akerl-r10k 3.14.2.1

data/doc/puppetfile.mkd

@@ -0,0 +1,355 @@
+Puppetfile
+==========
+
+Puppetfiles are a simple Ruby based DSL that specifies a list of modules to
+install, what version to install, and where to fetch them from. r10k can use a
+Puppetfile to install a set of Puppet modules for local development, or they can
+be used with r10k environment deployments to install additional modules into a
+given environment.
+
+Unlike librarian-puppet, the r10k implementation of Puppetfiles does not include
+dependency resolution, but it is on the roadmap.
+
+When directly working with Puppetfiles, you can use the `r10k puppetfile`
+subcommand to interact with a Puppetfile.
+
+When using r10k's deploy functionality, interacting with Puppetfiles is handled
+on a case by case basis.
+
+Because the Puppetfile format is actually implemented using a Ruby DSL any valid
+Ruby expression can be used. That being said, being a bit too creative in the
+DSL can lead to surprising (read: bad) things happening, so consider keeping it
+simple.
+
+Commands
+--------
+
+Puppetfile subcommands assume that the Puppetfile to operate on is in the
+current working directory and modules should be installed in the 'modules'
+directory relative to the current working directory.
+
+Install or update all modules in a given Puppetfile
+into ./modules)
+
+    r10k puppetfile install
+
+Verify the Puppetfile syntax
+
+    r10k puppetfile check
+
+Remove any modules in the 'modules' directory that are not specified in the
+Puppetfile:
+
+    r10k puppetfile purge
+
+Global settings
+---------------
+
+The following settings can be used to control how the Puppetfile installs and
+handles modules.
+
+### forge
+
+The `forge` setting specifies which server that Forge based modules are fetched
+from. This declaration is only respected if [`forge.allow_puppetfile_override`](/dynamic-environments/configuration.mkd#allow_puppetfile_override)
+is set to true in the main `r10k.yaml`. Otherwise, use [`forge.baseurl`](/doc/dynamic-environments/configuration.mkd#baseurl)
+to globally configure where modules should be downloaded from.
+
+### moduledir
+
+The `moduledir` setting specifies where modules from the Puppetfile will be
+installed. This defaults to the `modules` directory relative to the Puppetfile.
+If the path is absolute then the modules will be installed to that absolute
+path, otherwise it's assumed that the `moduledir` setting should be relative and
+the modules will be installed in that directory relative to the Puppetfile.
+
+The moduledir setting should be placed before any modules are declared.
+
+Install modules to an absolute path:
+
+```ruby
+moduledir '/etc/puppet/modules'
+
+mod 'branan/eight_hundred' # will be installed into '/etc/puppet/modules/eight_hundred'
+```
+
+Install modules to a relative path:
+
+```ruby
+moduledir 'thirdparty'
+
+mod 'branan/eight_hundred' # will be installed into `dirname /path/to/Puppetfile`/thirdparty/eight_hundred
+```
+
+**Note**: support for a relative moduledir was added in r10k 1.4.0; the behavior
+of a relative moduledir path is undefined on earlier versions of r10k.
+
+Module types
+------------
+
+r10k can install Puppet modules from a number of different sources. Right now
+modules can be installed from the Puppet Forge, Git, or SVN.
+
+### Puppet Forge
+
+Modules can be installed from the Puppet Forge.
+
+If no version is specified the latest version available at the time will be
+installed, and will be kept at that version.
+
+    mod 'puppetlabs/apache'
+
+If a version is specified then that version will be installed.
+
+    mod 'puppetlabs/apache', '0.10.0'
+
+If the version is set to :latest then the module will be always updated to the
+latest version available.
+
+    mod 'puppetlabs/apache', :latest
+
+An explicit type and/or version can be specified using the standard interface,
+`:type` and `:version`. The `:source` parameter is not supported for individual
+forge modules and will be ignored.
+
+    mod 'puppetlabs/apache',
+      type:    'forge',
+      version: '6.0.0'
+
+### Git
+
+Git repositories that contain a Puppet module can be cloned and used as modules.
+When Git is used, the module version can be specified by using `:ref`, `:tag`,
+`:commit`, `:branch`, or the standard interface parameter `:version`.
+
+When a module is installed using `:ref`, r10k uses some simple heuristics to
+determine the type of Git object that should be checked out. This can be used
+with a git commit, branch reference, or a tag.
+
+When a module is installed using `:tag` or `:commit`, r10k assumes that the
+given object is a tag or commit and can do some optimizations around fetching
+the object. If the tag or commit is already available r10k will skip network
+operations when updating the repo, which can speed up install times. When
+`:ref` is set to track `HEAD`, it will synchronize the module on each run.
+
+Module versions can also be specified using `:branch` to track a specific
+branch reference.
+
+#### Examples
+
+```ruby
+# Install puppetlabs/apache and keep it up to date with 'master'
+mod 'apache',
+  :git => 'https://github.com/puppetlabs/puppetlabs-apache'
+
+# Install puppetlabs/apache and track the 'docs_experiment' branch
+mod 'apache',
+  :git => 'https://github.com/puppetlabs/puppetlabs-apache',
+  :ref => 'docs_experiment'
+
+# Install puppetlabs/apache and pin to the '0.9.0' tag
+mod 'apache',
+  :git => 'https://github.com/puppetlabs/puppetlabs-apache',
+  :tag => '0.9.0'
+
+# Install puppetlabs/apache and pin to the '83401079' commit
+mod 'apache',
+  :git    => 'https://github.com/puppetlabs/puppetlabs-apache',
+  :commit => '83401079053dca11d61945bd9beef9ecf7576cbf'
+
+# Install puppetlabs/apache and track the 'docs_experiment' branch
+mod 'apache',
+  :git    => 'https://github.com/puppetlabs/puppetlabs-apache',
+  :branch => 'docs_experiment'
+
+# Install puppetlabs/apache and use standard interface parameters pinned to the
+# '2098a17' commit.
+mod 'puppetlabs-apache',
+  type:    'git',
+  source:  'https://github.com/puppetlabs/puppetlabs-apache',
+  version: '2098a17'
+```
+
+#### Control Repo Branch Tracking
+
+Since r10k 2.4.0, the `:branch` option can be set to the special value
+`:control_branch` to indicate that the content should track a branch
+reference matching the containing control repo branch. For example, if a
+Puppetfile containing a Git content declaration is in the "testing" branch
+of a control repo, a setting of `:control_branch` will attempt to deploy that
+content from a "testing" branch of the content repo.
+
+Additionally, you can specify a `:default_branch` option which is the branch
+reference that content will be deployed from if the the given `:ref`, `:tag`,
+`:commit`, or `:branch` option cannot be resolved and deployed. If the desired
+content cannot be resolved and no default branch is given, or if the default
+branch can also not be resolved, an error will be logged and the content will
+not be deployed or updated.
+
+#### :control\_branch Examples
+
+```ruby
+# Deploy content from branch matching control repo branch.
+mod 'hieradata',
+  :git => 'git@git.example.com:organization/hieradata.git',
+  :branch => :control_branch
+
+# Track control branch and fall-back to master if no matching branch.
+mod 'hieradata',
+  :git => 'git@git.example.com:organization/hieradata.git',
+  :branch => :control_branch,
+  :default_branch => 'master'
+```
+
+
+### SVN
+
+Modules can be installed via SVN. If no version is given, the module will track
+the latest version available in the main SVN repository.
+
+    mod 'apache',
+      :svn => 'https://github.com/puppetlabs/puppetlabs-apache/trunk'
+
+If an SVN revision number is specified with `:rev`, `:revision`, or `:version`,
+that SVN revision will be kept checked out.
+
+    mod 'apache',
+      :svn => 'https://github.com/puppetlabs/puppetlabs-apache/trunk',
+      :rev => '154'
+
+    mod 'apache',
+      :svn      => 'https://github.com/puppetlabs/puppetlabs-apache/trunk',
+      :revision => '154'
+
+    mod 'apache',
+      type:    'svn',
+      source:  'https://github.com/puppetlabs/puppetlabs-apache/trunk',
+      version: '154'
+
+If the SVN repository requires credentials, you can supply the `:username` and
+`:password` options.
+
+    mod 'apache',
+      :svn      => 'https://github.com/puppetlabs/puppetlabs-apache/trunk',
+      :username => 'azurediamond',
+      :password => 'hunter2'
+
+**Note**: SVN credentials are passed as command line options, so the SVN
+credentials may be visible in the process table when r10k is running. If you
+choose to supply SVN credentials make sure that the system running r10k is
+appropriately secured.
+
+### Tarball
+
+Modules can be installed from tarball archives. A tarball module must specify a source URL to retreive the tarball content from. A tarball module may optionally specify a sha256 checksum as the module version.
+
+    mod 'puppetlabs-apache',
+      type: 'tarball',
+      source: 'https://repo.example.com/puppet/modules/puppetlabs-apache-7.0.0.tar.gz',
+      version: 'aedd6dc1a5136c6a1a1ec2f285df2a70b0fe4c9effb254b5a1f58116e4c1659e' # sha256 digest
+
+If no version is specified, a tarball will be downloaded from the given source and cached. The cache will not be invalidated until the source URL is changed, or a sha256 checksum version is provided.
+
+Tarball module content will be unpacked directly into an appropriately named module directory. For example, the puppetlabs-apache-7.0.0.tar.gz archive in the example above will be unpacked into `<environment-dir>/modules/apache/`.
+
+### Local
+
+In the event you want to store locally written modules in your r10k-managed
+repository in the Puppetfile managed path, you can use the `:local` type.
+
+For instance, if you have a Git repository with the following structure:
+
+```
+# tree -L 2
+.
+├── environment.conf
+├── modules
+│   └── local_module
+└── Puppetfile
+
+4 directories, 2 files
+```
+
+And you want to prevent `local_module` from being removed, you can add a 'local'
+module in your Puppetfile:
+
+```
+mod 'local_module', :local => true
+
+# Include your other modules as normal
+mod 'branan/eight_hundred'
+mod 'puppetlabs/apache'
+```
+
+If you run r10k against this Git branch, you'll get the following:
+
+```
+# tree -L 2
+.
+├── environment.conf
+├── modules
+│   ├── apache
+│   ├── eight_hundred
+│   └── local_module
+└── Puppetfile
+
+4 directories, 2 files
+```
+
+#### Caveats
+
+This is a workaround for r10k not being able to determine that modules
+created via VCS should not be purged, but is not meant to be a long term
+solution. The general practice around having local and remote modules in the
+same Git repository is to move modules versioned into a separate directory, like
+so:
+
+```
+# tree -L 2
+.
+├── environment.conf
+├── site-modules
+│   └── local_module
+├── modules
+│   ├── apache
+│   └── eight_hundred
+└── Puppetfile
+
+4 directories, 2 files
+```
+
+Moving modules stored in the Git repository into a separate directory will
+remove the need to have Puppetfile entries for every locally versioned Puppet
+module.
+
+For more information see the [FAQ entry](faq.mkd#how-do-i-prevent-r10k-from-removing-modules-in-the-modules-directory-of-my-git-repository)
+on managing internal and external modules in the same directory.
+
+### Per-Item spec dir deployment
+
+During deployment, r10k's default behavior is to deploy the spec directory. The
+Puppetfile can modify this per module, overriding settings from the default
+r10k config. The following example sets the module to not deploy the spec
+directory.
+
+```
+mod 'apache',
+  :git => 'git@github.com:puppetlabs/puppetlabs-apache.git',
+  :exclude_spec => true
+```
+
+### Per-Item Install Path
+
+Git and SVN content types support installing into an alternate path without changing
+the value of moduledir by specifying an 'install\_path' option:
+
+```
+# This will install the 'apache' module into 'external/apache'.
+mod 'apache',
+  :git => 'git@github.com:puppetlabs/puppetlabs-apache.git',
+  :install_path => 'external'
+```
+
+The given 'install\_path' can be an absolute path or a path relative to the base of
+the environment. Note that r10k will exit with an error if you attempt to set the
+'path' option to a directory outside of the environment.

data/doc/updating-your-puppetfile.mkd

@@ -0,0 +1,38 @@
+Updating Your Puppetfile
+========================
+
+Over time, your Puppetfile may become stale and reference older versions of modules or miss dependencies for the modules. Your Puppetfile will require maintenance to keep it up to date.
+
+Manual Updates
+--------------
+
+You can manually update your Puppetfile very easily. By visiting the module's homepage on the [Puppet Forge](https://forge.puppetlabs.com/), you can determine the new version of a module and update it:
+
+    # Original
+    mod 'puppetlabs/apache', '0.10.0'
+    
+    # New
+    mod 'puppetlabs/apache', '1.0.0'
+
+When using a module directly from a git/svn repo, the `:tag` or `:ref` should be updated:
+
+    # Original
+    mod 'apache',
+      :git => 'https://github.com/puppetlabs/puppetlabs-apache',
+      :tag => '0.10.0'
+      
+    # Original
+    mod 'apache',
+      :git => 'https://github.com/puppetlabs/puppetlabs-apache',
+      :tag => '1.0.0'
+
+Dependency tracking can be done on the Puppet Forge as well by looking at the Dependency tab (Ex: [puppetlabs/apache](https://forge.puppetlabs.com/puppetlabs/apache/dependencies) and visiting each module in turn, or examining `metadata.json` in non-forge modules.
+
+Automatic Updates
+-----------------
+
+The manual update process is sufficient when updating a small number of modules for a specific effort. Automatic tooling is helpful when updating a lengthier number of modules and for scheduled updates. A number of tools have been provided by the Puppet user community to assist with this. You are encouraged to review each tool before using them, and use of these tools is at your own risk.
+
+* [ra10ke](https://rubygems.org/gems/ra10ke) ([project page](https://github.com/tampakrap/ra10ke/)) - A set of rake tasks to scan the Puppetfile for out of date modules
+* [puppetfile-updater](https://rubygems.org/gems/puppetfile-updater/) ([project page](https://github.com/camptocamp/puppetfile-updater)) - A set of rake tasks to scan the Puppetfile, find newer versions, update the Puppetfile, and commit the changes.
+* [generate-puppetfile](https://rubygems.org/gems/generate-puppetfile) ([project page](https://github.com/rnelson0/puppet-generate-puppetfile)) - A command line tool to generate raw Puppetfiles, update existing Puppetfiles, and optionally generate a `.fixtures.yml` file.

data/docker/.gitignore

@@ -0,0 +1 @@
+TEST-rspec.xml

data/docker/.rspec

@@ -0,0 +1,4 @@
+--require pupperware/spec_helper
+--format RspecJunitFormatter
+--out TEST-rspec.xml
+--format documentation

data/docker/Gemfile

@@ -0,0 +1,11 @@
+source "https://rubygems.org"
+
+gem 'pupperware',
+    :git => 'https://github.com/puppetlabs/pupperware.git',
+    :branch => 'main',
+    :glob => 'gem/*.gemspec'
+
+group :test do
+    gem 'rspec'
+    gem 'rspec_junit_formatter'
+end

data/docker/Makefile

@@ -0,0 +1,99 @@
+PUPPERWARE_ANALYTICS_STREAM ?= dev
+NAMESPACE ?= puppet
+git_describe = $(shell git describe --tags)
+vcs_ref := $(shell git rev-parse HEAD)
+build_date := $(shell date -u +%FT%T)
+hadolint_available := $(shell hadolint --help > /dev/null 2>&1; echo $$?)
+hadolint_command := hadolint
+hadolint_container := ghcr.io/hadolint/hadolint:latest
+alpine_version := 3.14
+# --load (--output=type=docker) can only be used with a single arch / platform
+# https://github.com/docker/buildx/issues/59
+output_type := docker
+platform := linux/amd64
+export BUNDLE_PATH = $(PWD)/.bundle/gems
+export BUNDLE_BIN = $(PWD)/.bundle/bin
+export GEMFILE = $(PWD)/Gemfile
+export DOCKER_BUILDKIT ?= 1
+
+ifeq ($(IS_RELEASE),true)
+	VERSION ?= $(shell echo $(git_describe) | sed 's/-.*//')
+	PUBLISHED_VERSION ?= $(shell curl --silent 'https://rubygems.org/api/v1/gems/r10k.json' | jq '."version"' | tr -d '"')
+	CONTAINER_EXISTS = $(shell DOCKER_CLI_EXPERIMENTAL=enabled docker manifest inspect $(NAMESPACE)/r10k:$(VERSION) > /dev/null 2>&1; echo $$?)
+ifeq ($(CONTAINER_EXISTS),0)
+	SKIP_BUILD ?= true
+else ifneq ($(VERSION),$(PUBLISHED_VERSION))
+	SKIP_BUILD ?= true
+endif
+
+	LATEST_VERSION ?= latest
+	dockerfile := release.Dockerfile
+	dockerfile_context := r10k
+else
+	VERSION ?= edge
+	IS_LATEST := false
+	dockerfile := Dockerfile
+	dockerfile_context := $(PWD)/..
+endif
+
+ifeq ($(IS_LATEST),true)
+	latest_tag := --tag $(NAMESPACE)/r10k:$(LATEST_VERSION)
+endif
+
+prep:
+	@git fetch --unshallow 2> /dev/null ||:
+	@git fetch origin 'refs/tags/*:refs/tags/*'
+ifeq ($(SKIP_BUILD),true)
+	@echo "SKIP_BUILD is true, exiting with 1"
+	@exit 1
+endif
+
+lint:
+ifeq ($(hadolint_available),0)
+	@$(hadolint_command) r10k/$(dockerfile)
+else
+	@docker pull $(hadolint_container)
+	@docker run --rm -v $(PWD)/r10k/$(dockerfile):/Dockerfile -i $(hadolint_container) $(hadolint_command) Dockerfile
+endif
+
+build: prep
+	docker pull alpine:$(alpine_version)
+	docker buildx build \
+		${DOCKER_BUILD_FLAGS} \
+		--output=type=$(output_type) \
+		--platform $(platform) \
+		--build-arg alpine_version=$(alpine_version) \
+		--build-arg vcs_ref=$(vcs_ref) \
+		--build-arg build_date=$(build_date) \
+		--build-arg version=$(VERSION) \
+		--build-arg pupperware_analytics_stream=$(PUPPERWARE_ANALYTICS_STREAM) \
+		--file r10k/$(dockerfile) \
+		--tag $(NAMESPACE)/r10k:$(VERSION) $(latest_tag) $(dockerfile_context)
+
+test: prep
+	@bundle install --path $$BUNDLE_PATH --gemfile $$GEMFILE --with test
+	@bundle update
+	@PUPPET_TEST_DOCKER_IMAGE=$(NAMESPACE)/r10k:$(VERSION) \
+		bundle exec --gemfile $$GEMFILE \
+		rspec spec
+
+# call build to produce multiple architectures
+# uses cached output from amd64 build target if it exists
+# registry output is equivalent to --push
+push-image: platform=linux/amd64,linux/arm64
+push-image: output_type=registry
+push-image: prep build
+
+push-readme:
+	@docker pull sheogorath/readme-to-dockerhub
+	@docker run --rm \
+		-v $(PWD)/README.md:/data/README.md \
+		-e DOCKERHUB_USERNAME="$(DOCKERHUB_USERNAME)" \
+		-e DOCKERHUB_PASSWORD="$(DOCKERHUB_PASSWORD)" \
+		-e DOCKERHUB_REPO_PREFIX=puppet \
+		-e DOCKERHUB_REPO_NAME=r10k \
+		sheogorath/readme-to-dockerhub
+
+publish: push-image push-readme
+
+.PHONY: lint build test prep publish push-image push-readme

data/docker/README.md

@@ -0,0 +1,28 @@
+# [puppetlabs/r10k](https://github.com/puppetlabs/r10k)
+
+r10k on a Docker image. Based on Alpine 3.8.
+
+## Configuration
+
+The following environment variables are supported:
+
+- `PUPPERWARE_ANALYTICS_ENABLED`
+
+  Set to 'true' to enable Google Analytics metrics. Defaults to 'false'.
+
+## Analytics Data Collection
+
+The r10k container collects usage data. This is disabled by default. You can enable it by passing `--env PUPPERWARE_ANALYTICS_ENABLED=true`
+to your `docker run` command.
+
+### What data is collected?
+* Version of the r10k container.
+* Anonymized IP address is used by Google Analytics for Geolocation data, but the IP address is not collected.
+
+### Why does the r10k container collect data?
+
+We collect data to help us understand how the containers are used and make decisions about upcoming changes.
+
+### How can I opt out of r10k container data collection?
+
+This is disabled by default.

data/docker/docker-compose.yml

@@ -0,0 +1,18 @@
+version: '3.7'
+
+services:
+  r10k_check:
+    image: ${R10K_IMAGE:-puppet/r10k}
+    environment:
+      - PUPPERWARE_ANALYTICS_ENABLED=${PUPPERWARE_ANALYTICS_ENABLED:-false}
+    command: 'puppetfile check --verbose --trace --puppetfile test/Puppetfile'
+    volumes:
+      - ${SPEC_DIRECTORY}/fixtures:/home/puppet/test
+
+  r10k_install:
+    image: ${R10K_IMAGE:-puppet/r10k}
+    environment:
+      - PUPPERWARE_ANALYTICS_ENABLED=${PUPPERWARE_ANALYTICS_ENABLED:-false}
+    command: 'puppetfile install --verbose --trace --puppetfile test/Puppetfile'
+    volumes:
+      - ${SPEC_DIRECTORY}/fixtures:/home/puppet/test

data/docker/r10k/Dockerfile

@@ -0,0 +1,68 @@
+ARG alpine_version=3.14
+FROM alpine:${alpine_version} as build
+
+# hadolint ignore=DL3018
+RUN apk add --no-cache ruby git && \
+    mkdir /workspace
+WORKDIR /workspace
+COPY . /workspace
+RUN gem build r10k.gemspec && \
+    mv r10k*.gem r10k.gem
+
+FROM alpine:${alpine_version}
+
+ARG vcs_ref
+ARG build_date
+ARG version="3.1.0"
+# Used by entrypoint to submit metrics to Google Analytics.
+# Published images should use "production" for this build_arg.
+ARG pupperware_analytics_stream="dev"
+# required to schedule runs of "r10k" in K8s
+ARG supercronic_version="0.1.9"
+ARG supercronic_sha1sum="5ddf8ea26b56d4a7ff6faecdd8966610d5cb9d85"
+ARG supercronic="supercronic-linux-amd64"
+ARG supercronic_url="https://github.com/aptible/supercronic/releases/download/v$supercronic_version/$supercronic"
+
+LABEL org.label-schema.maintainer="Puppet Release Team <release@puppet.com>" \
+      org.label-schema.vendor="Puppet" \
+      org.label-schema.url="https://github.com/puppetlabs/r10k" \
+      org.label-schema.name="r10k" \
+      org.label-schema.license="Apache-2.0" \
+      org.label-schema.vcs-url="https://github.com/puppetlabs/r10k" \
+      org.label-schema.schema-version="1.0" \
+      org.label-schema.dockerfile="/Dockerfile"
+
+COPY docker/r10k/adduser.sh docker/r10k/docker-entrypoint.sh /
+COPY docker/r10k/docker-entrypoint.d /docker-entrypoint.d
+
+ENTRYPOINT ["/docker-entrypoint.sh"]
+CMD ["help"]
+
+# dynamic LABELs and ENV vars placed lower for the sake of Docker layer caching
+ENV PUPPERWARE_ANALYTICS_STREAM="$pupperware_analytics_stream"
+
+LABEL org.label-schema.version="$version" \
+      org.label-schema.vcs-ref="$vcs_ref" \
+      org.label-schema.build-date="$build_date"
+
+COPY --from=build /workspace/r10k.gem /
+SHELL ["/bin/ash", "-eo", "pipefail", "-c"]
+# ignore apk and gem pinning
+# hadolint ignore=DL3018,DL3028
+RUN chmod a+x /adduser.sh /docker-entrypoint.sh /docker-entrypoint.d/*.sh && \
+# Add a puppet user to run r10k as for consistency with puppetserver
+    /adduser.sh && \
+    chown -R puppet: /docker-entrypoint.d /docker-entrypoint.sh && \
+    apk add --no-cache ruby openssh-client git ruby-rugged curl ruby-json ruby-etc && \
+    gem install --no-doc /r10k.gem && \
+    rm -f /r10k.gem && \
+    curl --fail --silent --show-error --location --remote-name "$supercronic_url" && \
+    echo "${supercronic_sha1sum}  ${supercronic}" | sha1sum -c - && \
+    chmod +x "$supercronic" && \
+    mv "$supercronic" "/usr/local/bin/${supercronic}" && \
+    ln -s "/usr/local/bin/${supercronic}" /usr/local/bin/supercronic
+
+USER puppet
+WORKDIR /home/puppet
+
+COPY docker/r10k/Dockerfile /

data/docker/r10k/adduser.sh

@@ -0,0 +1,13 @@
+#!/bin/sh
+
+getent_string="$(getent group | grep -e ':999$')"
+exit_code=$?
+
+if [ "$exit_code" = '0' ]; then
+  group="$(echo $getent_string | cut -d ':' -f1)"
+else
+  addgroup -g 999 puppet
+  group='puppet'
+fi
+
+adduser -G $group -D -u 999 puppet

data/docker/r10k/docker-entrypoint.d/10-analytics.sh

@@ -0,0 +1,30 @@
+#!/bin/sh
+
+if [ "${PUPPERWARE_ANALYTICS_ENABLED}" != "true" ]; then
+    # Don't print out any messages here since this is a CLI container
+    exit 0
+fi
+
+# See: https://developers.google.com/analytics/devguides/collection/protocol/v1/parameters
+# Tracking ID
+tid=UA-132486246-5
+# Application Name
+an=r10k
+# Application Version
+av=$(r10k version | cut -d ' ' -f 2)
+# Anonymous Client ID
+_file=/var/tmp/pwclientid
+cid=$(cat $_file 2>/dev/null || (cat /proc/sys/kernel/random/uuid | tee $_file))
+# Event Category
+ec=${PUPPERWARE_ANALYTICS_STREAM:-dev}
+# Event Action
+ea=start
+# Anonymize ip
+aip=1
+
+_params="v=1&t=event&tid=${tid}&an=${an}&av=${av}&cid=${cid}&ec=${ec}&ea=${ea}&aip=${aip}"
+_url="http://www.google-analytics.com/collect?${_params}"
+
+# Don't print out any messages here since this is a CLI container
+curl --fail --silent --show-error --output /dev/null \
+    -X POST -H "Content-Length: 0" $_url

data/docker/r10k/docker-entrypoint.sh

@@ -0,0 +1,10 @@
+#! /bin/sh
+
+set -e
+
+for f in /docker-entrypoint.d/*.sh; do
+  # Don't print out any messages here since this is a CLI container
+  "$f"
+done
+
+exec /usr/bin/r10k "$@"