jamf/jamfpro

JamfPro Docker image

JamfPro Tomcat Docker Image

Please Note

The Dockerhub image has moved to the Jamf namespace and tags will pushed here: Dockerhub Tags

Description

Basic example Docker image based upon upstream Tomcat image to run a manually downloaded JamfPro ROOT.war from JamfNation.

Note

This repository is provided as an example of how to construct a very basic Docker image to run a JamfPro server. Please refer to this JamfNation post - Apache Tomcat Versions Installed by the Jamf Pro Installer - to determine which Tomcat versions are explictly supported for a particular version of JamfPro.

Features

• Creates and runs Tomcat as user:group tomcat (non-root)
• Correct pathing for JamfPro file logs
• Logs to stdout of JamfPro logs in addition to catalina logs
• JMX connection information
• Remote database connection in DataBase.xml

Docker Build Options

Override the version of Tomcat used:

docker build --build-arg "TOMCAT_VERSION=8.5.85-jdk11" -t jamfpro .

Replace the server.template file prior to building to override the server.xml Tomcat file.

Environment Variable Options

STDOUT_LOGGING [ true ] / false

DATABASE_HOST [ localhost ]
DATABASE_NAME [ jamfsoftware ]
DATABASE_USERNAME [ jamfsoftware ]
DATABASE_PASSWORD [ jamfsw03 ]
DATABASE_PORT [ 3306 ]
JDBC_PARAMETERS [ ]

JMXREMOTE true / [ false ]
JMXREMOTE_PORT
JMXREMOTE_RMI_PORT
JMXREMOTE_SSL
JMXREMOTE_AUTHENTICATE
RMI_SERVER_HOSTNAME
JMXREMOTE_PASSWORD_FILE

CATALINA_OPTS
JAVA_OPTS [ -Djava.awt.headless=true ]

PRIMARY_NODE_NAME -- Enable clustering
  This MUST be the ip address of the primary as recognized by Tomcat
  There is no direct JamfPro primary <--> secondary communication so the ip need not be reachable by the secondary directly

POD_NAME -- Enable Kubernetes clustering via downward API
POD_IP -- Enable Kubernetes clustering via downward API

MEMCACHED_HOST -- Enable Memcached caching, assumes port 11211 by default

server.xml template overrides:

tomcat_executor_max_threads - 150
tomcat_executor_min_threads - 4
tomcat_connector_port - 8080
tomcat_connection_timeout - 61000
tomcat_connector_proxy_port - 443
tomcat_connector_server - Jamf
tomcat_connector_max_parameter_count - 300000
tomcat_host_app_base - webapps
tomcat_host_unpack_wars - true
tomcat_host_auto_deploy - true
tomcat_host_start_stop_threads - 4
tomcat_host_stuck_threads_threshold - 600

Data Persistence

This image requires that either a /data/ROOT.war be bind-mounted and exist, or the /usr/bin/tomcat/webapps/ROOT directory exist. A ROOT.war will be auto-unpacked and configured based upon the above environment variables, or if the ROOT directory already exists, nothing will be unpacked but logging paths, database information, JMX, and Java opts will be set.

File Override Config

The DataBase.xml file can be optionally mounted into the container's /config directory, this will override any environment variables set.

Example

Run a basic JamfPro instance with port 8080 exposed locally on port 8080, setup remote database, bind-mounted ROOT.war, and bind-mounted webapps directory.

docker run -p 8080:8080 -d \
-e DATABASE_USERNAME=root \
-e DATABASE_PASSWORD=jamfsw03 \
-e DATABASE_HOST=host.docker.internal \
-v $(pwd)/ROOT.war:/data/ROOT.war \
-v $(pwd)/webapps:/usr/local/tomcat/webapps \
jamf/jamfpro:0.0.18

Valid image tags can be found on Dockerhub Tags or Github Releases.

Kubernetes Deployment

When enabling clustering the Tomcat manifest should include both POD_NAME and POD_IP environment variables which can be accessed via the Kubernetes downward API. The environment variable PRIMARY_NODE_NAME should be set to whichever pod will become the primary node. An example of utilizing the downward API in a manifest:

- name: POD_NAME
valueFrom:
  fieldRef:
    fieldPath: metadata.name
- name: POD_IP
valueFrom:
  fieldRef:
    fieldPath: status.podIP

jamfpro's Issues

SSL Issues with OpenJDK

We recently began experiencing issues when enrolling and using the Jamf binary to execute commands and run policies. Looking at the server logs, we're seeing a large amount of SSLHandshake errors specifically with VPP and what appears to be Jamf's Patch Management system. When running recon, we receive an "Unknown error", with no additional information. Based on our Jamf logs, it looks like the SSL issue is related to OpenJDK not having the correct certificates. Can Jamf please take a look at this Docker image and explore switching to another JDK?

To Reproduce
Steps to reproduce the behavior:

1. Containerize Jamf Pro using the Jamf Dockerfile
2. Enroll machines manually or via DEP
3. Use the binary to run recon or policy

Expected behavior
The binary should work as expected.

Additional context
Sample from Jamf log:
Caused by: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

Tomcat Version nit Matching Latest Recommended Release?

Describe the bug
As per https://www.jamf.com/jamf-nation/articles/380/apache-tomcat-versions-installed-by-the-jamf-pro-installer Tomcat 8.5.57 is intended for JAMF Pro 10.24.2.

Expected behavior
I'm not sure if it is within the scope of this project to try and keep the versions up to date, but I'm just looking to understand if this image is "safe" to use with the latest versions, or should this repo/image be used as a reference for creating an up to date version?

Tomcat - /usr/local/tomcat/conf/server.xml - allow server.xml somehow to be on an external volume

Is your feature request related to a problem? Please describe.

Profile Service Enrollment does not send an http"S":///enroll/profile. Since it's not a secure link it won't install the MDM profile. You can change Tomcat Apache settings to put it behind a load balancer, but these settings do not persist. When I pulled out /user/local/tomcat/conf and used a volume, the settings persisted but the App still does not push out an https version of the MDM profile. Can't seem to save my own cert or a Jamf cert in the Apache Tomcat Settings either.

using Traefik for the front end load balancer and it's handling the SSL cert for the backend jamf container.

Describe the solution you'd like
1 - Add volume for /usr/local/tomcat/conf - may need to populate with base config.
2 - Figure out how to get https MDM profile out to a user enrolled computer.

Describe alternatives you've considered
1 - figure out how to export 443 and mount a volume for the certificates for tomcat within the container

Additional context
At the moment this is very close to a perfect solution, but without a valid MDM to stall, it's not functional.
My email if you want more data: [email protected]

Thanks for reviewing this...

SSL cert does not persist

Describe the bug
After uploading an SSL cert through web dashboard, and if the pod restarts, the cert file does not persist.

To Reproduce
Steps to reproduce the behavior:

1. Setup kubernetes deployment
2. Upload SSL cert for https/host connection through instance web interface
3. If pod is restarted for whatever reason, the cert file does not persist

I understand the app is built for a native install, I mainly want to get a confirmation that for a successful deployment, whether we need to embed the cert (similar to root.WAR file) when we create our own image.

Add support for configure the load balancing settings

At the moment the tomcat server is installed without any modifications to the server.xml. It would be great if following settings can be set when working behind a load balancer:

• Enable Remote IP Valve
• Enable Proxy Port
• Scheme
• Proxy Port

At the moment I'm manually creating the server.xml and adding it to the image like this:
ADD server.xml /usr/local/tomcat/conf/

Release 0.0.14 not pushed to Docker Hub

The current release 0.0.14 was not pushed to Docker hub.

Link to Kubernetes Manifests is Dead

Describe the bug
At the bottom of the README there is a reference to the "JamfPro Kubernetes Manifests"(https://github.com/jamf/kubernetesManifests) but it appears that repository has been deleted.

To Reproduce

• Scroll to the bottom of the README.
• Click the hyperlink "JamfPro Kubernetes Manifests""
• Notice Github error

Expected behavior
Repository to load

Additional context
I assume these have been deleted rather than moved, so I'm guessing the link can be removed.

ERROR InitializeServerThread: - Error in Setup Assistant: Unhandled Case.

Describe the bug
After doing a clean build from jamf/jamfpro:latest and using the 10.43.1 war file. I get the database schema created and the licences agreement. After agreeing I then only get a white screen and not the entire key screen. If you then remove the SetupAssistant.html it shows the agreement again.

To Reproduce
Steps to reproduce the behavior:

1. docker run -p 8880:8080 -d \

-e DATABASE_USERNAME=user
-e DATABASE_PASSWORD=Password
-e DATABASE_HOST=mysql-8.0
-v $(pwd)/10.43.1/ROOT.war:/data/ROOT.war
-v $(pwd)/webapps:/usr/local/tomcat/webapps
-v $(pwd)/logs:/usr/local/tomcat/logs
--network jamfpro
--name jamf-pro-10.43.1
jamf/jamfpro:latest

Expected behavior
Enter licence key and create admin account

Screenshots
Its just a white screen

Additional context
The is from a clean install, I have note tried this from a backup

arm64 version?

Is it possible to put an arm64 version on Docker Hub? I run dev servers locally and just got an M1 laptop.

In the README procedure, the docker pull will not succeed

Describe the bug

It is described as

docker run -p 8080:8080 -d \
-e DATABASE_USERNAME=root \
-e DATABASE_PASSWORD=jamfsw03 \
-e DATABASE_HOST=host.docker.internal \
-v $(pwd)/ROOT.war:/data/ROOT.war \
-v $(pwd)/webapps:/usr/local/tomcat/webapps \
jamfpro

in README.md.

But I can't pull the image.

To Reproduce

docker run -p 8080:8080 -d \
-e DATABASE_USERNAME=root \
-e DATABASE_PASSWORD=jamfsw03 \
-e DATABASE_HOST=host.docker.internal \
-v $(pwd)/ROOT.war:/data/ROOT.war \
-v $(pwd)/webapps:/usr/local/tomcat/webapps \
jamfpro

Expected behavior

I expect that the image will be pulled.

Additional context

There is not the latest tag in https://hub.docker.com/r/jamfdevops/jamfpro/tags/.
Perhaps it seems that the addition of it is out in the flow of the publish of image.

Workaround
As of 2018-12-11,

docker run -p 8080:8080 -d \
-e DATABASE_USERNAME=root \
-e DATABASE_PASSWORD=jamfsw03 \
-e DATABASE_HOST=host.docker.internal \
-v $(pwd)/ROOT.war:/data/ROOT.war \
-v $(pwd)/webapps:/usr/local/tomcat/webapps \
jamfdevops/jamfpro:0.0.4

Please include environment variable for XFF

My ingress requires me to use a */jamfpro URL scheme, which requires me to set x-forwarded-for in the tomcat server xml file.
In order to do this, I need to hack it with an init container.
This is not the end of the world, but it would be nice to have a supported mechanism.

P.S. - Great work on this so far. Thanks.

Not working with Jamf 10.34.0+?

Describe the bug

When this image is used with Jamf Pro 10.34.0+ with no mysql data it consistently gets this error message when opening the webpage.

"There was an error updating the database schema. Contact JAMF Software Support."

To Reproduce

I'm using my docker-compose file. There's nothing special about my file so I can't see how it would be that. In my .env file I change JAMF_PRO_VERSION= to JAMF_PRO_VERSION=10.34.0 (or above) and then I make sure I've copied the ROOT.war into a folder named "10.34.0" located in the same dir as my docker-compose.yml file. Then I run docker-compose up -d in the dir. I wait for it to start up then I open the web browser to "http://localhost".

Expected behavior

When opening web browser it should come up to the license screen.

This docker-compose file works with Jamf Pro 10.33.0 and below.

Debug logging to STDOUT

Describe the bug
With Jamf-Pro-Container Release 0.0.17 and Jamf Pro 10.37.0 the debug logging is send to STDOUT even with STDOUT_LOGGING Variable on false.

Expected behavior
With STDOUT_LOGGING on false, no logging is send to STDOUT.

clustering.properties no longer read on each boot of Jamf Pro

It appears that at least in Jamf Pro 10.42.1 the clustering.properties file used in this portion of the code is no longer read on each boot.

I've spent the past few weeks with Jamf Support working on this as part of CS0898484.
I've asked for details on if this was on purpose, or accidental and will be fixed.

Figured the maintainers of this repo would like to know about it since this is where I first found out about that file.

If y'all find anything out I would love to get an update, so far the answer is "this isn't really supported"

Expose DataBase.xml jdbcParameters as environment variable

Is your feature request related to a problem? Please describe.
When configuring JAMF Pro with Amazon Aurora, we learned that the default connection string in the DataBase.xml needed to be modified.

Describe the solution you'd like
I'd like to update this section of the configuration.sh file to also include an environment variable override for the jdbcParameters XML field.

Describe alternatives you've considered
Given that the ROOT.war is still compressed at bootstrap, I didn't see many non-invasive alternatives that didn't involve modifying the docker image posted to Docker hub.