Automating environments with Puppet #1

Mascote do LinuxPro na sala de servidores, com quatro racks iguais controlados por fios de marionete e o logo do Puppet Labs na parede

Note (2026): Original text from April 2017 — an introduction to Puppet still using the Puppet Labs / “master” vocabulary, with the promise of a hands-on #2 that never appeared. Nine years later, the declarative language is the same, but the public package has changed hands: Perforce took the open binaries offline in late 2024, and the community (Vox Pupuli) continues the project as OpenVox 8. Commands, paths, and Forge modules remain; the repository does not.

Puppet describes the desired state of the machine — package installed, service running, file with this content — and the agent turns the difference into action. You do not write “how to install nginx on this distro”; you write that nginx must exist. The catalog handles the rest. In a large fleet, that is what separates a runbook from a contract.

What Puppet does (and does not do)

Created in 2005 by Luke Kanies, Puppet is a declarative configuration manager licensed under Apache 2.0. Each resource (package, file, service, user, cron…) is a fact about the node. The agent compares that fact with reality and applies only the delta. Idempotent: running it again does not break what is already correct.

This covers what the 2017 post listed — standardizing packages, services, and files across thousands of nodes, auditing drift, and restoring files through the filebucket. It does not cover what Ansible does better: ad-hoc plays, end-to-end orchestration, “run this command now on this group”. They are neighboring tools, not clones. The site's Ansible howto is at Automating Linux servers with Ansible.

Perforce's commercial product still exists (Puppet Enterprise). What disappeared from the open landscape was yum/apt.puppet.com for free across the entire fleet. Anyone who needs OSS in 2026 installs OpenVox — the stable series is 8, and 9.0.0-rc1 was released on September 4, 2026, still as a candidate.

The cycle: facts → catalog → apply → report

The design has not changed. The names have: the former “Puppet Master” is now openvox-server (formerlypuppetserver); the agent is the package openvox-agent, but the binary is still called puppet and lives in /opt/puppetlabs / /etc/puppetlabs.

nó (agente)
  1. coleta facts (os, memória, IP, discos, custom facts)
  2. envia facts ao servidor  ──►  openvox-server
  3. servidor compilou o catálogo deste certname
  4. agente recebe o catálogo  ◄──
  5. aplica recursos (ou --noop, só simula)
  6. manda relatório           ──►  openvoxdb (opcional)

Two modes, the same as in 2017:

  • puppet apply — local manifest, no server. Lab, bootstrap, single machine.
  • Agent / server — the node periodically requests the catalog (systemd timer or daemon). A real fleet.
# simula sem mudar nada
sudo puppet agent --test --noop

# aplica de verdade, verbose, uma vez
sudo puppet agent --test

# só local
sudo puppet apply /etc/puppetlabs/code/environments/production/manifests/site.pp

The old diagram in this post still mentioned Puppet Explorer and MCollective. Both have left the scene. Consoles/reports now go through OpenVoxDB, Foreman, or the agent's own report.

A minimal manifest

Everything in Puppet is a resource. The example below installs nginx, ensures the service is running, and triggers a restart if the file changes — the trio that handles 80% of “I want this daemon running”.

# site.pp (ou um profile)
package { 'nginx':
  ensure => installed,
}

file { '/etc/nginx/nginx.conf':
  ensure  => file,
  owner   => 'root',
  group   => 'root',
  mode    => '0644',
  source  => 'puppet:///modules/perfil/nginx.conf',
  require => Package['nginx'],
  notify  => Service['nginx'],
}

service { 'nginx':
  ensure => running,
  enable => true,
}

The language is the same as in the Brazilian community's workbook (puppet-br.github.io/apostila-puppet) and Forge modules: OpenVox 8.11+ is functionally equivalent to Puppet 8, so modules, Puppetfile and old books remain valid. What no longer remains valid is the package repository.

In 2026: install OpenVox, not apt.puppet.com

In late 2024, Perforce stopped publicly publishing OSS packages. Vox Pupuli (with Overlook InfraTech + OSUOSL hosting the mirror) began rebuilding and evolving the code as OpenVox. In June 2026, the agent is at 8.28; 9 is already in beta. Red Hat Satellite 6.19 documents OpenVox Server/Agent 8 and treats Puppet 7 as EOL. The puppet-puppet module from Foreman accepts the new package names.

Debian/Ubuntu still ship puppet-agent 8.10 in the distro archive — code without upstream support, Debian bug #1133413 / Ubuntu #2165065. OpenVox is more than fifteen releases ahead. Do not mix the two on the same system: the OpenVox package replaces Puppet. Before migrating, copy /etc/puppetlabs/ in its entirety.

# Ubuntu 24.04 / 26.04 — OpenVox 8
wget https://apt.voxpupuli.org/openvox8-release-ubuntu24.04.deb
sudo apt install ./openvox8-release-ubuntu24.04.deb
sudo apt update
sudo apt install openvox-agent

# Debian 12
wget https://apt.voxpupuli.org/openvox8-release-debian12.deb
sudo apt install ./openvox8-release-debian12.deb
sudo apt update
sudo apt install openvox-agent

# EL 9 (RHEL / Alma / Rocky)
sudo dnf install https://yum.voxpupuli.org/openvox8-release-el-9.noarch.rpm
sudo dnf install openvox-agent

Server, DB, and Bolt have the same prefix: openvox-server, openvoxdb, openbolt. Keyring: https://apt.voxpupuli.org/openvox-keyring.gpg. Official guide: voxpupuli.org/openvox/install. Docs: docs.openvoxproject.org.

Hiera for the Foreman module, if the OpenVox repository is already on the node:

puppet::client_package: openvox-agent
puppet::server_package: openvox-server

Puppet, Ansible, and the pipeline

A rule of thumb for Linux in 2026:

  • Puppet/OpenVox — continuous convergence. The node returns to the catalog's state on its own, hour after hour, even if someone “fixed it by hand”.
  • Ansible — orchestration and one-off plays. Pushes the change now, then leaves. Better for bootstrap, patch windows, and anything that does not need a daemon on the target.
  • CI/CD — tests the manifest/playbook in Git before the fleet receives it. The vocabulary is in DevOps: what CI/CD is.

Many people use both: Ansible (or cloud-init) installs the agent; OpenVox maintains the state from then on.

What still holds up from the 2017 list

  • Large fleet, small team — the catalog is the contract, not the wiki.
  • Filebucket — a file Puppet replaced remains recoverable.
  • --noop — simulates the run, generates the report, and does not touch the disk. Use it before promoting a new module.
  • Facts — the catalog is per node; os.family chooses the right package without if ubuntu scattered around.

What no longer holds up: the puppetlabs.com link for OSS downloads, the “master” group, MCollective as a bus, and the idea that apt install puppet-agent from the distro is keeping up with upstream.

Brazilian community: workbook at puppet-br.github.io/apostila-puppet and the puppetbr Telegram group. Fork code and issues: github.com/openvoxproject.