The original author of this module has long promoted a line of thinking that builds off of Infrastructure As Code into Infrastructure As Data. With Hiera and modules like this, end-users can simply import the code they need and then fully express their entire enterprise infrastructure purely as data without any more code to write or support (not even antiquated roles/profiles). As such, all examples in this document and the module's in-file documentation are presented strictly as YAML.
- Description
- Setup - The basics of getting started with postfix
- Usage - Configuration options and additional functionality
- Reference - An under-the-hood peek at what the module is doing and how
- Limitations - OS compatibility, etc.
- Development - Guide for contributing to the module
This module was written from scratch, specifically for Puppet 5 and Hiera 5 to fully manage postfix; nothing more and nothing less. No assumptions are made as to what you intend to do with postfix other than enjoy full control over it via Hiera in every respect.
Here, "fully manage" means this Puppet module:
- Installs, upgrades, downgrades, version-pins, and uninstalls postfix.
- Controls every line in every postfix configuration file, both vendor- and user-supplied.
- Optionally controls the postfix service.
This is one of a generation of Puppet modules that fully extends control over the subject resources to Hiera. Use modules like this where you'd rather express your infrastructure as data without any further Puppet code.
This module specifically affects the following resources:
- The primary postfix package, or whatever it is named for your platform.
- Every line of every file in the postfix configuration directory.
- The postfix service -- by any name -- if you so choose.
Please refer to the dependencies section of metadata.json to learn what other modules this one needs, if any.
At its simplest, you can install postfix in its vendor-supplied default state merely with:
---
classes:
- postfix
Many usage examples are provided via the source code documentation. Refer to the Reference section to learn how to access it.
Pre-generated, web-accessible reference documentation -- with abundant examples -- can be found at GitHub Pages for this project, generated via Puppet Strings. If you do not have access to this on-line documentation, please just run bundle install && bundle exec rake strings:generate from this module's top directory to have a local copy of the documentation generated for you in the docs directory.
Please refer to the operatingsystem_support section of metadata.json for known, proven-in-production OS compatibility. This is not an exhaustive list. You will very likely find that this module runs just fine on other operating system and version combinations, given the proper inputs. In fact, if you do, please report it back so the metadata can be updated!
This module is compatible with both Postfix 2 and 3. However, its default model is that of Postfix 2 due to its continuing prevalence. In order to support Postfix 3, you must supply the following additional configuration:
# Disable `purge_config_file_path` to preserve these unmanaged but important resources:
# - %{config_file_path}/dynamicmaps.cf.d/
# - %{config_file_path}/dynamicmaps.cf
# - %{config_file_path}/main.cf.proto
# - %{config_file_path}/master.cf.proto
# - %{config_file_path}/postfix-files
postfix::purge_config_file_path: false
# Specify a backward compatibility threshold for Postfix
postfix::global_parameters:
compatibility_level: 2Please refer to CONTRIBUTING to learn how to hack this module.