confdroid_resources is a lightweight Puppet module that automates the installation and configuration of common YUM/DNF repositories on Rocky Linux (and other Red Hat-based distributions). Its primary focus is managing widely used third-party repositories such as EPEL in a clean, idempotent, and conflict-free way.
+
+
Why This Module Exists
+
+
Rocky Linux (like other Enterprise Linux distributions) uses YUM/DNF repositories to define where packages are downloaded from. Many useful packages — especially development tools, monitoring agents, additional utilities, and more — are not available in the base OS repositories. These packages are commonly found in EPEL (Extra Packages for Enterprise Linux).
+
+
However, Puppet follows a singleton resource model: a given resource (such as the EPEL repository) can only be declared and managed once in the catalog. Declaring it multiple times causes conflicts and catalog compilation failures.
+
+
This creates a common problem:
+
+
Module A needs EPEL to install package X.
+
+
Module B also needs EPEL to install package Y.
+
+
If both modules try to declare the EPEL repo resource → conflict.
+
+
+
To solve this, the best practice is to manage foundational repositories (like EPEL) once, in a central place that is included in every node’s catalog — regardless of which specific modules or classes are applied. That’s exactly where confdroid_resources comes in.
+
+
How It Works
+
+
The module provides a clean, reusable way to install and enable common repositories (starting with EPEL).
+
+
It is designed to be included early in the catalog — ideally in a base profile or common role that applies to all nodes.
+
+
Once the repository is present, any module or class can safely install packages that depend on it without re-declaring the repo resource.
+
+
Individual repositories can be enabled or disabled via parameters, giving you full control without touching the main resource declarations.
+
+
+
This approach keeps your catalog clean, avoids duplication, and prevents resource conflicts.
+
+
WARNING
+
+
Attention: Never use this puppet module on systems which have been previously configured manually. It is impossible to predict how and what would have been configured, hence previous configurations outside the scope of this module may be overwritten! Automated configurations require a test environment to verify that the module suits the purpose intended by the user, as well as tune the parameters, before deploying into live production
+
+
Features
+
+
installs and configures yum repos
+
+
install commonly required packages, which can be overridden per host, hostgroup etc.
+
+
Automatic installation and enabling of EPEL via $rs_enable_epel. since this parameter is directly also used in the yumrepo configuration, it needs to be set to 1, nottrue.
+
+
Parameter-based control (enable/disable specific repos)
+
+
Idempotent and conflict-free design
+
+
+
More repositories (PowerTools/CRB, RPM Fusion, etc.) will be added over time.
+
+
Repo Documentation
+
+
See the full Puppet documentation including parameters in docs/index.html
+
+
Dependencies
+
+
All dependencies must be included in the catalogue.
+
+
Deployment
+
+
native Puppet deployment
+
+
+
via site.pp or nodes.pp
+
+
node 'example.example.net' {
+ include confdroid_resources
+}
+
+
+
through Foreman (recommended):
+
+
+
In order to apply parameters through Foreman, the params.pp must be added to the host or host group in question.
All files and directories are configured with correct selinux context. If selinux is disabled, these contexts are ignored.
+
+
Known Problems
+
+
Support
+
+
OS: Rocky 9
+
+
Puppet 8
+
+
+
Tests
+
+
Puppet Lint
+
+
excluded tests:
+
+
--no-variable_scope-check: not applicable as we are inheriting parameters from params class. the lint check does not distinguish between facts and inherited parameters.
ConfDroid as entity is entirely independent from Puppet. We provide custom configuration modules, written for specific purposes and specific environments. The modules are tested and supported only as documented, and require testing in designated environments (i.e. lab or development environments) for parameter tuning etc. before deploying into production environments.
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/doc/frames.html b/doc/frames.html
new file mode 100644
index 0000000..53734c2
--- /dev/null
+++ b/doc/frames.html
@@ -0,0 +1,22 @@
+
+
+
+
+ Documentation by YARD 0.9.36
+
+
+
+
diff --git a/doc/index.html b/doc/index.html
new file mode 100644
index 0000000..dd73c08
--- /dev/null
+++ b/doc/index.html
@@ -0,0 +1,226 @@
+
+
+
+
+
+
+ File: README
+
+ — Documentation by YARD 0.9.36
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
confdroid_resources is a lightweight Puppet module that automates the installation and configuration of common YUM/DNF repositories on Rocky Linux (and other Red Hat-based distributions). Its primary focus is managing widely used third-party repositories such as EPEL in a clean, idempotent, and conflict-free way.
+
+
Why This Module Exists
+
+
Rocky Linux (like other Enterprise Linux distributions) uses YUM/DNF repositories to define where packages are downloaded from. Many useful packages — especially development tools, monitoring agents, additional utilities, and more — are not available in the base OS repositories. These packages are commonly found in EPEL (Extra Packages for Enterprise Linux).
+
+
However, Puppet follows a singleton resource model: a given resource (such as the EPEL repository) can only be declared and managed once in the catalog. Declaring it multiple times causes conflicts and catalog compilation failures.
+
+
This creates a common problem:
+
+
Module A needs EPEL to install package X.
+
+
Module B also needs EPEL to install package Y.
+
+
If both modules try to declare the EPEL repo resource → conflict.
+
+
+
To solve this, the best practice is to manage foundational repositories (like EPEL) once, in a central place that is included in every node’s catalog — regardless of which specific modules or classes are applied. That’s exactly where confdroid_resources comes in.
+
+
How It Works
+
+
The module provides a clean, reusable way to install and enable common repositories (starting with EPEL).
+
+
It is designed to be included early in the catalog — ideally in a base profile or common role that applies to all nodes.
+
+
Once the repository is present, any module or class can safely install packages that depend on it without re-declaring the repo resource.
+
+
Individual repositories can be enabled or disabled via parameters, giving you full control without touching the main resource declarations.
+
+
+
This approach keeps your catalog clean, avoids duplication, and prevents resource conflicts.
+
+
WARNING
+
+
Attention: Never use this puppet module on systems which have been previously configured manually. It is impossible to predict how and what would have been configured, hence previous configurations outside the scope of this module may be overwritten! Automated configurations require a test environment to verify that the module suits the purpose intended by the user, as well as tune the parameters, before deploying into live production
+
+
Features
+
+
installs and configures yum repos
+
+
install commonly required packages, which can be overridden per host, hostgroup etc.
+
+
Automatic installation and enabling of EPEL via $rs_enable_epel. since this parameter is directly also used in the yumrepo configuration, it needs to be set to 1, nottrue.
+
+
Parameter-based control (enable/disable specific repos)
+
+
Idempotent and conflict-free design
+
+
+
More repositories (PowerTools/CRB, RPM Fusion, etc.) will be added over time.
+
+
Repo Documentation
+
+
See the full Puppet documentation including parameters in docs/index.html
+
+
Dependencies
+
+
All dependencies must be included in the catalogue.
+
+
Deployment
+
+
native Puppet deployment
+
+
+
via site.pp or nodes.pp
+
+
node 'example.example.net' {
+ include confdroid_resources
+}
+
+
+
through Foreman (recommended):
+
+
+
In order to apply parameters through Foreman, the params.pp must be added to the host or host group in question.
All files and directories are configured with correct selinux context. If selinux is disabled, these contexts are ignored.
+
+
Known Problems
+
+
Support
+
+
OS: Rocky 9
+
+
Puppet 8
+
+
+
Tests
+
+
Puppet Lint
+
+
excluded tests:
+
+
--no-variable_scope-check: not applicable as we are inheriting parameters from params class. the lint check does not distinguish between facts and inherited parameters.
ConfDroid as entity is entirely independent from Puppet. We provide custom configuration modules, written for specific purposes and specific environments. The modules are tested and supported only as documented, and require testing in designated environments (i.e. lab or development environments) for parameter tuning etc. before deploying into production environments.