fix: keep puppetserver gems out of the var-dir mount path#153
Open
slauger wants to merge 1 commit into
Open
Conversation
Signed-off-by: Simon Lauger <simon@lauger.de>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
The bundled
puppetserver.confpointsmaster-var-dirat/opt/puppetlabs/server/data/puppetserver-- the same directory that holds the static, image-providedjruby-gemsandvendored-jruby-gems(whererequire 'puppet'is loaded from).To persist variable runtime data (yaml, server_data, bucket, reports) people mount a volume on
data/puppetserver. That overlays and empties the gem directories, so the server can no longer load Puppet and dies with:The entrypoint only restores
vendored-jruby-gems, notjruby-gems, so that workaround is incomplete.Fix
Point
master-var-dirat a dedicated.../puppetserver/varsub-directory. The variable data now has its own mountable location, and the gems stay untouched at their absolute paths.gem-home/gem-pathare already absolute and are not derived from the var-dir, so they are unaffected.openvoxserver/files/etc/puppetlabs/puppetserver/conf.d/puppetserver.conf:master-var-dir->.../puppetserver/varopenvoxserver/prep_build_container.sh: create the newvardirectory (ownership is already handled by the recursivechownondata/puppetserver)Applies to both the Ubuntu and Alpine images via the shared prep scripts.
Verification
Built the Ubuntu image and ran, as the
puppetuser:require 'puppet'.../puppetserver/var.../puppetserverSo the new var dir is freely mountable without clobbering the gems, and the old foot-gun is reproduced as the control. This also makes running with a read-only root filesystem viable.
Breaking change
This changes the default
master-var-dirlocation. Existing deployments that persist or mount variable data at/opt/puppetlabs/server/data/puppetserverwill need to move that mount to/opt/puppetlabs/server/data/puppetserver/var. Data previously persisted at the old path will not be picked up automatically.Follow-up
The Helm chart most likely needs a matching change. It currently mounts a volume over the whole
data/puppetserverdirectory, which is exactly what triggers theLoadErrorand what this PR makes unnecessary. That mount should be moved to.../puppetserver/var(or dropped in favour of persisting only what actually needs it). Happy to follow up there.