Forge Home


Installs next generation Pulp server


92 latest version

4.7 quality score

We run a couple of automated
scans to help you access a
module's quality. Each module is
given a score based on how well
the author has formatted their
code and documentation and
modules are also checked for
malware using VirusTotal.

Please note, the information below
is for guidance only and neither of
these methods should be considered
an endorsement by Puppet.

Version information

  • 10.1.0 (latest)
  • 10.0.0
  • 9.0.0
  • 8.6.0
  • 8.5.0
  • 8.4.0
  • 8.3.0
  • 8.2.0
  • 8.1.0
  • 8.0.0
  • 7.2.0
  • 7.1.0
  • 7.0.1
  • 7.0.0
  • 6.0.0
  • 5.2.1
  • 5.2.0
  • 5.1.0
  • 5.0.0
  • 4.0.1
  • 4.0.0
  • 3.4.0
  • 3.3.0
  • 3.2.1
  • 3.2.0
  • 3.1.0
  • 3.0.0
  • 2.2.3
  • 2.2.2
  • 2.2.1
  • 2.2.0
  • 2.1.0
  • 2.0.0
  • 1.3.0
  • 1.2.1
  • 1.2.0
  • 1.1.1
  • 1.1.0
  • 1.0.0
  • 0.2.0
  • 0.1.0
released May 16th 2024
This version is compatible with:
  • Puppet Enterprise 2023.7.x, 2023.6.x, 2023.5.x, 2023.4.x, 2023.3.x, 2023.2.x, 2023.1.x, 2023.0.x, 2021.7.x, 2021.6.x, 2021.5.x, 2021.4.x, 2021.3.x, 2021.2.x, 2021.1.x, 2021.0.x
  • Puppet >= 7.0.0 < 9.0.0
  • ,

Start using this module

  • r10k or Code Manager
  • Bolt
  • Manual installation
  • Direct download

Add this module to your Puppetfile:

mod 'theforeman-pulpcore', '10.1.0'
Learn more about managing modules with a Puppetfile

Add this module to your Bolt project:

bolt module add theforeman-pulpcore
Learn more about using this module with an existing project

Manually install this module globally with Puppet module tool:

puppet module install theforeman-pulpcore --version 10.1.0

Direct download is not typically how you would use a Puppet module to manage your infrastructure, but you may want to download the module in order to inspect the code.



theforeman/pulpcore — version 10.1.0 May 16th 2024


Puppet module to set up Pulp 3. The primary goal of the maintainers is to set up Pulp 3 as part of Katello installation, but there's no reason it couldn't be used elsewhere.

The module assumes package repositories are present on the system. For convenience there is a pulpcore::repo class which installs from (built from pulpcore-packaging) but users can use other sources. Installation from pip is not supported.

Support policy

All supported versions are listed below. For every supported version, acceptance tests run in CI on every supported platform. The module provides no guarantee for multiple versions. Whenever a Pulpcore version is dropped, the module's major version is increased.

Supported operating systems are listed in metadata.json but individual releases can divert from that. For example, if Pulpcore x.y drops EL7, it will still be listed in metadata.json until all versions supported by the module have dropped it. Similarly, if x.z adds support for EL9, it'll be listed in metadata.json and all versions that don't support EL9 will have a note.

Pulpcore 3.39

Default recommended version.

Installation layout

Pulpcore doesn't mandate a specific layout so this module creates and manages this. There are some constraints, mostly due to SELinux support.

As part of the installation, it creates a user (default pulp) and group (default pulp). This user gets a home directory (default /var/lib/pulp). There is also a config dir (default /etc/pulp) under which a file is created.

The media root (default /var/lib/pulp/media) refers to the MEDIA_ROOT setting. In Pulp this should not be served by Apache. Instead of MEDIA_URL Pulp has a dedicated pulpcore-content service which can also perform permission checks. Only the Pulp services need to read the files so directory permissions are set to 0750. Note this default differs from Pulp's default. A subdirectory of the home directory allows a stricter lockdown and avoids any risk of uploading media files into the wrong directory.

There are also the STATIC_ROOT and STATIC_URL settings. These serve the static assets used by Pulp. This includes CSS and Javascript for the HTML pages. They're not needed for the application to function, but make browsing the API more convenient.

These is also the cache_dir which is used to configure WORKING_DIRECTORY and FILE_UPLOAD_TEMP_DIR. This defaults to /var/lib/pulp/tmp. It is strongly recommended that this is on the same filesystem as MEDIA_ROOT.

Apache is configured to use an empty directory as docroot ($apache_docroot, default /var/lib/pulp/pulpcore_static). Doing so prevents Apache from bypassing the Pulp content app. When Apache is not managed, this directory is not managed.

While Pulp can create most of these directories at runtime, they're explicitly managed to set the correct permissions and, if pulpcore-selinux is installed, enforce the correct labels.

This results into the following structure, using tree -pug:

├── [drwxr-xr-x root     root    ]  etc
│   └── [drwxr-xr-x root     pulp    ]  pulp ($config_dir)
│       └── [-rw-r----- root     pulp    ]
└── [drwxr-xr-x root     root    ]  var
    └── [drwxr-xr-x root     root    ]  lib
        └── [drwxrwxr-x pulp     pulp    ]  pulp ($user_home)
            ├── [drwxr-xr-x pulp     pulp    ]  assets ($static_root)
            ├── [drwxr-xr-x pulp     pulp    ]  pulpcore_static ($apache_docroot)
            ├── [drwxr-x--- pulp     pulp    ]  media ($media_root)
            └── [drwxr-x--- pulp     pulp    ]  tmp ($cache_dir)

Pulpcore settings

The application will load settings from Django's defaults, Pulpcore's defaults, plus any overrides defined in the settings file at ${config_dir}/ (default: /etc/pulp/ The Django diffsettings tool is useful to check settings which are different from Django's defaults (i.e. all of the Pulpcore defaults which are not present in Django, plus any overrides defined in the settings file):

PULP_SETTINGS=/etc/pulp/ pulpcore-manager diffsettings

For example, to check the current value of a Pulpcore setting such as WORKER_TTL:

PULP_SETTINGS=/etc/pulp/ pulpcore-manager diffsettings | grep WORKER_TTL

This is useful for module parameter which configure Pulpcore settings but have an undef default, such as $worker_ttl. When the param value is undef, the setting is omitted from and therefore Pulpcore's default is used.

Service setup

The module deploys a few systemd services:

  • pulpcore-api.socket - A unix socket that listens on $api_socket_path (default: /run/pulpcore-api.sock). It is owned by the Apache user.
  • pulpcore-api.service - The actual content service. It is using systemd socket activation.
  • pulpcore-content.socket - A unix socket that listens on $content_socket_path (default: /run/pulpcore-content.sock). It is owned by the Apache user.
  • pulpcore-content.service - The actual content service. It is using systemd socket activation.
  • pulpcore-worker@.service - A service template allowing multiple workers to be started. Actual workers will be named pulpcore-worker@%i where %i is a number starting at 1 and ending at $worker_count.

The systemd socket activated services bind to a unix socket. They are always owned by the Apache user. To find this out this username, it always pulls in the apache module, even if the vhosts are unmanaged ($apache_http_vhost and $apache_https_vhost both set to false).

Binding to a unix socket with minimal permissions is the most secure since only Apache can connect to Pulp's services. This forces the authentication to happen and prevents MITM attacks. Binding on TCP ports is not supported for this reason.