DEV Community: betadots

# OpenVox 9 ist da!

Martin Alfke — Fri, 09 Oct 2026 06:48:53 +0000

Am 2. Oktober 2026 hat die OpenVox-Project-Community das Release 9.0 von OpenVox veröffentlicht.
Damit basiert die Community-Version auf demselben Unterbau wie Puppet Core 9, das im August 2026 erschienen ist.

Der folgende Text ist eine Übersetzung mit kleineren Anpassungen vom Release Blog Posting.

Wir haben soeben OpenVox 9.0.0 veröffentlicht! Hierbei handelt es sich um eine Aktualisierung der Plattformbasis; das bedeutet, dass alle Kernabhängigkeiten auf aktiv gepflegte Versionen umgestellt wurden. Wer die jüngste Flut an CVE-Meldungen mit Sorge verfolgt hat, für den ist dieses Release genau das Richtige.

OpenVox 9 umfasst openvox-agent und openvoxdb in Version 9.0.0 sowie openvox-server in Version 9.0.1, ergänzt durch openfact 6.2.1.
(Das erste Release von openvox-server trägt die Nummer 9.0.1, da die Version 9.0.0 bereits durch ein Artefakt belegt war, das während der Beta-Phase versehentlich auf Clojars veröffentlicht worden war.)
Zudem wurde eine Reihe längst veralteter Code-Bestände entfernt.
Neue Funktionen sind für die Version 10.x geplant.

Release-Hinweise und Dokumentation

Die vollständigen Release-Hinweise, einschließlich Fehlerbehebungen und der Änderungen in den jeweiligen Vorabversionen, findet man hier:

openvox-agent: https://github.com/OpenVoxProject/openvox/releases/tag/9.0.0
openvox-server: https://github.com/OpenVoxProject/openvox-server/releases/tag/9.0.1
openvoxdb: https://github.com/OpenVoxProject/openvoxdb/releases/tag/9.0.0
openfact: https://github.com/OpenVoxProject/openfact/releases/tag/6.0.0 (OpenVox 9.0.0 enthält Version 6.2.1, die lediglich Fehlerbehebungen ergänzt)

Die Dokumentation zu OpenVox 9 findet man unter:

OpenVox: https://docs.openvoxproject.org/openvox/9.x/
OpenVox Server: https://docs.openvoxproject.org/openvox-server/9.x/
OpenVoxDB: https://docs.openvoxproject.org/openvoxdb/9.x/

OpenVox 9 beziehen

OpenVox-9-Pakete werden unter der Bezeichnung openvox9 bereitgestellt.
Um diese Repositories zu konfigurieren, muss das Paket openvox9-release installiert werden:

Pakete für macOS und Windows findet man unter:

Wenn Beta-Versionen oder Release-Candidates getestet wurden, gelanget man durch ein normales Paket-Upgrade zur finalen Version.
Vorabversionen enthielten eine Tilde in der Versionsnummer (z. B. 9.0.0~rc4), damit sie bei der Sortierung unterhalb der finalen Version eingeordnet wurden.

OpenVox 8 bleibt über die openvox8-Repositories verfügbar. Es wird weiterhin für mindestens sechs Monate wichtige Fehlerbehebungen und Sicherheits-Updates erhalten.
OpenVox-8-Agents können weiterhin mit OpenVox-9-Servern kommunizieren. Man muss nicht alles auf einmal umstellen.

Wichtigste Änderungen im Vergleich zu OpenVox 8

openvox-agent Ruby 4.0 (zuvor Ruby 3.2) und OpenSSL 3.5 LTS.
openvox-server verwendet JRuby 10.1, das mit Ruby 4.0 kompatibel ist. Dies ist ein Upgrade von JRuby 9.4, das mit Ruby 3.1 kompatibel war.
openvox-server und openvoxdb werden offiziell unter Java 21 und 25 unterstützt und getestet; die Unterstützung für Java 17 wurde eingestellt. Die Pakete laufen unter Java 25, sofern die Plattform dies bereitstellt, andernfalls unter Java 21. Die FIPS-Pakete laufen nur unter Java 21, da die Bouncy-Castle-FIPS-Bibliotheken nur bis Java 21 zertifiziert sind. Der Service nutzt jetzt den Paketpfad und nicht die Alternative (/usr/bin/java).
openvoxdb wird nun mit PostgreSQL 18 getestet.
openvox-agent enthält openfact 6; damit entfällt die Fact-Option ldapname, und es werden Warnungen zu künftigen Entfernungen (geplant für OpenVox 10) ausgegeben.

Vor dem Upgrade

Dies ist ein Major-Release mit Breaking Changes (Änderungen, die bestehende Konfigurationen oder Abläufe beeinträchtigen können).
Bitte die Release Notes vollständig durchlesen und die OpenVox 9.0.0 Release Notes beachten.

Die wichtigsten Informationen sind:

Der Standardwert für server ist nicht mehr puppet. Agents müssen server oder server_list konfigurieren oder SRV-Records verwenden (auch ca_server und report_server funktionieren für die jeweiligen Dienste). Ein Agent, der als Root ausgeführt wird, ohne dass eine dieser Optionen gesetzt ist, bricht mit einem Fehler ab.
Die Einstellung reports hat nun den Standardwert none anstelle von store. Setzen Sie reports = store auf Ihren Servern, wenn Sie darauf angewiesen sind, dass Berichte auf der Festplatte gespeichert werden.
Datenbindungen aus der Hiera-3-Ära sind entfallen. Die Einstellungen data_binding_terminus und environment_data_provider sowie der Hiera-3-Indirector-Terminus wurden entfernt; Hiera 5 ist der unterstützte Standard.
Java 21 ist nun erforderlich. Wenn die Dienste unter Java 17 starten, stürzen sie frühzeitig mit einer ClassNotFoundException für java.util.SequencedCollection ab.

Bekannte Probleme

Agent-Daemon kann gelegentlich beim Status „applying configuration“ hängen bleiben

Bei einer kleinen Anzahl von Nutzern wurde beobachtet, dass der puppet agent-Daemon keine Statusmeldungen mehr sendet, während ein per fork gestarteter Prozess mit der Bezeichnung puppet agent: applying configuration aktiv bleibt und sich nicht beendet (openvox#485).
Dies tritt selten auf: Die bisherigen Meldungen stammen von kleinen Linux-VMs mit nur einer vCPU, bei denen das Problem alle paar Tage auftrat.

Die Ursache ist eine seltene Race-Condition zwischen den Hintergrund-Threads für DNS-Auflösungen in Ruby (deren Verhalten sich in Ruby 3.3 und 3.4 geändert hat) und dem fork-Aufruf, der jeden Agent-Lauf einleitet.
Erfolgt der fork im ungünstigen Moment, übernimmt der Kindprozess eine gesperrte glibc-Resolver-Instanz (Mutex), wodurch jede Namensauflösung in diesem Kindprozess blockiert wird.
OpenVox 8 (Ruby 3.2) ist davon nicht betroffen.

OpenVox 9.0.0 enthält mehrere Änderungen, die die Wahrscheinlichkeit dieses Problems stark verringern und sicherstellen, dass sich der Daemon selbstständig erholt, sollte es dennoch auftreten:

Der Agent führt im Daemon keine Namensauflösungen mehr unmittelbar vor dem fork-Aufruf für einen Lauf durch (openvox#683); damit entfällt der in den Berichten identifizierte Auslöser.
Ein Lauf, der die Zeitvorgabe runtimeout überschreitet, wird nun beendet (abgebrochen), sodass der Daemon mit dem nächsten Lauf fortfahren kann (openvox#642, openvox#643).
openfact begrenzt die FQDN-Auflösung in seinen Hostname-Resolvern (openfact#177). Falls dieses Problem weiterhin auftritt, kann das Setzen von RUBY_TCP_NO_FAST_FALLBACK=1 in einer systemd-Override-Konfiguration für den puppet-Dienst die Häufigkeit des Auftretens verringern:

# systemctl edit puppet
[Service]
Environment=RUBY_TCP_NO_FAST_FALLBACK=1

Ein Neustart des puppet-Dienstes bereinigt keinen bereits hängengebliebenen Kindprozess; dieser muss mittels SIGKILL beendet werden.
Sollte das Problem bei Version 9.0.0 aufstoßen, bitte im Issue openvox#485 Informationen hinterlegen.

FIPS-Pakete enthalten ältere Bouncy-Castle-JAR-Dateien

Die FIPS-Builds von openvox-server und openvoxdb enthalten einen älteren Satz von Bouncy-Castle-FIPS-JAR-Dateien.
Die neueste Version der Bouncy-Castle-FIPS-1.x-Reihe weist ein kleines Problem auf, das in einer stark eingeschränkten Konfiguration (außerhalb der Standardeinstellungen) zu Schwierigkeiten führen könnte; daher führen wir kein Update auf diese Version durch.
Stattdessen wird OpenVox 9.1 auf die Bouncy-Castle-FIPS-2.x-Reihe umsteigen, welche für FIPS unter Java 21 vollständig zertifiziert ist.

Vielen Dank

OpenVox 9 würde ohne all jene nicht existieren, die Pull-Requests eingereicht, Fehler gemeldet, Vorabversionen getestet und an Diskussionen über anstehende Änderungen teilgenommen haben.
Vielen Dank an alle!

Ein besonderer Dank gilt den Personen, die in diesem Entwicklungszyklus einen Großteil der Arbeit geleistet haben, darunter unter anderem:

Tim Meusel für seine Arbeit an nahezu allen Repositories: Aktualisierungen von Laufzeitumgebungen und Abhängigkeiten, CI, Release-PRs sowie SBOMs.
Charlie Sharpsteen, für seine Arbeit an Server, Datenbank, Laufzeitumgebung und Build-Tools sowie für die umfassende Überarbeitung der Dokumentation („Great Docs Reset“).
Michael Harp, für den enormen Umfang an Dokumentationsarbeit – einschließlich der Unterlagen für Version 9.x – sowie für die Ermittlung der Ursache des oben beschriebenen Agenten-Hängers.
Nick Burgan, für den Ausbau der Release-Infrastruktur, Smoke-Tests sowie die Arbeit an der Paketierung für Java und FIPS.
Haroon Rafique, für die Pflege der Clojure-Komponenten von openvox-server und openvoxdb, FIPS-Korrekturen und mehr. Sichere Standardeinstellung für server.
Martin Alfke, für die Aktualisierung großer Teile der Dokumentation für OpenVox und OpenFact.
Robert Waffen, für die Neugestaltung der Container-Images und die Einführung von Multi-Plattform-Builds.
Ben Ford, für die „Getting-Started“- und „Quickstart“-Anleitungen, die Dokumentations-Tools sowie die Katalogvalidierung im Agenten.
Jerome Charaoui, für die Debian-Paketierung und Korrekturen zur Reproduzierbarkeit.
Josh Partlow, für die arm64-Unterstützung und weitere Arbeiten an den Abnahmetests.
Austin Blatt, für die Migration auf Jetty 12.
Chris Boot, für wochenlange, geduldige Debugging-Arbeit im Zusammenhang mit openvox#485.
Miranda Streeter, für die Verbesserungen der Startgeschwindigkeit der Container-Images.

Bei Fragen oder Problemen mit diesen Releases bitte im #openvox Channel auf Slack oder #voxpupuli-openvox im IRC melden.
Details findet man unter https://voxpupuli.org/connect/.

DevConf Tag 2

Marcus — Sat, 20 Jun 2026 07:43:19 +0000

Es ist 9Uhr morgens und der Kaffeestand hat mich vertröstet mit den Worten "Wir sind geschlossen, Eröffnung ist 09:30Uhr"

Unter dem einzigen schattenspenden Baum im Hof sammeln sich die Konferenzteilnehmer.

Ich habe mir einen glibc-Workshop und einen Quadlets-Workshop vorgenommen.

glibc-Workshop

Bild: A duck for a bug.

Aufgabe war: Ich habe hier 20 einfache Bugs in glibc heraus gesucht. Wir haben hier drei Mentoren, die an der glibc gearbeitet haben. Ich werde die Bugs jetzt an die Teilnehmer versteigern und wer als erster einen Patch einreicht, gewinnt die Ente.

Der Leiter scherzte noch: Mich hat die Vorbereitung acht Stunden gekostet. Wenn auch nur einer von euch dran bleibt und weiter Patches einreicht, habe ich ein beeindruckendes Verhältnis zwischen Aufwand und Nutzen erreicht. :-)
Leider ist glibc nicht so ruhmreich wie der Kernel und hat keine Vollzeitentwickler.

Podman-Quadlets Workshop

https://codeberg.org/inknos/DevConf26/src/branch/main/demo/01_wordpress/03/README.md

Die Demos waren schön und zeigen, wie man von Docker-Compose auf Podman kommt oder von Quadlets auf Kubernetes oder von Kubernetes auf Quadlets. Quadlets haben Potential, wenn sie etwas Liebe erfahren.

Podman Quadlets funktionieren unter Debian nicht. Dafür habe ich mit einem der RedHat-Entwickler gemeinsam einen Bug-Report erstellt. Am Workshop teilgenommen habe ich mit einer Fedora-VM.
Der Theorie nach bringt Podman in Form von podman machine init und podman machine start eine VM mit, die quadletfähig sein soll, aber die ist unter Debian ebenfalls defekt.

DevConf: Tag 1

Marcus — Thu, 18 Jun 2026 07:54:44 +0000

Die Genese der DevConf: RedHat hat seinen europäisches Hauptquartier in Brno/Tschechien.

Möchtest du life mitschauen? https://www.youtube.com/@DevConfs

Ich möchte die vergangenen Vorträge dokumentieren:

09:00 Einleitung:

Wenn ihr zum ersten Mal hier seid, nehmt die Karte und probiert die Räume ohne Hilfe zu finden https://www.devconf.info/cz/map/

09:30 CVE-Vortrag. RedHat hat ein Rolling-Container-Release mit AI gebaut, sie nennen es "Hummingbird".
"If you have to explain it [CVEs to your manager], you have already lost"
Publikumsfrage: Was ist der Unterschied zwischen Hummingbird und Renovate? -- Beide lösen das gleiche Problem, Hummingbird benutzt Renovate im Hintergrund.

10:15 bpftrace Viktor@RedHat
Ich habe mich spontan daran erinnert, warum ich BPF-Trace verworfen habe. Es hat ein paar sehr nischige High-Level-Anwendungsfälle. Der Maintainer hat das Acknowledged und kündigt Erweiterungen an:

Macros
Libraries and Imports
C-Interoperation

11:00 HTTP3 und Quick Evolution
https://www.goodreads.com/quotes/215637-simplicity-is-a-great-virtue-but-it-requires-hard-work

OpenVox rootless Alpine Containers

Robert Waffen — Fri, 12 Jun 2026 13:42:44 +0000

Over the last weeks, I spent a lot of my Open Source time at betadots GmbH working on improving the OpenVox containers.

The result: both openvoxserver and openvoxdb are now regularly published as Ubuntu and Alpine based container images 🎉

The PRs

This may sound like a small packaging change at first glance, but it actually opens the door for several different deployment styles and operational preferences.

Some users prefer Ubuntu based images for compatibility, familiarity and enterprise environments. Others want the smaller Alpine footprint, faster pulls and a more minimal runtime environment.

How I got there

Building the Alpine containers was a significant challenge because we don’t have packages here. Building Alpine packages would have been another nightmare to solve. So, I looked into the build scripts for the Ubuntu/RHEL packages and extracted all the necessary steps to get the server running. Ideally, I thought, "That’s only a JAR, how complicated can this be? Containers are made for running JARs!" But I couldn’t have been further from the truth. The OpenVox JARs are not self-running and depend on a lot of files and directories being in the right place. Getting this working was a bit of a hassle! But in the end, I got all the steps together, and the containers were building and even starting! They were working! Then, I had to do it rootless. So, we figured out every place where a chmod or chown is made and got this out of the starting process. It wasn’t easy! But we solved it in the end. With much help from the community!

Rootless containers in detail 🥷🐳

One particularly exciting part: the Alpine images are already fully rootless.

That means they are prepared to run without root privileges inside the container, improving the security posture and aligning better with modern container best practices.

The Ubuntu variants are expected to follow soon as the remaining changes are being worked on.

Rootless containers are one of those things that feel a bit like upgrading from telnet to SSH. Once the ecosystem is ready for it, going back feels strange.

Community powered Open Source ❤️

Even though I implemented most of the changes during my Open Source time at betadots GmbH, this was absolutely not a solo effort.

There were reviews, discussions, testing, feedback and many tiny details coming from the OpenVox community. Open Source thrives when individuals collectively contribute their ideas, refining them until the final product surpasses the original draft.

Huge thanks to everyone involved 🙌

Why this matters

Infrastructure projects are often built from many small building blocks:

container images
CI pipelines
packaging
runtime security
multi-distro support
rootless compatibility

Individually, these changes may seem minor.

But together they make the ecosystem more flexible, more secure and easier to integrate into different environments, from homelabs to enterprise deployments.

What’s next?

There is still more work ahead around rootless support, image hardening and ecosystem improvements, but this is another nice milestone for OpenVox containers.

Feedback, testing and contributions are always welcome.

Open Source is still one of the few places where random people on the internet collectively assemble giant infrastructures out of YAML, shell scripts and sleep deprivation 🤖✨

Cheers, Robert

puppet-checkmk dusted off 🧹🦊

Marcus — Fri, 12 Jun 2026 08:47:43 +0000

VoxPupuli's puppet-checkmk [1][2] had become invisible on the Puppet Forge. [3] The Forge has a simple filter: No updates for a long time? Hide it!

Since we hadn't put out a release in a while, we got dropped off the Forge. We've fixed that: dusted off the metadata and added modern operating systems (RedHat-10, Debian-13) to the test matrix.

As sysadmins may guess, there were some quirks with EPEL. I am looking at you, Oracle Linux! ;-) [4]

[1] https://github.com/voxpupuli/puppet-check_mk
[2] https://forge.puppet.com/modules/puppet/check_mk/readme
[3] https://forge.puppet.com/modules?q=check_mk
[4] https://github.com/voxpupuli/puppet-nginx/blob/master/spec/spec_helper_acceptance.rb#L5-L13

puppet-checkmk entstaubt 🧹🦊

Marcus — Fri, 12 Jun 2026 08:47:42 +0000

VoxPupulis puppet-checkmk [1][2] war in der Puppet-Forge unsichtbar geworden. [3]
Die Forge hat einen schlichten Filter: >FIXNUM Zeit kein Update erhalten? Ausblenden!

Wei wir schon lange kein Release mehr veröffentlicht haben, sind wir aus der Forge gefallen. Wir haben das behoben: Metadaten entstaubt und moderne Betriebssysteme (RedHat-10, Debian-13) in die Test-Matrix eingefügt.

In guter Sysadmin-Gewohnheit gab es Freude mit EPEL. Du bist gemeint, Oracle-Linux! ;-) [4]

Puppet Enterprise - Neue Releases und Upgrade Zyklen

Martin Alfke — Wed, 08 Apr 2026 13:59:44 +0000

Bisher gab es bei Puppet Enterprise 2 unterschiedliche Support Releases:

LTS - Long Term Support und
STS - Standard (oder Short) Term Support

Die LTS Releases hatten üblicherweise 2 bis 3 Jahre Support, bevor man ein Upgrade durchführen musste.
Bei STS Releases bezog sich der Support nur auf das jeweils letzte Release.

Mit Puppet Enterprise 2026 (Release ist angekündigt für August 2026) hat Perforce die Support Matrix überarbeitet.
Der neue Support Zyklus wird als Latest / Latest-1 bezeichnet.

In diesem Posting werden die wesentlichen Unterschiede dargestellt und was man in Zukunft bei der Nutzung von Puppet Enterprise berücksichtigen sollte.

Latest

Mit Latest wird das jeweils aktuelle Puppet Enterprise Major Release bezeichnet.
Aktuell ist dies das letzte Release von PE 2025.

Mit dem Release von PE 2026, wird PE 2026 das Latest Support Release.

Latest Releases haben einen vollständigen Support über einen Zeitraum von 12 Monaten.
Innerhalb dieses Zeitraumes sind neue Features und Verbesserungen, Sicherheitsupdates und Fehlerkorrekturen im Support verfügbar.

Danach gibt es in der Folge Minor Releases, die vierteljährlich zur Verfügung gestellt werden.

Latest-1

Als Latest-1 wird das jeweilige vorherige Release bezeichnet, nachdem eine neue Major Version veröffentlicht wurde.

Wenn PE 2026 released wird, wird das PE 2025 Release zu Latest-1.

Latest-1 Releases haben einen eingeschränkten Support über einen Zeitraum von 12 Monaten.
Innerhalb dieses Zeitraumes sind nur Sicherheitsupdates und Fehlerkorrekturen im Support verfügbar.

aktuelles LTS Releases

Das aktuelle LTS Release von Puppet Enterprise ist die Version 2023.8.
Mit dem Release von PE 2026 wird diese Version nicht mehr unterstützt.

Alle anderen älteren Puppet Enterprise Releases sind nicht mehr im Support enthalten.
Wenn eine ältere Puppet Enterprise Version als PE 2025 im Einsatz ist, sollte unbedingt ein Upgrade geplant und durchgeführt werden. Welche Upgrades möglich sind, ist in der Dokumentation zu Puppet Enterprise Upgrades hinterlegt.

Releases und Support Zeitraum

Stand 08.04.2026

PE Version	Support Beginn	Support Name	Support Umfang	Support Ende
2023.8.x	aktuell	LTS	Vollständiger Support	08/2026
2023.8.x	08/2026	LTS	eingeschränkter Support	02/2027
2025.x	aktuell	Latest	Vollständiger Support	08/2026
2025.x	08/2026	Latest-1	eingeschränkter Support	08/2027
2026.x	08/2026	Latest	Vollständiger Support	??/2027
2026.x	??/2027	Latest-1	eingeschränkter Support	??/2028
2027.x	??/2027	Latest	Vollständiger Support	??/2028
2027.x	??/2028	Latest-1	eingeschränkter Support	??/2029
2028.x	??/2028	Latest	Vollständiger Support	??/2029

Zusammenfassung

Perforce entwirrt und standardisiert die Support Zyklen.
Mit den jährliche Major Releases und definierten Zeiträumen für den eingeschränkten Support können Kunden innerhalb von 24 Monaten ein Update durchführen, ohne den Support zu verlieren.

Bei der Vorbereitung und Durchführung von Updates unterstützen wir unsere Kunden gern.

How to keep your Puppet modules up to date with Renovate

Robert Waffen — Wed, 25 Mar 2026 16:14:50 +0000

Managing a Puppet control repository with a growing list of dependencies can quickly become a challenge.
Keeping everything up to date manually?
That’s not just tedious — it’s also error-prone.

Modules are updated frequently, sometimes daily.
With a long list of dependencies, it’s easy to miss important updates.
And let’s be honest: humans are not exactly known for perfect consistency when it comes to repetitive tasks.

So why not let a bot handle it?

Why Renovate?

Renovate is designed to take over exactly this kind of work.
It continuously scans your repositories, detects dependency updates, and automatically creates merge requests for you — including changelogs.

Instead of manually checking versions, you simply review and merge PRs.
Much cleaner.
Much safer.

Assumptions

Before we get started, this setup assumes:

Your repositories are hosted on GitLab
You are using GitLab CI with runners
You can run container-based jobs

Setting Up Renovate

Create a Renovate Runner Repository

Create a dedicated repository in GitLab, for example: renovate-runner

Inside this repository, create a config.js file:

module.exports = {
  autodiscover: false,
  dependencyDashboard: true,
  // We only enable the puppet manager here
  // see all managers: https://docs.renovatebot.com/modules/manager/
  enabledManagers: ['puppet'],
  // GitLab API - update with your instance URL
  endpoint: 'https://gitlab.example.com/api/v4/',
  extends: ['config:base', ':semanticCommits', ':semanticCommitTypeAll(chore)'],
  labels: ['renovate', 'dependencies'],
  platform: 'gitlab',
  prCreation: "immediate",
  prHourlyLimit: 20,
  repositories: ['puppet/control-repo'],
  requireConfig: true,
  reviewers: ['@rwaffen'],
  token: process.env.RENOVATE_TOKEN
};

This configuration will create one merge request per dependency update.

If you prefer grouped updates, you can extend it like this:

packageRules: [
  {
    matchManagers: ["puppet"],
    groupName: "{{manager}}",
  }
]

Add GitLab CI Configuration

Create a .gitlab-ci.yml:

---
run_renovate:
  image:
    name: ghcr.io/voxpupuli/renovate:latest
    entrypoint: [""]
  resource_group: production
  script:
    - renovate $RENOVATE_EXTRA_FLAGS
  only:
    - schedules
    - triggers
    - web
  # variables:
  #   LOG_LEVEL: debug

Running Renovate

With everything in place, you can trigger a pipeline in your renovate-runner repository.

Once started, Renovate will take over and handle the full update cycle for you:

It launches the Renovate container
Authenticates using your configured token
Scans the defined repositories
Detects dependency files such as Puppetfile
Resolves current versions and checks for new releases or tags
Creates merge requests whenever updates are available

At this point, your role shifts from maintainer to reviewer:
you simply go through the generated merge requests and decide what to merge.

To make this process truly hands-off, you should also configure a scheduled pipeline in GitLab.
This ensures Renovate runs regularly and keeps your dependencies continuously up to date — without any manual triggering.

Authentication: `RENOVATE_TOKEN`

Renovate requires a Personal Access Token (RENOVATE_TOKEN) to interact with your repositories.

Required permissions:

api
write_repository

It is highly recommended to create this as a group access token, so Renovate can access all relevant repositories — especially important if your Puppetfile includes Git-based modules.

Choosing the Right Container Image

Renovate provides official container images, but they come with some trade-offs:

Large size
Based on Ubuntu
Higher number of known vulnerabilities (CVEs)

Vox Pupuli provides a leaner alternative:

Smaller footprint
Based on Alpine
Significantly fewer vulnerabilities

IMAGE                                 ID             DISK USAGE   CONTENT SIZE   EXTRA
ghcr.io/renovatebot/renovate:latest   0334065a0093       1.87GB          416MB
ghcr.io/voxpupuli/renovate:latest     e354b2af781c        726MB          132MB

Vulnerability Scan (grype)

grype ghcr.io/renovatebot/renovate:latest

 ✔ Scanned for vulnerabilities     [297 vulnerability matches]
   ├── by severity: 1 critical, 10 high, 971 medium, 137 low, 15 negligible
   └── by status:   14 fixed, 1120 not-fixed, 837 ignored

grype ghcr.io/voxpupuli/renovate:latest

 ✔ Scanned for vulnerabilities     [19 vulnerability matches]
   ├── by severity: 0 critical, 15 high, 4 medium, 0 low, 0 negligible
   └── by status:   13 fixed, 6 not-fixed, 0 ignored

Final Thoughts

With Renovate in place, dependency management becomes predictable and automated.
Instead of chasing updates manually, you get a steady stream of structured merge requests — complete with context and changelogs.
In other words: less chaos, more control.

🧩 Puppet Module Update Process

Robert Waffen — Fri, 11 Jul 2025 07:59:30 +0000

🔍 1. Identify and Analyze the Module

Extract a module name from the Puppetfile.
Search for the module on Puppet Forge.
Compare available versions and identify the latest one.

📝 2. Review Changes in the Module

Follow the Project URL on the Forge page to the GitHub repository.
Check recent changes under Releases or in the Changelog.

Example:

⚠️ 3. Watch for Breaking Changes

Possible breaking changes:
- Removal of support for EOL software
- API changes
- Renamed parameters or variables
Note: Not every breaking change will affect your setup.
- Example: Dropping EL6 support likely doesn’t concern you.

🔍 4. Evaluate Other Changes

Linked pull requests (PRs) may offer additional insights.
Check whether changes are understandable and whether breaking changes apply to your environment.

🌱 5. Integrate into Development Branches

If the module is considered ready for update:
- Integrate into a feature or development branch.

🌲 6. Control Repo Branch Structure

Typically present:

development
production
Optionally: staging before production
Additionally: 0–n feature branches

🧪 7. Testing in Development Environment

Test the updated module in a suitable environment (VM, container).
Observe how it interacts with other modules.

Possible findings:

Dependencies on specific module versions
New facts writing additional data to PuppetDB
New or modified parameters requiring Hiera data

🔄 8. Forward the Change

Once all adjustments are complete:
- Pass the change to the next branch for further testing or rollout preparation.

🤖 9. Automation with Renovate Bot

This process is quite detailed and time-consuming.
With Renovate Bot, collecting and reviewing relevant updates becomes much easier.
Renovate can be integrated into GitLab or GitHub.
It works similarly to GitHub’s built-in Dependabot, but is more flexible and configurable.

🧰 10. Automation with VoxBox

You can also try using the Vox Pupuli VoxBox to list all dependencies for the entire control repo.
- This doesn't work with every setup.
- If there are private modules in the Puppetfile, the person running the command must have access to them.
- Example command:
- podman run -it --rm -v $PWD:/repo:Z ghcr.io/voxpupuli/voxbox:latest r10k:dependencies
More useful information can be found in the Vox Pupuli VoxBox documentation

🧩 Puppet Modul Update Prozess

Robert Waffen — Fri, 11 Jul 2025 07:58:40 +0000

🔍 1. Modul identifizieren und analysieren

Einen Modulnamen aus dem Puppetfile entnehmen.
In der Puppet Forge nach dem Modul suchen.
Verfügbare Versionen vergleichen und die neueste identifizieren.

📝 2. Änderungen im Modul prüfen

Über den Link zur Project URL auf der Forge-Seite zum GitHub-Repository wechseln.
Dort unter Releases oder im Changelog die letzten Änderungen prüfen:

Beispiel:

⚠️ 3. Auf Breaking Changes achten

Mögliche Breaking Changes:
- Entfernung der Unterstützung für EOL-Software
- Änderungen an der API
- Umbenennung von Variablen
Hinweis: Nicht jede Breaking Change ist für jedes Setup relevant.
- Beispiel: Der Entfall von EL6-Support betrifft euch vermutlich nicht.

🔍 4. Sonstige Änderungen bewerten

Auch verlinkte Pull Requests (PRs) können Aufschluss geben.
Prüfen, ob Änderungen nachvollziehbar sind und keine Breaking Changes enthalten, die euch betreffen.

🌱 5. Aufnahme in Entwicklungszweige

Wenn das Modul als updatefähig eingeschätzt wird:
- Aufnahme in einen Feature- oder Development-Branch

🌲 6. Branch-Struktur im Control-Repo

Typischerweise vorhanden:

development
staging
production
Zusätzlich: 0–n Feature-Branches

🧪 7. Tests in Entwicklungsumgebung

Test des neuen Moduls in geeigneter Umgebung (VM, Container)
Beobachtung des Zusammenspiels mit anderen Modulen

Mögliche Erkenntnisse:

Abhängigkeit zu anderen Modul-Versionen
Neue Facts, die zusätzliche Daten in die PuppetDB schreiben
Neue oder geänderte Parameter, die Hiera-Daten erfordern

🔄 8. Change weiterreichen

Wenn alle Anpassungen erledigt sind:
- Übergabe des Changes in den nächsten Branch zur weiteren Prüfung oder Vorbereitung für den Rollout.

🤖 9. Automatisierung mit Renovate Bot

Dieser Prozess ist sehr kleinteilig und kann zeitaufwendig sein.
Mit Hilfe von Renovate Bot lässt sich das Sichten und Sammeln der relevanten Informationen deutlich erleichtern.
Renovate ist ein Bot, der sich in GitLab oder GitHub integrieren lässt.
Er funktioniert ähnlich wie der GitHub-eigene Dependabot, ist aber deutlich flexibler und konfigurierbarer.

🧰 10. Automatisierung mit VoxBox

Man kann auch versuchen mit der Vox Pupuli Voxbox die Abhängigkeiten für das gesamte Control-Repo anzeigen zu lassen.
- Das klappt nicht bei jedem Setup.
- Wenn im Puppetfile private Module sind, muss der jenige der es ausführt, Zugriff auf diese haben.
- Beispielbefehl:
- podman run -it --rm -v $PWD:/repo:Z ghcr.io/voxpupuli/voxbox:latest r10k:dependencies
Weitere nützliche Informationen gibt es in der Vox Pupuli VoxBox Dokumentation

Das neue Puppet Open Source Projekt heißt "OpenVox"

Martin Alfke — Tue, 28 Jan 2025 15:00:38 +0000

Puppet by Perforce hat angekündigt,
dass die Open Source Pakete ab 2025 nur noch nach Zustimmung einer nicht weiter definierten EULA verfügbar gemacht werden sollen.

In early 2025, Puppet will begin to ship any new binaries and packages developed by our team to a private, hardened, and controlled location. Community contributors will have free access to this private repo under the terms of an End-User License Agreement (EULA) for development use.

Dabei muss berücksichtigt werden, dass die kostenfreie Variante nur für maximal 25 Nodes gilt.
Wer mehr Systeme mit Puppet Open Source verwalten will, benötigt eine Puppet Labs Support Commercial License.

Die Open Source Community hat das Gespräch mit dem Puppet Management gesucht.

Hier das Resultat:

Das neue Puppet Open Source Projekt heißt OpenVox
- Vorbereitung
- Aus Puppet wird OpenVox und Puppet Open Source
- Source Code, Pakete und Container
- Ich nutze Puppet Open Source. Was muss ich tun?
- Puppet Open Source
- OpenVox
- Die weitere Entwicklung
- Wie kann man helfen?
- Professioneller Support
- Zusammenfassung

Vorbereitung

Vor dem ersten Gespräch mit Puppet hat sich die Community im Vorfeld besprochen und analysiert, ob man als Open Source Projekt in der Lage sein kann, die weitere Entwicklung zu stemmen.
Das Feedback aus der Open Source Community und von Open Source Usern war sehr positiv.

Einige Nutzer haben sogar direkt angekündigt, dass man Entwickler für dedizierte Aufgaben zur Verfügung stellen möchte.

Aus Puppet wird OpenVox und Puppet Open Source

Die Open Source Community hat sich mit Puppet by Perforce darauf geeinigt, dass die weitere Entwicklung von Puppet in einem Fork unter der Verwaltung der Open Source Community erfolgen soll.

Nach einer öffentlichen Abstimmung Ende 2024 innerhalb der Community, hat man sich für den Namen OpenVox entschieden und beschlossen, dass die Entwicklung innerhalb der bereits existierenden Vox Pupuli Puppet Open Source Community auf GitHub stattfinden soll.

Da Perforce die Namensrechte an Puppet besitzt, hat man gemeinsam mit Perforce entschieden, dass die Pakete, die durch das OpenVox Projekt erstellt werden, nicht mehr Puppet im Namen haben sollen.
Dies ist auch in Hinsicht auf Differenzierbarkeit der Herkunft der Pakete sinnvoll.
Die Open Source Pakete von Perforce werden weiterhin puppet-agent, puppetdb und puppetserver heißen.

Gemeinsam mit Perforce wurde vereinbart, dass man sowohl die Kommandozeile, wie auch Namen der Konfigurationsdateien und die Schnittstellen zur Erweiterung von Puppet ( /lib/puppet in Modulen) zu existierenden Installation und Code kompatibel halten möchte.

Die weitere Kompatibilität soll durch ein Language Steering Committee sichergestellt werden, in dem alle Beteiligten gemeinsam über Änderungen an der Puppet DSL oder Inkompatibilitäten entscheiden.

Source Code, Pakete und Container

Der frei verfügbare Puppet Open Source Code wurde in das OpenVox GitHub Projekt geforkt.

Im ersten Schritt hat das Re-branding stattgefunden.
Für Anwender ist es wichtig zu wissen, dass Kommandozeilen Tools, Bibliotheken und Puppet Erweiterungen auch unter OpenVox vollständig kompatibel zu Puppet Open Source sind.

Aktuell werden die Pipelines zur Erstellung der RedHat und Debian Pakete auf öffentliche GitHub Actions umgestellt und sollen sehr bald zur Verfügung gestellt werden.
Erste reproduzierbare Build wurden bereits getetstet.
Pakete für Windows und MacOS sind ebenfalls geplant.

Die Puppet Container (puppetserver und puppetdb) werden nicht mehr weiter gepflegt!

Statt dessen werden OpenVox Container zur Verfügung gestellt. Aktuell wird an OpenVox Server und OpenVoxDB gearbeitet.

Ich nutze Puppet Open Source. Was muss ich tun?

Es gibt 2 Möglichkeiten:

Puppet Open Source
OpenVox

Puppet Open Source

Man muss bei Puppet die EULA akzeptieren und sich ab 25 Nodes um eine Lizenz kümmern.

OpenVox

Die Installations-Anleitung für die Migration findet man auf der
OpenVox Projekt Seite.

Da die Konfigurationspfade und -dateien, sowie die Kommandos alle identisch sind, muss keine weitere Anpassung oder Umstellung vorgenommen werden.
Auch der existierende Puppet Code funktioniert ohne Anpassungen.

Nutzer von OpenVox werden gebeten die aktuellen Pakete und Container in einer Testumgebung zu validieren.

Die weitere Entwicklung

Es gibt eine ganze Reihe von Wünschen aus der Community, die bisher leider nicht umgesetzt wurden.
Zuerst möchte man aktuelle Betriebssystemversionen unterstützen. Hierbei hatte die Community oft nach Paketen für Debian stable und testing gefragt.

Im nächsten Schritt soll der Code von alten Artefakten befreit werden.
Nicht mehr gepflegte Ruby Erweiterungen sollen durch moderne Implementierungen ersetzt werden.
Der Code Zoo (Jruby, Clojure, Java) soll aufgeräumt werden.

Wie kann man helfen?

Die Puppet Community möchte sich als Professionelles Open Source Projekt etablieren.
Dazu sucht man die finanzielle Unterstützung von Usern, Firmen und öffentlichen Einrichtungen für Open Source Arbeit.

Auch individuelle Zuarbeit ist gerne gesehen. Es muss Dokumentation geschrieben werden, die Pakete müssen getestet werden.
Die Community braucht die Unterstützung der Anwender, sei es durch Zuarbeit, Code Reviews oder Bug Reports.

Im nächsten Schritt benötigt man Spiegel Server, Bandbreite und Storage.

Professioneller Support

Open Source Support ist für viele Kunden ein wichtiger Aspekt bei der Wahl der Mittel.
Für OpenVox gibt es bereits jetzt schon 2 Firmen, die Support anbieten:

Wir von der betadots GmbH unterstützen Kunden bei Planung, Installation, Updates von OpenVox, Puppet Open Source und Puppet Enterprise und kümmern uns um die Weiterbildung der Mitarbeiter im Umfeld von Git und GitLab, Foreman/Katello, Puppet/OpenVox und Linux HA.

In Amerikanischem Raum wird die Firma overlookinfratech Ansprechpartner für OpenVox Support sein.

Weitere Firmen werden auf der Support Übersicht von OpenVox gelistet werden.

Zusammenfassung

OpenVox ist ein drop-in Ersatz für Puppet Open Source.

Die Community hat gezeigt, dass sie den Wunsch nach Weiterentwicklung hat und in der Lage ist diese Arbeiten durchzuführen.

Professioneller Support und Trainings stehen in den USA und in Europa zur Verfügung.

Open Source ist die Basis für den Erfolg vieler Unternehmen. Deshalb: Unterstützt Eure Community.

Für weitere Informationen stehen wir gerne zur Verfügung.

Datacenters need automation

betadots GmbH

The Ruby side of Puppet - Part 3 - Custom Types and Providers

Martin Alfke — Mon, 20 Jan 2025 18:50:29 +0000

This is the final post in a three-part serie, covering the concepts and best practices for extending Puppet using custom facts, custom functions and custom types and providers.

Part 1 explores how to create custom facts, which allow nodes to send information to the Puppet Server.

Part 2 discusses building custom functions to process data or execute specific tasks.

Part 3 (this post) focuses on custom types and providers, allowing you to extend Puppet's DSL and control system resources.

Types are at the core of Puppet’s declarative DSL. Types describe the desired state of the system, targeting specific, configurable parts (sometimes OS-specific). Puppet provides a set of core types, available with any Puppet agent installation.

Some of the core types include:

file
user
group
package
service

Why Create Custom Types and Providers:

There are several reasons to develop custom types and providers:

Avoid relying on the often unreliable or hard-to-maintain exec resources
Manage an application that requires CLI commands for configuration.
Handle configurations with highly specific syntax that existing Puppet types cannot manage (like file or concat).

Content:

General concepts
Types and providers in modules
Type description
Provider implementation
Using custom types in Puppet DSL
Resource API
Summary

General concepts

A custom type consists of two main parts:

Type definiton: This defines how the type will be used in the Puppet DSL.
Provider implementation(s): One or more providers per type define how to interact with the system to manage resources.

Type definition

The type describes how Puppet resources are declared in the DSL. For example, to manage an application’s configuration:

app_config { <setting>:
  ensure   => present,
  property => <value>,
  param    => <app_args>,
  provider => <auth_method>,
}

In the type definition, you typically have a namevar (a key identifier) and mutiple parameters and properties.

Namevar: The key identifying the resource instance in the type declaration.
Properties: These represent something measurable on the target system, such as a user’s UID or GID, or an application’s config value.
Parameters: Parameters influence how Puppet manages a resource but don’t directly map to something measurable on the system. For example, manage_home in the user type is a parameter that affects Puppet’s behavior but isn’t a property of the user account.

The difference between parameters and properties is nicely described on the Puppet Type/Provider development page:

Properties:

"Properties correspond to something measurable on the target system. For example, the UID and GID of a user account are properties, because their current state can be queried or changed. In practical terms, setting a value for a property causes a method to be called on the provider."

Parameters:

"Parameters change how Puppet manages a resource, but do not necessarily map directly to something measurable. For example, the user type’s managehome attribute is a parameter — its value affects what Puppet does, but the question of whether Puppet is managing a home directory isn’t an innate property of the user account."

In our example, the property is the value of the config setting, whereas the parameter specifies application attributes.

Provider implementations

Providers define the mechanisms for managing the state of the resources described by types. They handle:

Determining whether the resource already exists.
Creating or removing resources.
Modifying resources.
Optionally, listing all existing resources of the type.

Types and providers in modules

Custom types and providers are placed within the lib/puppet directory of a module.

The type file is located in lib/puppet/type and named after the resource type (app_config.rb in this case).
Provider implementations go into the lib/puppet/provider directory, inside a subdirectory named after the resource type. Each provider is named according to its provider implementation (e.g., ruby.rb, cli.rb, cert.rb, token.rb, user.rb)

For example:

Type: app_config
Providers:
- cert
- token
- user

# <modulepath>/<modulename>
modules/application/
    \- lib/
        \- puppet/
            |- type/
            |    \- app_config.rb
            \- provider/
                \- app_config/
                    |- cert.rb
                    |- token.rb
                    \- user.rb

Type description

New custom types can be crated using two different API versions.
APIv1 is the old, classic way using getters and setters within the providers.
APIv2 is a new implementation which is integrated into PDK - this implementation is also called Resource API.

In the next section we introduce the APIv1 implementation. The Resource API implementation is handled later in this document.

APIv1

The traditional method uses Puppet::Type.newtype, which defines the type.
It is recommended to add the type documentation into the code.
This allows users to run puppet describe <type> on their system to display the documentation.

# lib/puppet/type/app_config.rb
Puppet::Type.newtype(:app_config) do
  @doc = %q{Manage application config. There are three ways
    to authenticate: cert, token, user. cert is the default
    provider.

    Example:

      app_config: { 'enable_logging':
        ensure   => present,
        value    => true,
      }
  }
  # ... the code ...
end

Management

The most important feature of a type is to add or remove something from the system.
This is usually handled with the ensure property.
To enable ensure, a single line is needed: ensurable

# lib/puppet/type/app_config.rb
Puppet::Type.newtype(:app_config) do
  @doc = %q{Manage application config. There are three ways
    to authenticate: cert, token, user. cert is the default
    provider.

    Example:

      app_config: { 'enable_logging':
        ensure   => present,
        value    => true,
      }
  }
  ensurable
end

Namevar

When declaring the type, one must specify a title - one could refer to this as a type instance identifier.
Usually this reflects for something the type is managing.

user { 'betadots': # <- title
}

The most simple implementation is to add a parameter with the name :name.

# lib/puppet/type/app_config.rb
Puppet::Type.newtype(:app_config) do
  @doc = %q{Manage application config. There are three ways
    to authenticate: cert, token, user. cert is the default
    provider.

    Example:

      app_config: { 'enable_logging':
        ensure   => present,
        value    => true,
      }
  }
  ensurable
  newparam(:name) do
    desc "The app config setting to manage. see app_cli conf --help"
  end
end

Passing the namevar: true key to the parameter is another way to identify a namevar:

newparam(:key, namevar: true) do
  desc 'The app config setting key to manage. see app_cli conf --help'
end

Properties

Next we add the other property. Each property can be validated by its content.
In our demo case we expect a string value.

# lib/puppet/type/app_config.rb
Puppet::Type.newtype(:app_config) do
  @doc = %q{Manage application config. There are three ways
    to authenticate: cert, token, user. cert is the default
    provider.

    Example:

      app_config: { 'enable_logging':
        ensure   => present,
        value    => true,
      }
  }
  ensurable
  newparam(:name) do
    desc "The app config setting to manage. see app_cli conf --help"
  end
  newproperty(:value)do
    desc "The config value to set."
    validate do |value|
      unless value =~ /^\w+/
        raise ArgumentError, "%s is not a valid value" % value
      end
    end
  end
end

Besides this one can provide specific valid values which are validated automatically:

newproperty(:enable) do
  newvalue(:true)
  newvalue(:false)
end

Please note that arrays as property values are validated in a different way:

From Puppet custom types website:

By default, if a property is assigned multiple values in an array:

It is considered in sync if any of those values matches the current value.

If none of those values match, the first one is used when syncing the property.

If all array values should be matched, the property needs the
array_matchingto be set to :all. The default value is :first

newproperty(:flags, :array_matching => :all) do
  # ...
end

Accessing values can be done in two ways:

should for properties, value for parameters
value for both, properties and parameters

We prefer to use the explizit methods as this makes it more clear, whether we deal with a property or a parameter.

Parameters

Parameters are defined in a similar way:

# lib/puppet/type/app_config.rb
Puppet::Type.newtype(:app_config) do
  @doc = %q{Manage application config. There are three ways
    to authenticate: cert, token, user. cert is the default
    provider.

    Example:

      app_config: { 'enable_logging':
        ensure   => present,
        value    => true,
        cli_args => ['-p'], # persistency
      }
  }
  ensurable
  newparam(:name) do
    desc "The app config setting to manage. see app_cli conf --help"
  end
  newproperty(:value) do
    desc "The config value to set."
    validate do |value|
      unless value =~ /^\w+/
        raise ArgumentError, "%s is not a valid value" % value
      end
    end
  end
  newparam(:cli_args, :array_matching => :all) do
    desc "CLI options to use during command execution."
    validate do |value|
      unless value.class == Array
        raise ArgumentError, "%s is not a an array" % value
      end
    end
    defaultto ['-p']
  end
end

Boolean parameters

Parameter which get a bool value should be handled in a different way to avoid code repetition

require 'puppet/parameter/boolean'
# ...
newparam(:force, :boolean => true, :parent => Puppet::Parameter::Boolean)

Automatic relationships

Within the type we can specify soft dependencies between different types.

E.g. the app_cli should use a user which must be available on the system

autorequire(:user) do
  ['app']
end

From now on the new custom type can already be used in Puppet DSL, the compiler will create a catalog but the agent will produce an error, as there are no functional providers.

Agent side prerun evaluation

It is possible to have the agent first check some things prior the catalog will be applied.
This is what the :pre_run_check method can be used for

def pre_run_check
  File.exist?('/opt/app/bin/app.exe') && raise Puppet::Error, "App not installed"
end

Features

When using multiple providers (similar to the package resource) we want to be sure that the provider has all required implementations (features).
A type can require a feature:

# lib/puppet/type/app_config.rb
Puppet::Type.newtype(:app_config) do
  @doc = %q{Manage application config. There are three ways
    to authenticate: cert, token, user. cert is the default
    provider.

    Example:

      app_config: { 'enable_logging':
        ensure   => present,
        value    => true,
        file     => '/opt/app/etc/app.cfg',
        cli_args => ['-p'], # persistency
      }
  }
  ensurable
  # global feature
  # feature :cli, "The cli feature requires some parameters", :methods => [:cli]
  newparam(:name) do
    desc "The app config setting to manage. see app_cli conf --help"
  end
  newproperty(:value) do
    desc "The config value to set."
    validate do |value|
      unless value =~ /^\w+/
        raise ArgumentError, "%s is not a valid value" % value
      end
    end
  end
  # The property config_file must be set when using the cli 
  #   option to configure app.
  # The cli provider will check for a feature.
  newproperty(:file, :required_features => %w{cli}) do
    desc "The config file to use."
    validate do |value|
      unless (File.expand_path(value) == value)
        raise ArgumentError, "%s is not an absolute path" % value
      end
    end
    defaultto: '/opt/app/etc/app.cfg'
  end
  newparam(:cli_args, :array_matching => :all) do
    desc "CLI options to use during command execution."
    validate do |value|
      unless value.class == Array
        raise ArgumentError, "%s is not a an array" % value
      end
    end
    defaultto: ['-p']
  end
end

Provider implementation

Once the type is defined, the provider must handle how the resource is managed. Providers typically implement methods to:

Check if the resource exists (exists?).
Create a new resource (create).
Read existing resource properties (prefetch or a getter)
Modify a resource (flush or a setter).
Delete a resource (destroy).

# lib/puppet/provider/app_config/cli.rb
Puppet::Type.type(:app_config).provide(:cli) do
  desc "The app_config types cli provider."
end

It is also possible to re-use and extend existing providers classes.
Common code can be placed inside a generic provider (lib/puppet/provider/app_config.rb).

# lib/puppet/provider/app_config/cli.rb
Puppet::Type.type(:app_config).provide(:cli, :parent => Puppet::Provider::App_config) do
  desc "The app_config types cli provider reuses shared/common code from app_config.rb."
end

If you want to add shared functionality to multiple providers, you can place your code into the PuppetX module directory: lib/puppet_x/<company_name>/<unique class name>.

# lib/puppet/provider/app_config/cli.rb
require_relative '../../puppet_x/betadots/app_api.rb'
Puppet::Type.type(:app_config).provide(:cli) do
  desc "The app_config types cli provider reuses shared/common code from app_config.rb."
end

A new provider can be created by inheriting from and extending an existing provider:

# lib/puppet/provider/app_config/token.rb
Puppet::Type.type(:app_config).provide(:token, :parent => :api, :source => :api) do
  desc "The app_config types token provideris an extension to the api provider."
end

Additionally one can reuse any provider from any type:

# lib/puppet/provider/app_config/file.rb
Puppet::Type.type(:app_config).provide(:file, :parent => Puppet::Type.type(:ini_setting).provider(:ruby)) do
  desc "The app_config types token provideris an extension to the api provider."
end

Selection of provider

The Puppet Agent must know which provider to use, if multiple providers are present.
You can use of the provider meta parameterr or let providers perform checks to determine if they are valid for the system. The options include:

Check	Example	Description
commands	`commands :app => "/opt/app/bin/app.exe"`	Valid if the command `/opt/app/bin/app.exe` exists. The command can be later used using `:app`.
confine - exists	`confine :exists => "/opt/app/etc/app.conf"`	Valid if the file exists.
confine - bool	`confine :true => /^10\./.match(%x{/opt/app/bin/app.exec version})`	Valid if Version is 10.x
confine - Fact	`confine 'os.family' => :debian`	Valid if the fact value matches
confing - feature	`confine :feature => :cli`	Valid if the provider has the feature
defaultfor	`defaultfor 'os.family' => :debian`	Use this provider as default for Debian-based systems.

Reading and applying configuration

The provider needs the ability to create, read, update and delete individual configuration states (CRUD API).

Each configuration property needs a getter (read) and a setter (modify) method.

# lib/puppet/provider/app_config/cli.rb
#   app_config: { 'enable_logging':
#     ensure   => present,
#     value    => true,
#   }
#
Puppet::Type.type(:app_config).provide(:cli) do
  desc "The app_config types cli provider."

  # confine to existing command
  commands :app => "/opt/app/bin/app.exe"

  def exists?
    @result = app_cli('list').split(%r{\n}).grep(%r{^#{resource[:key]}})
    if @result.length > 1
      raise ParserError, 'found multiple config items found, please fix this'
    end
    return false if @result.empty?
    return true unless @result.empty?
  end

  def create
    app(['set', resource[:name], resource[:value]])
  end

  def destroy
    app(['rm', resource[:name]])
  end

  # getter
  def value()
    @result[0].split[1]
  end

  # setter
  def value=(value)
    app(['set', resource[:name], resource[:value]])
  end
end

It is recommended to also create the instances class method, which can collect all instances of a resource type into a hash.
The namevar is the hash key, which has a hash of paramters and properties as value.

require 'yaml'
def self.instances
  instances = []
  YAML.load(app_cli('list')).each do |key, value|
    attributes_hash = { key: key, ensure: :present, value: value, name: key}
    instances << new(attributes_hash)
  end
  instances
end

Sometimes it is not possible to collect all instances, such as with the file resource. In such cases no instance method is defined.

The instance method is used indirectly be each type when calling prefetch to get the acutal configuration and returns the@property_hash instance variable.

def self.prefetch(resources)
  resources.each_key do |name|
    provider = instances.find { |instance| instance.name == name }
    resources[name].provider = provider if provider
  end
end

This allows the type getter and setter to read an manipulate the instance variable, instead of writing getter and setter methods for each type.
This behavior is added by declaring the mk_resource_methods class method.

Once this is implemented you can run the command puppet resource app_config to retrieve all existing configurations.

Refresh events

In some cases it is required to refresh a resource, for example, to restart a service, remount a mount, or rerun an exec resource. To allow a type/provider to react to a refresh event, it needs special handling.

Within the type the refreshable feature must be activated and a refresh definition is added.

The following examples are taken from puppet service type and provider. The feature describes, which provider definition should be executed upon refresh event.

# lib/puppet/type/services.rb
# ...
  feature :refreshable, "The provider can restart the service.",
    :methods => [:restart]
# ...
  def refresh
    # Only restart if we're actually running
    if (@parameters[:ensure] || newattr(:ensure)).retrieve == :running
      provider.restart
    else
      debug "Skipping restart; service is not running"
    end
  end
# ...

Using custom types in Puppet DSL

Once the custom type and provider are implemented, you can use them in your manifests as follows:

# Type declaration
app_config { 'enable_logging':
  ensure    => present,
  value     => true,
  require   => File['/opt/app/etc/app.cfg'],
  subscribe => Service|'app'|,
}
# Type reference
service { 'app':
  ensure    => running,
  subscribe => App_config['enable_logging'],
}
# Type declaration using lambda and splat operator
$config_hash.each |String $key, Hash $hash| {
  app_config { $key:
    * => $hash,
  }
}
# Virtual or exported resource
@@app_config { 'app_mount':
  ensure => present,
  value  => "${facts['networking']['fqdn']}/srv/app_mount",
  tag    => 'blog',
}
# Resource collector
App_config <<| tag == 'blog' |>>

Resource API

The modern resource API has one limitation: one can not refresh types!
Besides this it also consists of types and providers which must be placed at the same location as the existing implementation.

Resource API Type

The resource API type uses an attributes hash to list all parameters and properties. Within the type key one can use any of the built-in Puppet data types.

# lib/puppet/type/app_config.rb
require 'puppet/resource_api'

Puppet::ResourceApi.register_type(
  name: 'app_config',
  docs: <<-EOS,
      @summary The type to manage app config settings
      @example
      app_config { 'key':
        ensure => present,
        value  => 'value',
      }

      This type provides Puppet with the capabilities to manage our application config
    EOS
  features: []
  attributes: {
    ensure: {
      type:    'Enum[present, absent]',
      desc:    'Whether the setting should be added or removed',
      default: 'present',
    },
    name: {
      type:     'String',
      desc:     'The setting to manage',
      behavior: :namevar,
    },
    value: {
      type: 'Variant[String, Integer, Array]',
      desc: 'The value to set'
    }
  }
)

Respource API Provider

The most simple solution is to make use of the SimpleProvider class.
This provider needs up to 4 defines:

get
create
update
delete

# lib/puppet/provider/app_config/cli.rb
require 'puppet/resource_api/simple_provider'
require 'open3'

class Puppet::Provider::AppConfig::Cli < Puppet::ResourceApi::SimpleProvider
  $app_command = '/opt/app/bin/app.exe'

  # Get: fetching all readable config settings into a hash
  def get(context)
    context.debug('Returning data from command')

    @result = []
    stdout, stderr, status = Open3.capture3('/opt/app/bin/app.exe list')
    raise ParseError "Error running command: \n#{stderr}" unless status.success?
    # Missing error handling. This is just for demo
    @command_result = stdout.split(%r{\n})
    @command_result.each do |line|
      next if line == '---'
      key = line.split(':')[0]
      value = line.split(':')[1].strip
      hash = {
        'ensure': 'present',
        'name': key,
        'value': value,
      }
      @result += [ hash ]
    end
    @result
  end

  # Create: add a new config setting with name and should value
  def create(context, name, should)
    context.notice("Creating '#{name}' with #{should[:value]}")
    _stdout, _stderr, status = Open3.capture3("/opt/app/bin/app.exe set #{name} #{should[:value]}")
    # Missing error handling. This is just for demo
    return true unless status.success?
  end

  # Update: correct an existing setting with name and replace with should value
  def update(context, name, should)
    context.notice("Updating '#{name}' with #{should[:value]}")
    _stdout, _stderr, status = Open3.capture3("/opt/app/bin/app.exe set #{name} #{should[:value]}")
    # Missing error handling. This is just for demo
    return true unless status.success?
  end

  # Delete: remove a config setting
  def delete(context, name)
    context.notice("Deleting '#{name}'")
    _stdout, _stderr, status = Open3.capture3("/opt/app/bin/app.exe rm #{name}")
    # Missing error handling. This is just for demo
    return true unless status.success?
  end
end

Summary

Types and providers are not complex. They basically describe the CRUD behavior of Puppet.
The type defines how to use the Puppet DSL, while the provider controls how to check and handle specific settings.

Please stop using exec for almost anything that is not super simple. In most cases, a simple type and provider will allow better analysis, error handling and control over what is happening. Besides this: custom types and providers execute faster compared to exec type usage - far more faster!

The example application and the working types and providers are available on GitHub:

The app: workshop demo app
The Puppet module with types and providers for the app: workshop demo module

App usage:

# Install APP:
git clone https://github.com/betadots/workshop-demo-app /opt/app
/opt/app/bin/app.exe

# Install Puppet module:
git clone https://github.com/betadots/workshop-demo-module -b ruby_workshop modules/app
# Type API V1
puppet resource app_config --modulepath modules
# Type Resource API
puppet resource app_config2 --modulepath modules

Happy puppetizing,
Martin

DEV Community: betadots

# OpenVox 9 ist da!

Release-Hinweise und Dokumentation

OpenVox 9 beziehen

Wichtigste Änderungen im Vergleich zu OpenVox 8

Vor dem Upgrade

Bekannte Probleme

Agent-Daemon kann gelegentlich beim Status „applying configuration“ hängen bleiben

FIPS-Pakete enthalten ältere Bouncy-Castle-JAR-Dateien

Vielen Dank

DevConf Tag 2

glibc-Workshop

Podman-Quadlets Workshop

DevConf: Tag 1

OpenVox rootless Alpine Containers

The PRs

How I got there

Rootless containers in detail 🥷🐳

Community powered Open Source ❤️

Why this matters

What’s next?

puppet-checkmk dusted off 🧹🦊

puppet-checkmk entstaubt 🧹🦊

Puppet Enterprise - Neue Releases und Upgrade Zyklen

Latest

Latest-1

aktuelles LTS Releases

Releases und Support Zeitraum

Zusammenfassung

How to keep your Puppet modules up to date with Renovate

Why Renovate?

Assumptions

Setting Up Renovate

Create a Renovate Runner Repository

Add GitLab CI Configuration

Running Renovate

Authentication: RENOVATE_TOKEN

Choosing the Right Container Image

Vulnerability Scan (grype)

Final Thoughts

🧩 Puppet Module Update Process

🔍 1. Identify and Analyze the Module

📝 2. Review Changes in the Module

⚠️ 3. Watch for Breaking Changes

🔍 4. Evaluate Other Changes

🌱 5. Integrate into Development Branches

🌲 6. Control Repo Branch Structure

🧪 7. Testing in Development Environment

🔄 8. Forward the Change

🤖 9. Automation with Renovate Bot

🧰 10. Automation with VoxBox

🧩 Puppet Modul Update Prozess

🔍 1. Modul identifizieren und analysieren

📝 2. Änderungen im Modul prüfen

⚠️ 3. Auf Breaking Changes achten

🔍 4. Sonstige Änderungen bewerten

🌱 5. Aufnahme in Entwicklungszweige

🌲 6. Branch-Struktur im Control-Repo

🧪 7. Tests in Entwicklungsumgebung

🔄 8. Change weiterreichen

🤖 9. Automatisierung mit Renovate Bot

🧰 10. Automatisierung mit VoxBox

Das neue Puppet Open Source Projekt heißt "OpenVox"

Vorbereitung

Aus Puppet wird OpenVox und Puppet Open Source

Source Code, Pakete und Container

Ich nutze Puppet Open Source. Was muss ich tun?

Puppet Open Source

OpenVox

Die weitere Entwicklung

Wie kann man helfen?

Professioneller Support

Zusammenfassung

The Ruby side of Puppet - Part 3 - Custom Types and Providers

General concepts

Type definition

Provider implementations

Types and providers in modules

Type description

APIv1

Authentication: `RENOVATE_TOKEN`