Creates and hosts locally managed RPM repositories
Arden Puppet

Arden Puppet



2,322 latest version

5.0 quality score

Version information

  • 0.2.1 (latest)
  • 0.2.0
  • 0.1.2
  • 0.1.1
released Sep 18th 2019
This version is compatible with:
  • Puppet Enterprise 2019.8.x, 2019.7.x, 2019.5.x, 2019.4.x, 2019.3.x, 2019.2.x, 2019.1.x, 2019.0.x, 2018.1.x, 2017.3.x
  • Puppet >= 5.0.0 < 7.0.0
  • CentOS

Start using this module


arden/local_rpm_repo — version 0.2.1 Sep 18th 2019


pipeline status Version

Table of Contents

  1. Description
  2. Setup - The basics of getting started with local_rpm_repo
  3. Usage - Configuration options and additional functionality
  4. Limitations - OS compatibility, etc.
  5. Development - Guide for contributing to the module


This module allows you to create and deploy a http based RPM repository using a tar of RPMs as a source or an external puppet fileserver. This can be helpful for environments where some number of locally created and maintained RPMs must be distributed to a set of systems.

We use this to automatically maintain a simple repo containing a ppc64 build of puppet-agent.


What local_rpm_repo affects

It creates an apache vhost on the target machine and schedules a cron job of createrepo for each repository specified in the config. The repos will be within the specified vhost in their own folders.

Setup Requirements - Tar Source

When an http or https URL is provided the module assumes you have a simple web server configured to host a tar file for each repository you intend to deploy.

Tar files for each repository should be created and named with a format similar to ${reponame}-${version}.tar. For example, a repo named test-repo with a version string of would have a corresponding tar named test-repo- It is possible to override the ${reponame} portion of this string with an alternate prefix. See the reference documentation for detail.

Setup Requirements - Puppet Source

Configure a custom file server mount point to host the source data for your repositories. The base_url should contain a directory corresponding to the repository name or the prefix override configured for that repository. Within that directory there should be a folder for the target version which contains the desired RPMs in the expected deployment structure.


Tar Sources

The example below will configure three repos named repo1, repo2, and repo3 respectively on the target node. This node will expect connections to arrive to the vhost yum.example.com.

When puppet is applying this configuration it will expect to be able to download the following three files:

  • http://bin.example.com/data/repo1-
  • http://bin.example.com/data/repo2-
  • http://bin.example.com/data/repo3-dev-
class local_rpm_repo {
  base_url_default => 'http://bin.example.com/data/',
  mirror_fqdn      => 'yum.example.com',
  repo_list        => {
    'repo1' => { 'version' => '' },
    'repo2' => { 'version' => '' },
    'repo3' => {
      'version' => '',
      'prefix'  => 'repo3-dev',

Alternatively the same configuration can be achieved via hiera:

local_rpm_repo::base_url_default: 'http://bin.example.com/data/'
local_rpm_repo::mirror_fqdn: 'yum.example.com'
    version: ''
    version: ''
    prefix: 'repo3-dev'
    version: ''

Once applied, the following changes will be implemented:

The /var/yumrepos directory will contain the following sub folders:

  • /var/yumrepos/repo1/versions/
  • /var/yumrepos/repo2/versions/
  • /var/yumrepos/repo3/versions/

The contents of the three tar files detailed above will be extracted to these directories.

An Apache vhost will be created listening at yum.example.com serving the /var/yumrepos directory.

Puppet Fileserver

This method uses the source directive on the puppet file resource type to recursively replicate the contents of the specified source folder as the repo version.

local_rpm_repo::base_url_default: 'http://bin.example.com/data/'
local_rpm_repo::mirror_fqdn: 'yum.example.com'
    version: ''
    base_url: 'puppet:///external_files'
    version: ''

In the example above repo1 will be declared from the tar http://bin.example.com/data/repo1- as normal, however, repo2 will replicate the contents of puppet:///external_files/repo2/ to it's version directory.


  • Currently GPG signing of repositories is not supported.




Check out the contributor list.