Planet Puppet

Example 42: Ansible vs Puppet: Choose the Operating Model, Not the Syntax

2026-07-17T06:00:00+00:00

Every Ansible-vs-Puppet argument I’ve ever watched start begins in the wrong place: YAML versus the Puppet DSL, agentless versus agent-based, tabs versus curly braces and mutual contempt. Fun bar conversation. Useless decision criteria. The question that actually matters is duller, and bigger: how do you want infrastructure policy evaluated, applied, observed, and owned — not this sprint, for the next several years. Puppet and Ansible overlap more than either camp likes to admit. Both install packages, render files, manage services, create users, and coordinate changes across a fleet. Same destinations, different routes — and the route stops being a footnote and starts being the whole story as the estate, the team, and the compliance requirements grow. The short answer Choose Puppet when you want continuous desired-state enforcement, per-node catalogs, rich run reporting, policy that outlives whoever wrote it, and convergence that happens locally without anyone pushing a button. Choose Ansible when agentless reach, ordered orchestration, fast automation across a herd of dissimilar things, and execution from one control point matches how your team actually likes to work. Use both when the boundary between them is drawn in ink, not vibes: Puppet owns persistent operating-system policy, Ansible owns deployments, network changes, or the coordinated one-off procedure. Don’t migrate because one DSL looked shorter in a conference demo. Migrate when the target operating model solves a problem your current one can’t solve economically. Should you migrate at all? The answer might be yes. It might not be, and there’s no Deep Thought to compute it for you in seven and a half million years — you still have to do the discovery work. Ansible and Puppet compared Dimension Puppet Ansible Primary model Declarative resources compiled into a per-node catalog Ordered plays and tasks executed against selected inventory Typical execution Agents request and apply catalogs on a schedule A control node connects to targets, commonly over SSH State enforcement Recurring convergence is the default State is evaluated when a playbook runs Language Puppet DSL, Hiera data, EPP templates YAML playbooks and roles, Jinja templates Ordering Resource relationships form a dependency graph Task order is explicit; handlers add event-driven actions Inventory and classification Facts, certificates, environments, Hiera, and classification produce a node catalog Static or dynamic inventory, groups, variables, and play targeting select hosts Change preview No-op catalog application and catalog compilation Check mode and diff mode where modules support them Reporting Agent reports can include every resource status, event, log, and run metric Play recap, callback output, controller logs, and automation-platform history Strongest fit Persistent system policy and continuous compliance Orchestration, deployments, remote automation, and heterogeneous targets Puppet’s own documentation calls a catalog a node-specific desired-state document with resource dependencies baked in: the agent compares actual state against it and corrects what doesn’t match. Ansible’s documentation describes playbooks as human-readable automation that can enforce configuration or walk a multi-tier operational procedure step by step. Both are idempotent — when the underlying resources or modules were actually written to be idempotent. Neither tool makes an arbitrary shell command idempotent by osmosis. I wish it did. I’ve written enough exec resources to know better. Sources: Puppet catalog compilation, Ansible introduction, and Ansible playbooks. Desired state versus an ordered procedure Puppet code declares resources and relationships, then lets the primary server do the arguing. It resolves facts, classification, Hiera data, manifests, functions, and templates into one unambiguous catalog for one node — this package must exist, this file must have this content, this service must run, all wired together with dependency edges that decide who goes first. Ansible playbooks read like what they are: a procedure. Target these hosts, run these tasks in this order, fire a handler if something changed, walk the fleet according to whatever strategy you picked. The modules underneath — package, file, service — can still be idempotent. But the playbook keeps a narrative running the whole time. It tells a story about execution, not just about outcome. That distinction shapes design, whether you notice it or not: A well-designed Puppet profile describes the policy that must remain true. A well-designed Ansible role describes repeatable tasks that produce the required state. A poor Puppet migration wraps every old script in exec resources. I’ve been that migration. More than once. A poor Ansible migration converts every Puppet resource into a task without reconsidering orchestration, variables, handlers, and run frequency. Continuous convergence and drift Puppet agents normally run on a schedule, so drift detection and remediation come baked into the model whether anyone asked for them or not. Someone changes something they shouldn’t at 2am, the next agent run notices, corrects it, and files the whole thing as a corrective event — a little timestamped confession. Agents also keep operating from their cached catalog when a fresh one can’t be compiled, depending on configuration and failure mode — a safety net, not a promise. Ansible normally changes or checks a system only when it’s invoked. Continuous enforcement is something you build on top of that: a scheduler, an automation controller, event-driven automation, ansible-pull, or some other deliberate mechanism. That can be exactly right — plenty of teams genuinely don’t want every policy continuously re-applied. But it means the drift model has to be designed on purpose. It doesn’t come free in the box. Ask the concrete question instead of the abstract one: who notices if /etc/ssh/sshd_config changes at 02:00, and what happens next? The answer tells you more about your real posture than any feature matrix ever will. Agentless does not mean infrastructure-less Ansible skips the dedicated management agent on normal SSH-reachable nodes, and that genuinely cuts endpoint packaging and lifecycle work. What it doesn’t do is make the infrastructure disappear — it just relocates it to somewhere you’re not looking yet. You still need: Reliable remote connectivity and credentials. Python or other target-side runtime requirements for many modules. Inventory ownership and freshness. A secured execution environment and dependency management. Scheduling, concurrency control, logs, secrets, and operator authorization. Puppet asks for an agent, and usually a server-side platform to go with it. In exchange, every node gets a local enforcement engine, a certificate identity, a catalog built just for it, and a recurring report trail home. The extra component is a real cost — no argument there — but it’s also the exact mechanism producing some of Puppet’s strongest properties. You don’t get the convergence without paying for the thing that converges. Change safety: no-op and check mode Puppet no-op compiles the real catalog, evaluates it against actual resources, and reports what it would have changed. Useful, sometimes uncannily so. It still depends on provider quality, and it still can’t predict what an external command or API call does once it actually runs. No-op reads the map, not the territory. Ansible check mode simulates changes for modules that support it. Read that clause again, specifically the qualifier — because the official documentation is explicit that a module without check-mode support does nothing and reports nothing when it’s run in check mode, and tasks depending on registered results from it may not behave as they would in a real run. Silence here isn’t reassuring. It might just mean the module shrugged. Diff mode adds before-and-after detail on top, where supported. Neither preview is a substitute for representative tests, canaries, and a rollback plan you’ve actually rehearsed. Treat preview output as evidence, not proof — a witness statement, not a verdict. See the Ansible check and diff mode documentation. Scale is more than node count Both tools handle large estates just fine. What breaks under load is different, and that’s the part people skip past to get to the demo. Puppet centralizes catalog compilation, code, data, certificates, and reports, and pushes the applying work out to agents. Server capacity, JRuby pools, compile time, PuppetDB, PostgreSQL, environment caching, and run interval — that’s your suspect list when things slow down. Ansible initiates connections and work from wherever it’s executing. Forks, strategy plugins, task duration, network latency, inventory plugins, controller capacity, and whatever rate limit the external API decided to enforce today — that’s yours instead. The serial, throttle, and strategy controls exist to make rolling execution explicit rather than accidental; the Ansible strategy documentation walks through them properly. “We have 5,000 nodes” tells me nothing on its own. Five thousand nodes quietly applying stable catalogs every thirty minutes, and five thousand nodes receiving one coordinated application deployment at the same moment, are not the same workload wearing a different hat. They’re different animals that happen to share a headcount. When Puppet is the stronger fit Long-lived Linux and Windows systems must continuously conform to policy. The organization values a compiled, node-specific catalog and detailed resource reports. Changes must be expressed as relationships rather than a global task order. Nodes may need to converge independently of a central push window. Hiera, facts, roles and profiles, and the existing module ecosystem already encode significant operational knowledge. Compliance depends on recurring evidence of actual versus desired state. For old puppeteers like me, that list reads less like a feature checklist and more like the reason the job exists. When Ansible is the stronger fit The estate includes network devices, appliances, APIs, or systems where an agent is undesirable. Orchestration and coordinated procedures are at least as important as continuous configuration. SSH-based access and central execution already match the security and operating model. Teams need rapid automation across changing or short-lived targets. Existing roles, collections, inventory, and automation-controller workflows already provide the organizational platform. When a hybrid is better than a migration A boundary I see actually hold up, over and over: Puppet manages operating-system baselines, accounts, packages, services, and persistent configuration. Ansible performs application deployments, maintenance workflows, network changes, and coordinated actions. This only works if the same property never has two owners. If Puppet insists on one version of a file while Ansible quietly deploys another, that’s not defense in depth. That’s two tools fighting over the same resource, and the fight is what gets deployed — an automation loop with a heartbeat. Write ownership down at the resource or workload level, not in your head and not in a Slack thread from eight months ago. Decide which inventory is authoritative, how credentials stay separated, where execution history actually lives, and how an engineer knows which tool to reach for without having to ask in the incident channel. A safe migration method 1. Inventory behavior, not files List managed resources, schedules, integrations, reports, secrets, classification rules, and operator workflows. Repository line count is a poor measure of migration effort — about as useful as counting words in a contract to estimate the lawsuit. 2. Classify workloads Separate persistent policy, application configuration, provisioning, deployment, orchestration, compliance, and one-off operations. Different categories may have different target tools, and often should. 3. Define acceptance evidence For each workload, record the resulting files, packages, services, commands, reports, and failure behavior. Preserve or create tests before translation — not after, when the only remaining oracle is someone’s memory of how it used to work. 4. Build native target patterns Design roles and inventory for Ansible, or profiles, modules, and Hiera for Puppet. Do not make the target imitate the source DSL. A Puppet manifest that’s secretly a YAML playbook wearing a trenchcoat serves nobody. 5. Pilot a representative slice Choose a workload containing data, dependencies, templates, service notification, and more than one operating system. A trivial package example proves very little — you already knew packages could be installed. 6. Prevent double ownership During transition, only one tool should manage a resource property. Use explicit cutover boundaries and retain a tested rollback — tested, not just written down and hoped for. 7. Measure the new operating cost Compare failure rate, drift, execution duration, change visibility, access management, test burden, and operator effort after the pilot. If nobody captured a baseline before the pilot, congratulations — you’ve just invented one retroactively, and it will conveniently favor whichever tool you already wanted. The practical conclusion Ansible is not “Puppet without agents,” and Puppet is not “Ansible that runs every thirty minutes.” They encode different assumptions about where policy gets evaluated and who’s allowed to touch what, and when. Choose the assumptions that fit your estate, not the ones that read better on a slide. If neither model should own everything, draw a hard boundary and use both deliberately — on purpose, not by accident three incidents from now. example42 supports migrations in both directions. The Ansible and Puppet migration service covers discovery, target patterns, pilots, staged rollout, and team handover. [Shameless plug]. Alvabot

Example 42: Puppet 7 to Puppet 8 Migration Guide

2026-07-10T06:00:00+00:00

Let’s get this straight before we start: a Puppet 7-to-8 upgrade is not a package update. It wears that costume — new repo, new version pin, apt upgrade and off you go — but underneath it’s a compatibility audit. You’re proving that your code, your data, your modules, your custom Ruby extensions, your server platform, and the workflow your team runs on autopilot all still agree with each other once the runtime underneath them changes. Ruby moves. OpenSSL moves. Strict mode flips on whether you asked for it or not. And in 2026 there’s a decision to make before any of that technical work starts: which Puppet 8 are you actually moving to? Open-source Puppet 8.10 was the last release Perforce maintained. Puppet Core continues from 8.11 as a commercial product. Puppet Enterprise has its own console-and-orchestrator upgrade path entirely. OpenVox is the community-maintained continuation, carrying the open-source torch under new names. Choose the target first. Repository access, package names, supported operating systems, lifecycle, entitlements and support expectations all hang off that one decision — everything below assumes you’ve already made it. The four target paths Open-source Puppet 8.10 Still installable, still runs. But Perforce says plainly that open-source Puppet gets nothing further from them past 8.10. Freezing here can be a legitimate, temporary compatibility step. It is not a security strategy — and treating it as one is how “temporary” quietly becomes “for the next three years.” See the Puppet Core 8.11 announcement. Puppet Core 8 The Perforce-maintained platform, built from the open-source tree, distributed through protected repositories that require actual entitlements — no more anonymous apt-get install. Perforce documents a direct transition from open-source Puppet 8 to Puppet Core; if your installation is anything but vanilla, custom bits may need extra work. See Upgrading from open-source Puppet to Puppet Core. Puppet Enterprise PE bundles the platform with its console, orchestrator, classifiers and deployment tooling — and its own supported upgrade procedure, full stop. Don’t run open-source server commands against a PE primary and hope for the best; that’s not an upgrade, that’s an incident report waiting for a title. Follow the PE version-specific path instead. The current Puppet Enterprise upgrade documentation covers infrastructure and agent sequencing, cautions, migration, and module testing. OpenVox 8 The community-maintained open-source implementation. Its own docs say it stays compatible with Puppet language and configuration while using replacement package names and repositories — same language, new labels, ship of Theseus for your configuration management. Treat the swap as a platform change anyway: test it on fresh systems or a controlled clone, back up /etc/puppetlabs, and validate server, database, terminus and module compatibility before you trust it in production. See the OpenVox installation and migration guidance. The rest of this guide covers the code and runtime work all four paths share. Wherever it disagrees with your distribution’s own installation and lifecycle rules, theirs wins. Breaking changes that deserve attention Perforce’s own Puppet 7-to-8 upgrade notes lay out the real compatibility boundaries. Four of them will actually bite. Ruby 3.2 Puppet 8 agents vendor MRI Ruby 3.2. Puppet Server 8 runs on JRuby 9.4, which implements most — not all — of the Ruby 3.1 interface. Plain Puppet DSL code barely notices. Your Ruby extensions will. Inventory all of these before you touch a package manager: Custom facts. Ruby functions. Types and providers. Report processors. Indirector termini. Face, application, and plugin code. Gems installed into Puppet’s vendored Ruby or Puppet Server’s JRuby environment. Run their unit tests against the target runtime, then actually exercise them in real catalog compilation — unit tests alone will lie to you by omission. Look for removed Ruby behavior, keyword-argument changes, standard-library gems that quietly stopped being bundled, and native extensions still built for the old runtime. OpenSSL 3 Puppet 8 agents vendor OpenSSL 3. Anything compiled against Puppet’s previous OpenSSL — your own tooling, third-party native extensions — needs rebuilding. Old algorithms, old certificate material, or local integrations can trip over this even when the Puppet CA itself is perfectly healthy. And while we’re on the subject: don’t regenerate the CA just because the major version ticked over. Back it up, test certificate operations, and touch trust infrastructure only when there’s a separate requirement and a complete rotation plan already written down. A CA rebuild is not a side effect of a Puppet upgrade — it’s its own project, with its own maintenance window and its own reasons to lose sleep. Strict mode by default Puppet 8 turns strict mode on by default. Code that references undefined variables, relies on invalid coercion, or leans on other previously-tolerated shortcuts can simply fail to compile. There are compatibility settings that dial strictness back down. Treating them as the actual migration endpoint doesn’t fix anything — it just files the failure for later, with interest. Turn strict checking on in CI while you’re still on Puppet 7, fix what breaks there, and let the production cutover be the anticlimax it should be. Legacy facts are no longer collected by default $::osfamily and $facts['osfamily'] both need to become $facts['os']['family'] or the equivalent structured fact. Search manifests, templates, Hiera hierarchy interpolation, custom functions, and tests — not only .pp files. Legacy facts like to hide in string interpolation and hierarchy paths where a lazy grep won’t find them. Puppet can be told to keep collecting legacy facts a while longer, but that’s a transition control, not a destination. The official module upgrade guidance is blunt about it: clean up legacy facts, top-scope variables, missing data types, and strict-mode issues before the jump, not after. Hiera 3 backends The Hiera 3 component is gone. Dropped. Deceased. Any backend implemented by extending Hiera::Backend needs to become a Hiera 5 extension, or be replaced outright. Ordinary Hiera 5 hierarchies, puppet lookup, and modern lookup functions were never the problem here. Find custom backends early. They tend to live outside the control repository, quietly forgotten, until every catalog depending on them fails at once and someone has to remember they exist. Phase 1: inventory the real platform Capture versions and ownership for: Puppet agent, Puppet Server, PuppetDB, termini, and PostgreSQL. Operating systems and architectures for every infrastructure role and representative agents. Java and JVM configuration on Puppet Server and PuppetDB nodes. Control repositories, environments, deployment tooling, and CI images. Every module and its dependency constraints from the Puppetfile. Locally developed modules and all custom Ruby extensions. Installed gems, report processors, ENC integrations, secret backends, and webhooks. Certificate Authority location, expiry, backups, CRLs, and renewal behavior. External consoles, dashboards, orchestrators, and API consumers. Also record baseline behavior: catalog compile time, run duration, failure rate, recurring changes, PuppetDB queue and query health, JVM memory, and report volume. Skip this and a technically flawless upgrade can still hide a serious regression — you just won’t have anything to catch it against. Phase 2: make Puppet 7 behave like the target Close the compatibility gap before you change a single package. Enable strict checks in development and CI. Replace legacy and top-scope fact access with structured facts. Add data types to public class parameters where practical. Remove deprecated language constructs and suppressed lint warnings. Move Hiera 3 backends and obsolete hierarchy patterns to Hiera 5. Update modules to releases declaring Puppet 8 support. Test custom Ruby code under Ruby 3.2 and the target Puppet Server runtime. Useful checks include: puppet parser validate manifests/site.pp puppet epp validate templates/example.epp pdk validate pdk test unit puppet lookup profile::example::setting --node test.example.com --explain Run these through CI, with the same module and gem dependency resolution production will actually use. A developer laptop with its own Ruby version and unpinned gems isn’t a migration test — it’s a story you’ll tell later, ruefully. Phase 3: prove catalog compatibility Unit tests catch module behavior in isolation. They prove nothing about whether your full classification, Hiera data, facts, and module set compile together — which is, annoyingly, the part that actually matters. Build representative fact sets for each operating-system family, role, environment, and important edge case. Compile catalogs on Puppet 7 and on the target Puppet 8 stack. Compare: Compilation success and warnings. Resource counts and types. Removed or newly managed resources. Dependency edges that affect ordering. File content and sensitive-data handling. Exported-resource and PuppetDB-dependent behavior. Compile time and memory use. Then apply target catalogs to disposable or restored test nodes. Catalog equality isn’t the goal — provider and runtime changes may legitimately differ — but every difference needs an explanation, not a shrug. Phase 4: rehearse the infrastructure upgrade Clone or rebuild a representative non-production stack. Restore sanitized code, data, PuppetDB data if needed, and a safe copy of the CA — inside an isolated network, please. Exercise: Server startup and full catalog compilation. Certificate signing, renewal, revocation, and CRL distribution. PuppetDB command processing, queries, reports, and dashboard integrations. Code deployment and environment cache behavior. Backup and restore procedures. Monitoring, alerting, log collection, and service restart behavior. Agent compatibility across the oldest and newest supported operating systems. Don’t discover, during the actual production window, that the new server package doesn’t exist for your current server OS. Platform support is part of this upgrade whether you scheduled it or not — sometimes a parallel rebuild is safer than an in-place OS-plus-Puppet-major-version leap. Phase 5: upgrade infrastructure before agents Puppet’s own agent upgrade guidance isn’t negotiable on this point: the server goes first. In a simple open-source or Puppet Core deployment, upgrade and verify the server-side components in the supported order for the chosen distribution, PuppetDB and termini compatibility included. For load-balanced compilers, rotate nodes individually when the product documentation supports mixed operation. For Puppet Enterprise, follow the PE installer or Puppet Installation Manager sequence exactly — infrastructure nodes running incompatible versions can break agent runs and replication in ways that are tedious to untangle afterward. After each infrastructure step, verify: Status endpoints and service health. Catalog compilation for representative nodes. PuppetDB command queues and query results. A controlled Puppet 7 agent run against the upgraded server. Report ingestion and external integrations. The official Puppet Server upgrade procedure and your distribution’s version-specific release notes are the actual authority here — this guide gives you the shape, not the exact commands. Phase 6: canary Puppet 8 agents Start with nodes that are representative, observable, and recoverable — not just the handful of empty test machines nobody would miss. Include: Each supported operating-system family and major version. Nodes using custom facts, providers, or native extensions. High-resource catalogs and unusual Hiera paths. Systems with security hardening or restricted networking. At least one important service where the team knows what normal looks like. For each canary: Back up configuration and record the installed package state. Run the last Puppet 7 catalog and keep its report. Upgrade the agent through the supported repository and package path. Run Puppet 8 in no-op and review every proposed change — actually read it, don’t skim. Apply only after the output is understood. Compare reports, facts, runtime, plugins, and service behavior with the baseline. Leave the canary through several normal run intervals before expanding. Roll out in bounded cohorts. Pause automatically on compile failures, unexpected corrective changes, agent crashes, or a runtime regression that’s more than rounding error. Rollback is a designed path Downgrading the package is the easy part of rollback. Decide, before production, how you’d recover: Server packages and configuration. PuppetDB and PostgreSQL data. CA files and certificate state. Code and Hiera data deployments. Agent package repositories and pinned versions. Ruby gems and native extensions. External integrations that change schema or authentication behavior. Don’t stack a Puppet major upgrade, a server OS migration, a CA rebuild, a Hiera redesign, and a module refactor into one irreversible event. Some of these can be prepared together, but their cutovers should stay separately observable and separately recoverable. What “done” looks like The migration is complete when: All production platforms use a supported target distribution and version. Catalogs compile without compatibility fallbacks or unexplained warnings. Legacy facts and Hiera 3 dependencies are gone, not just muted. Custom Ruby extensions are tested on the target runtimes. PuppetDB, reports, CA operations, deployments, and integrations are healthy. Performance is at least understood relative to the pre-upgrade baseline. The team can deploy code, diagnose failures, add agents, renew certificates, and restore the platform — without three people Googling the same Stack Overflow answer. Temporary compatibility settings have owners and removal dates — or are already gone. The safest Puppet 8 migration is intentionally boring: most incompatibilities get removed while you’re still on Puppet 7, the target stack gets rehearsed before it’s real, infrastructure moves first, and agents move in cohorts small enough to actually watch. No fireworks. That’s the whole point. If you want an environment-specific assessment, Puppet Health Check covers code, runtime, infrastructure, and upgrade readiness. For implementation and rollout, there’s Smart Puppet Support. [Shameless plug]. Alvabot

betadots: DevConf Tag 2

2026-06-20T07:43:19+00:00

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.

betadots: DevConf: Tag 1

2026-06-18T07:54:44+00:00

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

betadots: OpenVox rootless Alpine Containers

2026-06-12T13:42:44+00:00

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

betadots: puppet-checkmk dusted off 🧹🦊

2026-06-12T08:47:43+00:00

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

betadots: puppet-checkmk entstaubt 🧹🦊

2026-06-12T08:47:42+00:00

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]

Example 42: First Steps in the Swamp

2026-06-11T00:00:00+00:00

Edit: A few hours after the initial post. So, what follows below, has been generated by Alvabot, an agent in the making. Alvabot is learning and shaping, and I’m learning how to use it. One of the worst way is the post that follows, which might be useful and readable, but it’s for a good part, a token re-digestion of https://swamp-club.com/manual/tutorials/hello-world. So basically AI slop. Sorry for that, Alessandro Original post Day one I got muddy. Day two I read the map. Day three, three weeks later, is the post I would have wanted on day one: the actual commands to type, in the actual order, to go from “deterministic automation for AI agent”, whatever that means, to a working workflow with versioned data you can query. No theory this time. Well, almost. This is the practical companion to the previous post: if you don’t know what a model, a workflow or a vault is in Swamp terms, go read that one first. We’ll wait. We have time, we’re a swamp. One prerequisite before the commands: you need an AI agent. Swamp is designed to be operated by agents, not just used next to them. Claude Code is the assumed default (and what I use mostly), but any decent coding agent works. The point, as we’ll see, is that you mostly don’t write Swamp YAML by hand — your agent does, and Swamp gives it the rails. Step 0 — Install curl -fsSL https://swamp-club.com/install.sh | sh Yes, the infamous curl-pipe-sh. We’ve all made our peace with it, or at least we pretend convincingly. Verify it landed: swamp version If the command is not found, restart your shell or add ~/.local/bin to your PATH. (Twenty-five years of Unix and this sentence is still in every tutorial ever written. There’s something comforting in that.) Step 1 — Initialize a repo Any repo. A new one, an existing project, the place where your podcast scripts live. For a first dip, make a sandbox: mkdir my-swamp-project cd my-swamp-project swamp repo init You get a glorious ASCII banner (“WELCOME TO THE CLUB — for hackers, by hackers”) and, more importantly, a scaffold: ls -a # .claude CLAUDE.md .gitignore models .swamp .swamp.yaml vaults workflows Pay attention to two things here: .claude/ and CLAUDE.md — this is how the agent learns Swamp. The skills are auto-discovered: open Claude Code in this directory and it already knows the framework. No prompting liturgy, no copy-pasted system prompts. The framework documents itself to its own operator, which is still my favorite mildly-unsettling feature. .swamp/ — this is where every execution will leave typed, versioned, queryable data. The substrate. The thing that stops your agent’s work from dissolving into chat history like tears in rain. Step 2 — Create your first model (don’t write it, ask for it) Open Claude Code in the repo and ask, in plain language: Create a command/shell model called hello-world that echoes "Hello from the swamp!" The agent creates a YAML definition under models/command/shell/. This is the division of labor I praised on day two, now visible on disk: logic lives in TypeScript (in the model type), configuration lives in YAML (in your model definition). The agent reasons over data, not over code. Old Puppet hands: yes, this smells exactly like the resource abstraction layer. I know. I checked my pulse too. Step 3 — Run it swamp model method run hello-world execute You get your Hello from the swamp!, but the interesting part is what comes after: a method summary report telling you that the run produced a result resource and a log file, both saved and versioned under .swamp/data/. Every run. Automatically. An audit trail as a first-class citizen, not something you bolt on later when the auditors call. Step 4 — Query the data This is the moment it clicked for me, so don’t skip it: swamp data query 'modelName == "hello-world"' Two artifacts, versioned. Now extract just the stdout: swamp data query \ 'modelName == "hello-world" && specName == "result"' \ --select 'attributes.stdout' Hello from the swamp! Those predicates are CEL expressions — the same expression language used inside model definitions and workflows to wire outputs into inputs. Learn the query syntax here, at the CLI, where mistakes are free, and you’ve learned the glue of the whole framework. Your agent’s executions are no longer ephemeral logs. They’re a queryable database. Sit with that for a second. Step 5 — Compose a workflow (and extend Swamp while you’re at it) Now the real demo. Back in Claude Code, ask for something Swamp can’t do yet: Create a new extension model type named @tutorial/random-status that randomly returns one of a list of statuses, storing it in a resource named "output" with a "status" property. Then create a model called weather-report that uses it to return one of: murky, misty, gloomy, stinky and humid. Then create a command/shell model called morning-message. Create a workflow called swamp-morning with two jobs: a "gather" job that runs hello-world and weather-report, and a "combine" job that depends on gather and runs morning-message, passing the hello-world stdout and the weather-report status into its command. Notice what just happened in one prompt: a new extension (new capability, packaged), two new models, and a workflow — a DAG with a parallel gather job feeding a dependent combine job. Files appear under extensions/, models/ and workflows/. All reviewable, all in git, before anything runs. Run it: swamp workflow run swamp-morning Hello from the swamp! The weather is gloomy - best to stay inside. The two gather steps run in parallel, combine waits for both, every edge is typed, every node leaves versioned data behind. Query the final result like before: swamp data query \ 'modelName == "morning-message" && specName == "result"' \ --select 'attributes.stdout' A pipeline where the second run is deterministic instead of a fresh improvisation. That’s the whole pitch, demonstrated in a sandbox in under half an hour. Step 6 — When things go wrong (they will, it’s a swamp) swamp doctor Checks installation health, broken hooks, unhealthy extensions, malformed workflows, vaults, and — bless them — cleartext secrets you left lying around. Run it early, run it often. On day one this command would have saved me several hours and an indecent amount of tokens. Where to wade next Once the hello-world ritual is done, the actual exploration starts. My suggested order: Vaults. Create one, store a secret, reference it via expression in a model. Local encrypted storage to start; AWS Secrets Manager or 1Password when a team shows up. Boring, in the best possible sense. The extensions registry at swamp-club.com/extensions. Browse what others built before reinventing it — there’s everything from AWS primitives to Firecracker microVM management for sandboxing Claude Code itself. A package manager for agent capabilities. Manual approval gates. Workflows can suspend at a manual_approval step and wait for a human sign-off before touching production. The day you let an agent near real infrastructure, this is the feature that lets you sleep. Your own real use case. Take the thing you ask your agent to improvise more than once — podcast post-production, invoice archiving, key rotation, that messy directory you keep promising to fix — and reframe it as a workflow of typed models. The moment you do, it stops being a one-off and becomes an asset. And read the manual. The hands are muddier than ever. The difference is that now the mud is versioned. We’ll keep wading. Alvabot and Alessandro Franceschi

Example 42: Reading the Swamp

2026-05-22T00:00:00+00:00

Two days ago I put my hands in the Swamp and they got, predictably, very dirty. Then I did something radical, revolutionary, somehow epic. I read the ***ing manual. No. It’s a lie, I didn’t. I forced an innocent AI to read it and summarize and explain the whole thing with the patience only AIs can have nowadays. This post, written in 4 hands, well, two hands and a bunch of tokens, (you will never know, nor care, who wrote what), is the final public summary of such a journey into the swamp. The map I should have read first Day one was hands-in-the-mud. I installed the tool, pointed an agent at it, and spent several hours and an indecent amount of tokens fighting a bug which could be avoided just by using a better name. Btw, the bug has already been corrected and the fix released (thank you Paul), what a time to be alive! Day two I climbed back onto dry land, wiped my glasses (wait, I don’t have glasses :-> ), and actually looked at the map. The map, it turns out, is good. Suspiciously good. There is a whole manual on swamp.club, neatly organized into tutorials, how-to guides, reference and explanation, written in a dry, essential, effective and ultimately boring style (had to say that also here, Adam :). The homepage line that meant absolutely nothing to me on day one — “deterministic automation for AI agents” — finally clicked. So let me try to explain it, naively, the way you explain a thing the morning after you finally got it. What I finally understood Here is the problem Swamp is staring at. An AI agent is a brilliant amnesiac improviser. Every session it re-derives the world from scratch, does something genuinely clever, and then the clever thing dissolves into the chat history. Capabilities lost in chat, like tears in rain. One-off scripts that rot. Ephemeral logs nobody can query. Credentials scattered wherever the agent felt like leaving them. I know this dance well. I am the continuity in that dance — me, my head, and a growing pile of CLAUDE.md files. Swamp’s bet is to give the agent a substrate instead. A place where the work it does becomes typed, versioned, queryable, composable — and therefore survives. The agent stops winging it and starts building things. It is, more or less, the difference between asking a consultant to solve your problem and asking them to leave behind a reusable module. For a man who spent twenty years preaching reusability in the Puppet world, that sentence clicked on day one, but I didn’t full realized that immediately. Six creatures living in the swamp The framework decomposes automation into a handful of primitives. They compose. Of course they compose — that is the whole point — but it still made me happy to see it. Models. Typed interfaces to anything. “Zod schemas in, validated data out.” A model is a typed interaction with an external system: it has a type — something like command/shell or @swamp/aws/ec2/vpc — methods such as create, sync, delete, and typed input and output schemas. The detail that made me sit up: reusable logic lives in TypeScript, while configuration lives in YAML. So the agent doesn’t write code to configure things — it reasons over data. Anyone who has agonised over “should the AI write code here, or data?” feels that one in the spine. It is the Puppet resource abstraction layer, reborn for agents. Workflows. Multi-step DAGs of jobs, with parallel steps, and — this is the good bit — they nest. Steps chain data from earlier steps with CEL expressions, so the output of one job feeds the input of the next, typed all the way. It is a pipeline, except every edge is typed and every node leaves an immutable, versioned artifact behind. My day-one naming bug lived exactly here, in a model the loader refused to discover. Now I understand why the loader has opinions. Vaults. Encrypted secret storage, referenced by expression, resolved at runtime rather than at planning time. Swappable providers: local encryption for me on my own, AWS Secrets Manager or 1Password for a team. Boring. I mean that as a compliment. Secret management that is boring is secret management done right. Extensions. The thing I face-planted into on day one. Extensions package reusable components — models, vault providers, execution drivers, datastores, reports — and you publish them to a registry where they become “a full citizen immediately”. On day one this scared me, and it still does a little. On day two I also see it for what it is: a package manager for agent capabilities. And no, Matteo, it’s not just yet another collection of skills, hope this post will help in clarifying what I was not able to explain correctly. Reports. Structured analysis after every run, in Markdown and JSON. The agent doesn’t just do the thing — it tells you what it did, in a format a human and another machine can both read. An audit trail as a first-class citizen, not an afterthought. Skills. Markdown documents that teach the agent how to use Swamp, loaded on demand when a trigger fires. So the agent learns Swamp from Swamp. The framework documents itself to its own operator. Mildly meta. Slightly unsettling. Mostly brilliant. Not only for infrastructures On day one I kept asking the same nervous question: what repo? Infrastructure repo? Software repo? Any repo? The honest answer the docs gave me is: any repeatable, multi-step thing. Infrastructure is the obvious case — inventory, provisioning, an AMI lookup feeding an EC2 model. Expected. Adam Jacob, System Initiative — of course it does infrastructure. But the moment you stop reading “automation for AI agents” as “infrastructure” and start reading it as “anything an agent currently does ad hoc in a chat window”, the thing gets a great deal bigger. Webframp wrote a enlightening post about this, give it a look. Use cases are whatever you do more than once with an agent (or you should/may do with it). Think about automated transcript generation of a podcast episode, extraction of summaries, tags, generation of posts, web pages and all the corollary stuff. Or security operations — key rotation. Rotate an API key, update the vault, notify the team. Three steps, secrets involved, must be repeatable, must be auditable. Swamp’s home turf. Or data remediation — a messy media library, a directory of inconsistently named files, a spreadsheet that needs reconciling. Boring, repetitive, the kind of job you hand to an agent once and can then never reproduce. Or the dull business automations — invoicing, monthly reports, the recurring thing you always forget until it is late. The pattern underneath all of them is the same. The moment you frame a task as “a workflow of typed models” instead of “a thing I ask the agent to improvise again”, it stops being a one-off and becomes an asset. Reusability, abstraction, repeatability, traceability — my day-one sacred principles — except now they apply to what the AI does, not only to what I write by hand. Teaching my agents to swim This is the part I am still slightly amazed by. Right now my working relationship with an agent is: brilliant intern, infinite enthusiasm, almost zero long-term memory (memory.md? really?). Every morning it forgets it ever met me. It re-derives, re-discovers, re-improvises, and occasionally re-breaks. It is, as I said two days ago, smart for smart users — which is a polite way of saying I carry the continuity, in my head and in config files. Swamp moves that continuity out of my head and into a structured substrate. The agent’s work becomes: typed, so it can no longer lie to itself quite so cheerfully — and on day one the AIs were always reassuring me everything was fine while nothing worked; versioned, so I can see what actually changed; auditable, through reports; repeatable, so the second run is deterministic rather than a fresh improvisation; shareable, through extensions. The agent stops being an intern who forgets everything and starts being a colleague who builds and reuses a real toolkit. That is a genuinely different way of working — and I did not expect a download-and-run-a-script tool to be the thing that handed it to me. Conclusions I am, clearly, hooked. The hands are still a bit muddy. Still wondering about all the possible use cases, for the world and for myself, but Alvabot and Webframp (hope he is human, at least) are helping. We’ll keep wading. Alvabot and Alessandro Franceschi

Example 42: Hands in the Swamp

2026-05-20T00:00:00+00:00

This is weird, and I guess a sign of the weird times we live in. A pond of beautiful entities I’m not sure about the first time I heard about Swamp, I guess at the last CfgMgmtCamp in February directly from Adam Jacob. If you know Adam, you know that he is a brilliant guy with crazy ideas, sometimes too ahead of their time (Ok, he also did Chef, when there was already Puppet, messing up things in our placid community, but that’s another story). In the next months I kept on having indirect updates about Swamp from Paul Stack and his posts on LinkedIn but that remained the classic “apparently cool tool I should check out when I have time”. That time, of course, never arrives, even if I have plenty of it. This morning was different, I woke up earlier than usual, gave a look at a post from Paul, went to the Swamp site and wondered, once again, “What the xxxx is Swamp anyway”? Honestly, claims like “ADAPTIVE WORKFLOWS (or DETERMINISTIC AUTOMATION) FOR AI AGENTS” didn’t really click anything in me, and it took me some time to understand the inner, and powerful, meanings. Anyway, instructions say: install swamp with the usual “download and run a random script”. Ok, I’m sadly familiar at performing unprotected sex with the Internet. Then go to your repo and run swamp init and then open your agent tool. What repo? Your infrastructure management repo? Your own software repo? Any repo? So I went to my pabawi repo (btw, it has been launched today on Product Hunt, give it a look ) and wondered… now what? This is software, not infrastructure to run things on. I consulted a random bot, of course, at least to try to understand what Swamp can be used for in this case, and then I wondered that maybe I could use it to automate the testing of Pabawi Docker images, to begin with something. Swamping for a single bad naming choice So I started to put my hands in the swamp. Needless to say they quickly became dirty. Very dirty. In a pure, ignorant, vibe approach, I asked Codex to do something with Swamp to automate the testing of Pabawi docker images. The AI started to juggle with tokens, searched the Swamp Club for existing extensions and generated a workflow to test the local Dockerfile on a remote system over ssh. I wondered why testing my local software on a remote server, when I have a local Docker running, and hence, after a few more AI mumblings and no viable existing alternative, I wondered why not making a general purpose Docker local testing extension? My damn tendency to abstract things to make them reusable. Here comes my trip to the rabbit hole, I just started to use Swamp and I was already trying to make a public extension. It could have been an incredibly fast rewarding experience, but in my case, for this very specific case, it has been a (relatively) painful (in the degree of a “few hours and several tokens spent” pain scale) experience. I struggled with conflicts from local development and published versions, issues with unknown model types, AIs always reassuring that everything was fine, while nothing was working, moving the extension to a dedicated repo, and doing it in the wrong way, then, again, issues with unknown model types. All this via a quick burn of Codex 5 hour session credits, some additional credits bought (clear sign I was hooked in the trap), a shift to Claude code, because I didn’t want to burn too quickly Codex extra credits, and the hit of Claude limits as well, to finalize everything with Antigravity, without plan. After several troubleshooting sessions, where the AI was apparently shooting at its own generated troubles while it should have aimed at my bad naming choices, Claude told me: ⏺ ROOT CAUSE — confirmed in Swamp's source (extension_loader.ts:1112): entry.isFile && entry.name.endsWith(".ts") && !entry.name.endsWith("_test.ts") // test files are excluded from discovery The model file is named docker_image_test.ts — it ends in _test.ts, so Swamp's extension loader treats it as a test file and excludes it from discovery entirely. Swamp extension push uses the manifest's explicit list (so it bundles fine, modelCount: 1), but every consumer scans the directory, skips *_test.ts, and registers 0 models. The type string, paths.base, the layout — none of it ever mattered. It was the filename all along. A bad name, a bug in upstream code, promptly reported with the insanely cool swamp issue command, some other minor tweaks, 7 releases on day one, and finally an apparently working docker-image-test extension was published. Muddy conclusions The good? In the process I started to learn something about Swamp, just scratching the surface, but my mind started to be enlightened about its endless possibilities. The bad? The fact that anyone can publish an extension and anyone else can use it out of the box with Swamp and use it for any infrastructure or automation workflow scares me. Feature request for Adam, Paul and whoever works in the Swamp: if you are not already doing it, do some kind of automated security assessment on what users publish on swamp.club The unnecessary irony? After all this effort I thought that I probably could have achieved the same “docker build and test” task in much less time with a shell script. I’m still not sure if this specific Docker test extension makes sense, in Swamp world, but my ancient DevOps spirit keeps on reminding the sacred principles of reusability, abstraction and repeatability and the curious AI fanboy of the current times lights up at the huge powers of gated and modelled AI driven workflows. Lessons learned? The usual one. AIs are smart for smart users and sometimes dumb with dumb users. Alessandro Franceschi

Puppet Blog: สล็อตวัวโชคลาภ UFABET ทางเข้าเล่นเว็บตรง PG Soft แตกง่าย 2026

2026-05-06T08:10:37+00:00

การเลือกเดิมพันกับ สล็อตวัวโชคลาภ UFABET ในปี2026ถือเป็นทางเลือกที่ยอดเยี่ยมสำหรับผู้ที่ต้องการความมั่นคงและระบบการเล่นที่ได้มาตรฐานสากลด้วยรูปแบบตัวเกมFortuneOxที่เน้นความรวดเร็วและโบนัสแตกง่ายเมื่อรวมเข้ากับระบบของ สล็อตวัวโชคลาภ UFABET ทำให้ผู้เล่นมั่นใจได้ว่าทุกยอดการชนะจะถูกจ่ายจริงบทความนี้จะสรุปข้อมูลเชิงลึกจากคู่มือผู้เล่นอย่างเป็นทางการเพื่อให้คุณพร้อมพิชิตกำไรจากวัวทองคำตัวนี้

สล็อตวัวโชคลาภ UFABET ทางเข้าเล่นเว็บตรง PG Soft แตกง่าย 2026

ทำไมต้องเลือกเล่น สล็อตวัวโชคลาภ UFABET เว็บตรงไม่ผ่านเอเย่นต์

ความโดดเด่นของ สล็อตวัวโชคลาภ UFABET คือการให้บริการผ่านระบบAPIแท้จากค่ายผู้พัฒนาซึ่งช่วยให้ค่าRTPและอัลกอริทึมของเกมเป็นไปอย่างโปร่งใสที่สุดการเข้าใช้งานผ่าน สล็อตวัวโชคลาภ UFABET ช่วยลดความเสี่ยงเรื่องการโดนปรับอัตราแพ้ชนะและยังมาพร้อมกับระบบฝากถอนอัตโนมัติที่เชื่อมต่อกับตัวเกมโดยตรงทำให้การเดิมพันของคุณลื่นไหลไม่มีสะดุดไม่ว่าจะเป็นช่วงเวลาที่มีผู้ใช้งานหนาแน่นก็ตาม

ทำไมต้องเลือกเล่น สล็อตวัวโชคลาภ UFABET เว็บตรงไม่ผ่านเอเย่นต์

เจาะลึกกติกาการเล่น สล็อตวัวโชคลาภ UFABET อ้างอิงจากระบบจริง

เพื่อให้การเดิมพันมีประสิทธิภาพผู้เล่นจำเป็นต้องเข้าใจกลไกของเกมซึ่งใน สล็อตวัวโชคลาภ UFABET มีรายละเอียดเฉพาะตัวที่น่าสนใจดังนี้:

รูปแบบเพลา 3-4-3 และเส้นไลน์เดิมพัน 10 แบบที่ควรรู้

ตัวเกมใน สล็อตวัวโชคลาภ UFABET ถูกออกแบบมาเป็นสล็อตวิดีโอที่มีความแปลกใหม่โดยมี3เพลาซึ่งเพลาที่1และ3มีจำนวน3แถวส่วนเพลาตรงกลางจะมี4แถวรองรับเส้นไลน์เดิมพันคงที่ทั้งหมด10รูปแบบการชนะจะเกิดขึ้นเมื่อมีสัญลักษณ์ที่เหมือนกันเรียงติดต่อกันจากเพลาซ้ายไปขวา

สัญลักษณ์พิเศษ Wild และอัตราการจ่ายเงินรางวัลสูงสุด 2,000x

ในระบบของ สล็อตวัวโชคลาภ UFABET สัญลักษณ์Wildคือหัวใจสำคัญเพราะสามารถใช้แทนสัญลักษณ์อื่นได้ทุกตัวหากสัญลักษณ์นี้ปรากฏขึ้นตามเส้นไลน์จะช่วยเพิ่มโอกาสชนะและหากชนะรางวัลใหญ่ที่สุดผู้เล่นมีโอกาสได้รับเงินรางวัลสูงถึง2,000เท่าของยอดเดิมพันรวม

เจาะลึกกติกาการเล่น สล็อตวัวโชคลาภ UFABET อ้างอิงจากระบบจริง

ฟีเจอร์เด็ดวัวแห่งโชคลาภตัวคูณ x10 ทำกำไรมหาศาล

หัวใจหลักที่ทำให้ สล็อตวัวโชคลาภ UFABET ครองใจผู้เล่นคือฟีเจอร์พิเศษที่จะสุ่มออกมามอบโบนัสก้อนโตให้กับผู้ใช้งานทุกคน:

เงื่อนไขการสุ่มเกิดฟีเจอร์หมุนซ้ำจนกว่าจะชนะรางวัล

ระหว่างการหมุนใน สล็อตวัวโชคลาภ UFABET ฟีเจอร์วัวแห่งโชคลาภอาจสุ่มเกิดขึ้นโดยที่เพลาที่1และ3จะปรากฏสัญลักษณ์ที่เหมือนกันจากนั้นเพลาทั้งหมดจะหมุนซ้ำไปเรื่อยๆจนกว่าจะมีการชนะรางวัลเกิดขึ้นซึ่งเป็นการการันตีรายได้ให้กับผู้เล่นเมื่อฟีเจอร์นี้ทำงาน

วิธีรับโบนัสคูณ 10 เมื่อสัญลักษณ์เต็มหน้าจอ

ความพิเศษสูงสุดของการเล่น สล็อตวัวโชคลาภ UFABET คือเมื่อสัญลักษณ์ใดสัญลักษณ์หนึ่งปรากฏเต็มทุกตำแหน่งบนเพลาทั้งหมดรางวัลชนะรวมในรอบนั้นจะถูกนำไปคูณด้วยx10ทันทีเปลี่ยนรางวัลธรรมดาให้กลายเป็นแจ็คพอตใหญ่ได้ในพริบตา

ตารางสรุปข้อมูลทางเทคนิคของเกม สล็อตวัวโชคลาภ UFABET

ข้อมูลสรุปสำหรับนักเดิมพันเพื่อใช้ในการวางแผนเงินทุนเมื่อเข้าใช้งาน สล็อตวัวโชคลาภ UFABET :

รายละเอียดเทคนิค	ข้อมูลตัวเลข
ขนาดการเดิมพัน	0.10 – 50.00 (฿)
ระดับการเดิมพัน	1 – 10
เส้นไลน์ชนะรางวัล	10 Lines (Fixed)
สัญลักษณ์พิเศษ	Wild Symbol
รางวัลสูงสุด	2,000x

คู่มือการใช้งานปุ่มควบคุมบนมือถือและคอมพิวเตอร์

การควบคุมเกมผ่าน สล็อตวัวโชคลาภ UFABET ถูกพัฒนาให้รองรับทุกอุปกรณ์อย่างสมบูรณ์แบบ:

ระบบมือถือ: ใช้การแตะที่ปุ่มวงกลมสีเขียวเพื่อเริ่มหมุนหรือกดที่ปุ่มTurboเพื่อเร่งความเร็วในการเล่น
ระบบคอมพิวเตอร์: สามารถกดปุ่มบาร์ยาวบนคีย์บอร์ดเพื่อเริ่มหมุนหรือกดค้างไว้เพื่อหมุนต่อเนื่องรวมถึงการกดเพื่อข้ามแอนิเมชั่นแสดงผลลัพธ์ให้ไวขึ้น
ข้อควรระวัง: หากเกิดข้อขัดข้องทางเทคนิคขณะเล่นการจ่ายรางวัลและการเล่นทั้งหมดใน สล็อตวัวโชคลาภ UFABET จะถือว่าเป็นโมฆะตามกฎสากล

อาจจะอยากดู: เกมไพ่ UFABET

สรุปความน่าเชื่อถือและเทคนิคการเล่นให้ได้เงินจริง

การทำกำไรจาก สล็อตวัวโชคลาภ UFABET ไม่ใช่เรื่องยากหากคุณเข้าใจกติกาและเลือกเล่นกับผู้ให้บริการที่มั่นคงการใช้ฟีเจอร์หมุนซ้ำและการรอจังหวะตัวคูณx10คือกลยุทธ์ที่ดีที่สุดผู้เล่นควรบริหารจัดการเงินทุนให้เหมาะสมและตรวจสอบประวัติการเล่นอย่างสม่ำเสมอเพื่อให้ทุกการเดิมพันใน สล็อตวัวโชคลาภ UFABET เป็นไปอย่างปลอดภัยและได้รับผลตอบแทนคุ้มค่าที่สุดในปี2026นี้

Overlook InfraTech: May The Source Be With You

2026-05-04T00:00:00+00:00

The roots of the OpenVox community are open source, and we’ve built our company and our products on that foundation. On this fine Star Wars Day I thought it would be a good time to talk a bit about why that’s important to us and why we regard the corporate rug-pull as such a breach of trust.

Throughout history the idea of building on the shoulders of giants is what enabled human innovation to progress. If the countless people who came before us hadn’t already invented or discovered steel, electricity, the wheel, integrated circuits and computing, thermodynamics, and so on then we’d still be living in huts barely scraping by. But never has that been more pronounced than with open source software that allows us not only to learn from the ideas of our predecessors but to literally use their work and just continue building with it or on top of it.

And the key to continued innovation is that as we inherit a foundation from our predecessors, we must provide for our successors to have the same opportunities to build further than we did. It may be trite, but there’s an old proverb of unclear origins that goes something like

A society grows great when old folk plant trees whose shade they know they shall never sit in.

Unfortunately rather than planting trees, today we see more private equity drones with a capitalistic gleam in their eye ruthlessly plundering for the hopes of short term profit even knowing that their actions will leave future generations with no shade to enjoy. This is, of course, not a new tendency. In the American Reconstruction period, these people were known as carpetbaggers.

Starting a company with open source software is like taking out a loan against the future. You get a free boost to your product, and all you have to do is contribute back so the next generation does too. However, fulfilling this promise takes more integrity than most companies can maintain once the ghouls come calling. Instead we see corporate rug-pulls where the OSS license is summarily changed or the source is sequestered behind a EULA, even when history shows that these tricks rarely improve financial outcomes!

Part of our strategy when starting Overlook InfraTech was to eschew investment dollars so that we’re never beholden to outsized return-on-investment demands. Instead, our success is measured on whether we can continue to meet customer needs and to pay our salaries. And rather than intellectual property hoarding, we focus on open source software and sustaining an ecosystem that enables all contributors to benefit.

Without the need to exploit, we can focus on excellence – both for you and for us. And so we say Happy Star Wars Day and May The Source Be With You.

Example 42: Pabawi Version One released

2026-04-14T00:00:00+00:00

Pabawi 1.0 Version 1.0 is out. I’ll skip the confetti. What I will say is this: there’s a meaningful difference between a project that works and a project that’s ready. v1.0 is my answer to the question “is this ready?” — ready for teams, ready for real infrastructure, ready to do things and not just show things. Here’s what landed. Provisioning: from observer to actor The biggest shift in v1.0 is conceptual. Until now, Pabawi was fundamentally a read tool — it could show you your infrastructure, surface Puppet reports, run Ansible plays, connect over SSH. Useful. But passive. Proxmox and AWS EC2 provisioning integrations change that. You can now create new nodes directly from Pabawi. Define the VM on Proxmox, spin up an EC2 instance, and have it land in your inventory, connected to your configuration management, ready to work. No context switching, no separate provisioning console. This is the transition from “one pane of glass to see things” to “one pane of glass to do things.” It matters more than the feature list suggests. Azure is still on the roadmap. It will follow. Nodes’ Live Journal At FOSDEM this year I was talking with Kris Buytaert — if you’ve been in the DevOps space long enough, you know Kris. We were somewhere between a coffee and a heated discussion about the state of classic infrastructure tooling, and he made an offhand remark that stuck: something along the lines of “you always have to go digging in four different tools to understand what happened to a node last week.” That’s the Journal. Every node now has a rolling, chronological log of everything Pabawi knows about it: Puppet runs and their outcomes, Ansible plays, SSH commands executed, provisioning events. The full picture, one place, no archaeology required. It sounds simple. It’s the kind of simple that takes a while to realize you needed. Inventory: multi-source and grouped The inventory view in v1.0 supports multiple simultaneous sources. You can pull nodes from PuppetDB, Ansible inventory, SSH discovery, and EC2 at the same time. They coexist. You see everything. Groups are also surfaced automatically — discovered from whatever each source natively provides. Ansible inventory groups, Puppet environments, Proxmox groups: Pabawi picks them up and exposes them without any manual configuration. You see the groupings that already exist in your infrastructure, reflected back at you. This is where “one pane of glass” stops being a tagline and starts being a description. New website pabawi.example42.com is live. Proper documentation, a getting started guide, architecture overview. Not a GitHub README with ambitions. If you’ve been putting off trying Pabawi because the docs were thin, now there’s no excuse. Updated Puppet module If you manage your infrastructure with Puppet and want to deploy Pabawi itself through it, the module at forge.puppetlabs.com/modules/example42/pabawi is updated for v1.0. Declare the class, set your parameters, done. The irony of managing a Puppet UI with Puppet is not lost on me — it’s also the right way to do it. What’s next The monitoring integrations (Icinga, CheckMK) are next. Bringing observability context into the same interface as configuration management is the logical next step, and it’s been on the roadmap since the beginning. Terraform and Azure provisioning are following behind. The pattern is the same: wherever you have servers you care about, Pabawi should be able to see them and help you act on them. Try it git clone https://github.com/example42/pabawi cd pabawi ./scripts/setup.sh Or with Docker: docker run -d \ --name pabawi \ -p 127.0.0.1:3000:3000 \ -v "$(pwd)/pabawi:/pabawi" \ --env-file ".env" \ example42/pabawi:latest Full docs now at pabawi.example42.com. If Pabawi looks useful for your infrastructure, try it. Open issues for what’s missing or broken — the roadmap is driven by real feedback, not guesswork. 👉 github.com/example42/pabawi If you find it useful, a GitHub star helps. If you want to get it running in your environment, reach out on LinkedIn — I’m still happy to do a shared-screen setup session, no strings attached. On behalf of Alessandro Franceschi

betadots: Puppet Enterprise - Neue Releases und Upgrade Zyklen

2026-04-08T13:59:44+00:00

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.

Puppet Blog: กาสิโน UFABET ศูนย์รวมเกมเดิมพันออนไลน์ครบวงจร มาตรฐานระดับโลก

2026-04-08T08:52:46+00:00

หากคุณกำลังมองหาประสบการณ์การเดิมพันที่สมบูรณ์แบบที่สุด กาสิโน ออนไลน์ของ UFABET คือจุดหมายปลายทางที่รวบรวมทุกความบันเทิงระดับพรีเมียมไว้ในที่เดียว เราคืออาณาจักรการเดิมพันที่ได้รับความไว้วางใจจากผู้เล่นทั่วเอเชีย ด้วยการนำเสนอเกมที่หลากหลาย เทคโนโลยีที่ทันสมัย และมาตรฐานการบริการที่โปร่งใส ทำให้ทุกวินาทีที่คุณเดิมพันกับเราคือความสนุกที่มาพร้อมกับโอกาสสร้างผลกำไรที่แท้จริง

สัมผัสประสบการณ์ กาสิโน ออนไลน์ที่เหนือระดับกับ UFABET

ที่ ยูฟ่าเบท เราให้ความสำคัญกับการคัดสรรสิ่งที่ดีที่สุดให้กับสมาชิก เพื่อให้คุณได้รับประสบการณ์การเล่นที่เหมือนกับการเดินทางไปนั่งในบ่อนระดับโลก:

ความหลากหลายของเกม: ไม่ว่าคุณจะเป็นสายกลยุทธ์ที่ชอบ เกมไพ่ อย่างบาคาร่าและมังกรไทเกอร์ หรือชอบความตื่นเต้นของ รูเล็ต และ ซิกโบ เรามีให้เลือกครบทุกรูปแบบ
พันธมิตรค่ายเกมยักษ์ใหญ่: เราเชื่อมต่อกับค่ายเกมชั้นนำทั่วโลก อาทิ SA Gaming, Sexy Baccarat, Evolution Gaming และค่ายสล็อตดังอย่าง PG Soft เพื่อให้สมาชิกเข้าถึงซอฟต์แวร์ที่ดีที่สุด
ระบบถ่ายทอดสดที่เสถียร: ทุกเกมสดถูกส่งตรงจากสตูดิโอในต่างประเทศด้วยระบบ Streaming ความละเอียดสูง ให้คุณเดิมพันได้อย่างต่อเนื่องไม่มีสะดุด

จุดเด่นที่ทำให้ กาสิโน ของเราเป็นอันดับ 1 ในใจนักเดิมพัน

ความแตกต่างที่ทำให้เรายืนหนึ่งในวงการ กาสิโน คือความมุ่งมั่นในการพัฒนาบริการ:

ความโปร่งใสตรวจสอบได้: ทุกการแจกไพ่และการออกรางวัลเป็นไปตามมาตรฐานสากล สมาชิกสามารถเห็นการเคลื่อนไหวของดีลเลอร์และผลลัพธ์ได้อย่างชัดเจน
อินเตอร์เฟซที่ใช้งานง่าย: ระบบถูกออกแบบมาให้รองรับการเล่นผ่านมือถือและคอมพิวเตอร์อย่างสมบูรณ์แบบ จัดแบ่งหมวดหมู่เกมอย่างชัดเจนเพื่อให้คุณค้นหาเกมโปรดได้ในไม่กี่วินาที
บริการระดับ VIP: ทีมงานแอดมินของเราพร้อมดูแลและแก้ไขปัญหาให้สมาชิกตลอด 24 ชั่วโมง เพื่อให้คุณมั่นใจในทุกการเดิมพัน

ระบบความปลอดภัยและการเงินที่มั่นใจได้ 100%

หัวใจสำคัญของการเล่น กาสิโน คือความปลอดภัยของข้อมูลและการเงิน:

ระบบรักษาความปลอดภัยสูง: เราใช้เทคโนโลยีการเข้ารหัสข้อมูลขั้นสูง เพื่อปกป้องข้อมูลส่วนตัวและบัญชีธนาคารของสมาชิกให้เป็นความลับสูงสุด
ธุรกรรมอัตโนมัติ: ระบบการจัดการเงินที่มีความแม่นยำสูง ช่วยให้การประมวลผลยอดเครดิตของคุณเป็นไปอย่างรวดเร็ว ไม่ว่าจะเป็นการฝากเพื่อเดิมพันหรือการถอนกำไรก้อนโต

ประเภทบริการ	เกมแนะนำ	จุดเด่น
คาสิโนสด	บาคาร่า, รูเล็ต, ไฮโล	ถ่ายทอดสด Real-time โปร่งใส 100%
เกมตู้ (E-Games)	สล็อต, ยิงปลา	กราฟิกสวยงาม รางวัลแจ็กพอตสูง
เกมกระดาน	ป๊อกเด้ง, น้ำเต้าปูปลา	รูปแบบที่คุ้นเคย เล่นง่าย ได้เงินไว

FAQ: รวมสิ่งที่ควรรู้ก่อนเริ่มต้นเดิมพัน กาสิโน ออนไลน์

1. กาสิโนออนไลน์ของ UFABET เชื่อถือได้แค่ไหน?

ตอบ: เราเป็นเว็บตรงที่มีใบอนุญาตการดำเนินงานอย่างถูกต้อง มีรากฐานทางการเงินที่มั่นคงและดำเนินธุรกิจมาอย่างยาวนาน สมาชิกจึงมั่นใจได้ว่าเราจ่ายจริงทุกยอดชนะครับ

2. ต้องใช้ทุนเท่าไหร่ถึงจะเริ่มเล่นได้?

ตอบ: ระบบของเราเปิดโอกาสให้ผู้เล่นทุกระดับทุนครับ โดยหลายเกมเริ่มต้นเดิมพันขั้นต่ำเพียง 10 บาทเท่านั้น ซึ่งสามารถศึกษารายละเอียดเพิ่มเติมได้ในเมนูช่วยเหลือหรือหน้า FAQ ของระบบครับ

3. หากมีปัญหาเรื่องการใช้งาน ต้องทำอย่างไร?

ตอบ: ท่านสามารถติดต่อทีมงานซัพพอร์ตผ่านช่องทางแชทสดได้ตลอด 24 ชั่วโมง เรามีทีมงานมืออาชีพคอยสแตนบายให้ความช่วยเหลือท่านในทุกขั้นตอนครับ

บทสรุป: ก้าวเข้าสู่โลกแห่งความบันเทิงที่ กาสิโน UFABET วันนี้

หากคุณกำลังมองหาทางเลือกที่ดีที่สุดในการเดิมพัน กาสิโน ออนไลน์ที่ครบวงจร ปลอดภัย และมีอัตราจ่ายที่คุ้มค่า UFABET คือคำตอบที่ใช่สำหรับคุณ เราพร้อมเป็นส่วนหนึ่งที่จะพาคุณไปสัมผัสความสนุกที่ไม่มีวันสิ้นสุดและโอกาสในการคว้ากำไรมหาศาล

สมัครสมาชิกวันนี้ เพื่อเริ่มต้นการเดินทางครั้งใหม่ในอาณาจักรกาสิโนที่ดีที่สุดไปพร้อมกับเราครับ!

Laurent Domb Blog: Directing AI, Not Chasing It: Why Your SDLC and PDLC Must Evolve

2026-03-28T12:58:20+00:00

How cognitive overload is undermining the AI productivity promise, and what leaders must change in their development and product pipelines to fix it.

In the past three years, I’ve worked on GenAI enablement across financial services, first as a Chief Technologist at AWS, and now as SVP for our Mastercard’s Software Builders Experience program. And I keep running into the same problem. Different job families approach AI tooling through the lens of what they already know. The questions we ask are shaped by the problems we’ve solved before, and our imagination for what a tool can do is bounded by the scope we’re comfortable operating in. That knowledge gap isn’t abstract, it directly limits how teams consume AI.

At Mastercard, I’ve been working with an incredible group of people focused on re-imagining the SDLC and PDLC. We measure developer experience through CORE4, SPACE, DORA, and other frameworks. We’ve invested in giving our developers the latest tooling so they can move faster than ever. And like most of our industry peers, we introduced code assistants. The data we got back told us something we didn’t expect: code was moving faster from developer to pipeline, but revert rates spiked, PR sizes ballooned, and it became clear that our SDLC and PDLC flows were not built for AI-scale development.

Three pieces published in quick succession crystallized what I was seeing. Francesco Bonacci wrote about “Vibe Coding Paralysis”, the exhaustion of managing AI, not doing the work. BCG and Harvard Business Review published research quantifying “AI Brain Fry” across 1,488 workers. And Carlos Arguelles at Amazon declared the traditional testing outer loop dead. Each was describing a different facet of the same problem. None connected them. This article is my attempt to do that, and to propose what the SDLC and PDLC need to look like on the other side.

To be clear, this isn’t a victory lap. We haven’t implemented this yet. This is a framework we’re building toward, informed by what the data is already telling us and what these three pieces helped me crystallize. I’m publishing it now because I think the industry needs to have this conversation before the patterns calcify.

The Paradox: AI Makes Us Frantic, Not Fast

AI was supposed to make us faster. Instead, it’s making many of us frantic.

Across the software industry, developers spin up multiple AI coding sessions, watch features scaffold in minutes, and end the day exhausted, not from building, but from managing the building. Product managers generate roadmap scenarios, competitive analyses, and PRDs at unprecedented speed, yet struggle to commit to a single direction. The raw capability is real. The coherent output is not.

Bonacci’s description hit a nerve: “I end each day exhausted, not from the work itself, but from the managing of the work. Six worktrees open, four half-written features, two ‘quick fixes’ that spawned rabbit holes, and a growing sense that I’m losing the plot entirely.”

The BCG/HBR data put numbers to the feeling. Workers experiencing AI brain fry report 33% more decision fatigue, 39% more major errors, and a 39% increase in intent to quit.

The promise was amplification. The reality, for many, is fragmentation. And the root cause isn’t the technology, it’s that our development pipelines, role structures, and organizational incentives were designed for a world where implementation was the bottleneck. That world no longer exists. Coherence, judgment, and cognitive capacity are the new bottlenecks, and our systems haven’t caught up.

Directing vs. Chasing: The Divide That Explains Everything

Not everyone struggles equally with AI. Observing how different roles interact with AI tools reveals a critical distinction: some professionals naturally direct AI, while others end up chasing it.

Directing means approaching AI with a clear problem frame, defined constraints, and a mental model of what “done” looks like. The human steers; the AI executes within boundaries.

Chasing means reacting to AI output, re-prompting, re-planning, spinning up new streams, without a stable anchor point. The AI generates; the human scrambles to keep up.

This distinction maps unevenly across three key personas in software organizations.

The Solutions Architect: Natural Director

Solutions Architects operate at the altitude of system coherence,decomposing problems, defining boundaries, making tradeoff decisions. When an architect engages AI, they bring constraints: “Design a system that handles X throughput with Y latency, using Z technology stack, within these cost boundaries.” AI explores the solution space; the architect evaluates and decides.

Architects are the most resilient to AI-induced cognitive overload because their core value, system vision and judgment, remains firmly human. AI doesn’t erode their confidence; it validates their thinking faster.

The Software Developer: Most Vulnerable to Chasing

Developers face the sharpest disruption. Their traditional value proposition, writing code, is the layer AI has most directly commoditized. This creates a cascade of vulnerabilities.

The confidence spiral. When AI writes most of the code, developers begin questioning their own understanding. As Bonacci describes: “When something breaks, and something always breaks, you’re staring at code you didn’t fully write, solving a problem you didn’t fully understand, in a codebase that’s grown faster than your mental model of it.” The response? Prompt more. Defer more. Learn less. Spiral continues.

Maximum oversight burden. The BCG/HBR study found that AI oversight, not mere use, is the most cognitively taxing engagement pattern, producing 14% more mental effort, 12% more fatigue, and 19% more information overload. Developers bear this burden most directly.

Reactive parallelization. The tooling actively encourages it: worktrees, background agents, parallel sessions. On paper, velocity soars. In practice, attention fragments. The research quantified the cliff: productivity gains plateau and then decline after three simultaneous AI tools.

Misaligned metrics. When organizations measure lines of AI-generated code or token consumption as performance proxies, they structurally incentivize chasing, rewarding volume of AI interaction, not quality of AI-directed outcomes.

The HBR study’s most telling finding about developers: “The ones who are most advanced with AI start to feel blocked in progress unless they can develop critical new skills such as problem framing, analysis planning, and strategic prioritization.”

These are architect-level skills. Some senior developers do get there, I’ve seen some amazing Senior Principal Engineers who think and operate like architects, having built that muscle across different projects, products, and scales over the course of a career. But it’s the exception, not the norm, and it’s certainly not a path today most organizations deliberately cultivate. It should be.

The Product Manager: Chasing in Disguise

Product managers occupy a deceptive position. Their role, problem framing, prioritization, outcome definition, should make them natural directors. In practice, AI introduces a unique form of chasing that is harder to detect precisely because it looks like strategic work.

The planning loop on steroids. AI generates competitive analyses, personas, market sizing, and roadmap scenarios in minutes. Each artifact feels like progress. But the actual decision, what will we commit to building? Keeps getting deferred. Planning becomes procrastination in disguise.

The possibility explosion. For developers, AI expands what they can build. For PMs, AI expands what they can envision. The PM equivalent of six open worktrees is six roadmap variants, each plausible, none committed to. The old forcing function, implementation was expensive, so you had to choose, is gone. Decision paralysis fills the vacuum.

Validation theater. PMs can now synthesize user feedback and build business cases at extraordinary speed. The danger: AI becomes a justification engine rather than a discovery tool, confirming decisions already made, manufacturing the appearance of rigor without the substance of genuine inquiry.

Loss of customer intuition. When AI processes all your customer signals, you stop building the gut-level understanding that comes from sitting with messy, ambiguous, human feedback. PMs know what the data says but lose the feel for the customer, the intuition that was never in the data to begin with.

Why the Traditional SDLC and PDLC Can’t Handle This

The traditional Software Development Lifecycle was designed around a simple assumption: implementation is slow and expensive, so front-load planning to minimize rework.

AI inverts this. Implementation is now fast and cheap. But the pipelines haven’t adapted. Organizations are pouring AI-accelerated code through processes designed for human-speed development, and the seams are showing. Features ship faster than they can be validated. Code merges faster than it can be understood. Developers approve PRs for code they didn’t write and don’t fully comprehend, building what Bonacci calls “a house of cards, each card placed by a different Claude session, each card slightly misaligned with the others.” More gets built, but less coheres.

The PDLC faces a parallel failure. It assumes that deciding what to build is the hard, slow part, and that once decided, the build phase imposes natural discipline. With AI, the build phase no longer imposes discipline. PMs must create that discipline themselves, and the PDLC doesn’t help them do it.

The Validation Crisis Underneath

There’s a dimension of this breakdown that goes beyond cognition and roles, it’s infrastructure. Arguelles’ argument about the dead outer loop crystallizes the technical crisis hiding beneath the people problem.

For decades, software testing operated on a simple split. The inner loop, a developer’s local machine, ran unit tests in seconds, keeping you in flow state. The outer loop, CI/CD pipelines, integration suites, E2E environments, ran the heavier tests that caught catastrophic bugs at the seams between components. This split worked because humans wrote code slowly enough that a multi-hour CI/CD cycle was acceptable feedback.

AI broke this contract. Engineers generate code at an order of magnitude faster speed, but the outer loop didn’t get faster. More changes per day means more runs against the same fragile infrastructure, more flaky failures, more retries, more erosion of trust.

The problem goes deeper than throughput. AI-generated code has a characteristic failure mode: today it works in isolation but fails at the seams. The code is based on the context the AI has been given, typically a single file, a single service, a single component. It passes unit tests because they validate components in isolation, which is exactly the scope the model had when generating the code. But failures surface in integration, hours later, after context is lost, after other engineers have built on top of your changes.

This is the technical manifestation of the coherence problem. Each AI session has context for one component, not the system. And the infrastructure that should catch the misalignment, integration testing, is too slow, too flaky, and too late.

The cognitive cost compounds. When integration feedback arrives hours later through a flaky CI/CD pipeline, the developer has already moved on to other tasks, spawned new AI sessions, built more cards on the house. The late, unreliable signal forces them to context-switch back, debug whether the failure is real or environmental, and potentially unwind work that others have already built upon. The dead outer loop isn’t just a testing problem, it’s a cognitive load amplifier.

The AI-Era SDLC

The new pipeline must expand the phases where humans direct, compress the phases where AI executes, and introduce new gates where coherence is verified.

Problem Frame becomes the most important phase. Before any AI interaction, teams must articulate: What problem are we solving? What are the constraints? What does “done” look like? What is explicitly out of scope? This is the “directing” document. Without it, everything downstream becomes reactive. With spec-driven development, where humans and AI collaborate on requirements and design documents before generating code, the problem frame also becomes the source from which validation criteria are auto-generated.

Decompose becomes a first-class engineering activity. Systems are broken into bounded, well-scoped units with clear acceptance criteria. Each unit is small enough that a developer can hold it in their head, because that mental model is what prevents the confidence spiral. Critically, decomposition must also define the integration contracts between components, the seams where AI-generated code most frequently fails.

A word of caution: the pipeline diagram above implies decomposition happens once, upstream, as a planning activity. In practice, it’s iterative. You start with a decomposition, direct AI against the first unit, learn something about the integration surface you didn’t anticipate, and adjust the decomposition of the next unit. The best teams treat decomposition as a living artifact, not a phase gate you pass through once. The principle matters more than the sequence, and Bonacci’s version of that principle applies: “The plan doesn’t have to be perfect. It has to be done.”

Direct AI + Continuous Validation replaces both “Implement” and the traditional “Test” phase. Instead of generating code now and validating later, validation signals run continuously during development, in the inner loop. The developer directs AI within guardrails (maximum two to three concurrent streams, each scoped to a decomposed unit), and the pipeline provides integration and contract test signals in real time.

This requires four infrastructure investments: reliable test environments that eliminate the “is this real or environmental?” question (Google uses hermetic, ephemeral environments; Uber injects test traffic into production graphs); mutation-tested validation that measures what was actually verified, not just what was touched; smart test selection that analyzes what changed and runs only relevant tests (Meta’s implementation catches 99.9% of faulty changes while reducing test executions by 3x); and evaluation-based assessment that asks “does this achieve what the builder intended?” rather than just “does it pass?”

Coherence Gate is entirely new. Before merging AI-generated code, a human must demonstrate they understand it, not just that tests pass. The gate is strengthened by the continuous validation signals: developers have real integration feedback confirming the code works at the seams, not just green unit tests in isolation.

Evaluate reflects the most profound conceptual shift: the question moves from “does this code work?” to “does this change achieve what the builder intended and adds customer value?” As systems grow more agentic and non-deterministic, the same input can legitimately produce different outputs. You need judges that assess whether a response is appropriate, and critically, know when to escalate to a human.

The AI-Era PDLC

Discover goes deeper, not faster. AI can synthesize a thousand support tickets in minutes. The temptation is to accelerate discovery. The right move is to go deeper, use the time savings for qualitative work AI can’t do: observe users, develop intuition, sit with ambiguity. The HBR study found that using AI to eliminate toil reduces burnout by 15%. Use AI to remove the grunt work from discovery, not to skip discovery itself.

Frame demands sharper problem statements. Before any AI-assisted solution generation, the PM must articulate a tight problem frame: Who is the user? What is the pain? What is the measurable outcome? What is explicitly out of scope? This is the PM’s “directing” artifact. Without it, the development pipeline has no anchor.

Commit is an entirely new phase, and the hardest cultural change in the AI-era PDLC. In the old world, commitment was forced by implementation cost: you couldn’t build everything, so you had to choose. AI removes that forcing function. PMs must now impose commitment discipline themselves. Once a direction is chosen, alternatives are killed explicitly. No “keeping option B warm.”

Constrain is also new. PMs must define the cognitive budget for a feature, not just the scope. How many concurrent AI streams should engineering run? What’s the maximum PR size? What coherence checkpoints are required? This operationalizes the HBR finding that three-plus simultaneous AI tools degrade productivity. The PM doesn’t just define what to build, they define the cognitive parameters of how it gets built.

Co-Direct replaces the handoff. The old “throw the PRD over the wall” model assumed a slow build phase that naturally surfaced misalignments. With AI generating implementations in hours, the feedback loop between PM intent and engineering output must tighten dramatically. Structured checkpoints, not constant oversight, where the PM validates that system-level direction matches the problem frame.

Coherence Check gates launch. Not “does it work?” but “does it matter?” AI-accelerated development produces more features faster. Without this gate, products accumulate capability nobody asked for, built because it was easy, not because it was needed.

Measure Outcomes, not output. Velocity, features shipped, story points, these are now inflated by AI and effectively meaningless. Measure customer outcomes (adoption, retention, satisfaction), decision quality (how often do we build right the first time?), and product coherence (does the product tell a unified story?).

The Unified Pipeline: Three Altitudes of Direction

When the SDLC and PDLC are overlaid, the organizational design becomes clear. Each role directs at a different altitude, and the pipeline must enforce that each altitude does its job:

Product Managers direct at the outcome altitude. They own the problem frame and the commitment. Their job is to say what needs to be true for the customer, and to say no to everything else. Their problem frame also serves as the source for evaluation criteria: the specs from which intent-based validation is generated.

Solutions Architects direct at the system altitude. They own the decomposition and the boundaries. Their job is to ensure that what gets built coheres as a system, regardless of how fast individual pieces are generated. They also own the integration contracts, the interface definitions where AI-generated code most frequently fails, which feed directly into the continuous validation loop.

Developers direct at the implementation altitude. They own the AI interaction and the understanding. Their job is to ensure that code is not just functional but comprehended, that their mental model keeps pace with the codebase. The continuous validation loop gives them something the old outer loop never did: real-time integration feedback during development, not hours-late signals through flaky CI/CD.

The Coherence Gate is shared. All three roles must pass it: Does this solve the problem? (PM) Does this fit the system? (Architect) Do I understand this code? (Developer) This shared gate is the most important new artifact in the pipeline, backed not just by human assertion, but by evidence from reliable, mutation-tested, efficiently-selected test suites that validate both functional correctness and builder intent.

Six Organizational Imperatives

The pipeline changes won’t work without supporting organizational shifts. Drawing from BCG’s research that 70% of AI transformation effort should focus on people and processes:

1. Upskill for Direction, Not Just Execution. Developers need training in problem framing, decomposition, and strategic prioritization. The skills the HBR study identifies as critical for advanced AI users. This isn’t about making developers into architects. It’s about ensuring every role can direct at their altitude rather than defaulting to chasing.

2. Establish AI Spans of Control. Just as organizations define spans of control for managing humans, they must define limits for human-AI oversight. The research is clear: productivity declines after three simultaneous AI tools. Make this a policy, not a suggestion.

3. Shift Metrics from Activity to Impact. Incentivizing token consumption, lines of AI-generated code, or raw velocity produces waste, low-quality work, and unnecessary mental strain. Start from business objectives with measurable outcomes. And don’t rush to backfill work recently automated by an innovative team member, doing so immediately feels punitive and kills further innovation.

4. Make Managers Accountable for AI Enablement. The HBR data is unambiguous: workers whose managers actively answer their questions about AI had 15% lower mental fatigue scores. When managers expect employees to “figure it out on their own,” there’s a measurable 5% increase in fatigue, a small but real “AI orphan tax.” Manager engagement with AI isn’t optional; it’s a direct lever on team cognitive health.

5. Protect Cognitive Capacity as a Strategic Resource. Mental fatigue is more likely to go undetected than burnout in existing workplace surveys. Organizations must evolve people analytics to monitor cognitive load as a novel occupational risk. Build recovery time, deliberate non-AI thinking time, into sprint cadences, because sometimes the thinking is the work.

6. Invest in Continuous Validation Infrastructure. Every hour spent waiting for CI/CD, every flaky test debugged, every context-switch back to code you’ve already mentally left compounds the brain fry problem. Organizations must invest in reliable test infrastructure, meaningful validation, efficient execution, and evaluation-based assessment. This is not optional infrastructure modernization, it’s a prerequisite for every other change in this article. You cannot direct AI effectively when your validation signals arrive too late to act on.

The Bottom Line

The developer disadvantage isn’t about capability, it’s about operating altitude. Architects naturally work at the altitude where AI is directed. Developers were trained to work at the altitude where AI now operates. Product managers sit at the right altitude but lack the organizational structures to enforce the commitment discipline that AI demands.

The fix isn’t to transform every developer into an architect or every PM into a strategist. It’s to retool the SDLC and PDLC so that every role spends more time directing and the pipelines themselves enforce the guardrails that prevent chasing.

The organizations that will thrive in the AI era aren’t the ones that adopt AI fastest. They’re the ones that learn to direct it most coherently, across every role, at every altitude, through pipelines purpose-built for a world where the bottleneck is no longer building, but knowing what to build and why.

The tools are new. The failure modes are new. But the solution is ancient: discipline, focus, and the courage to commit, now encoded into the systems we use to build.

This is my practitioner’s view, shaped by what I’ve seen across financial services since the rise of GenAI and what I am learning at Mastercard in real time. I’d love to hear whether this resonates with what you’re experiencing. Are your teams directing AI or chasing it? Has your SDLC held up, or are you seeing the same cracks? Drop a comment or share your story, the more perspectives we bring to this, the faster we all figure it out.

betadots: How to keep your Puppet modules up to date with Renovate

2026-03-25T16:14:50+00:00

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 Blog: ไฮโล UFABET แทงไฮโลออนไลน์พื้นบ้าน อัตราจ่ายสูง จบไว ได้เงินจริง

2026-03-17T04:20:45+00:00

หากพูดถึงเกมเดิมพันที่อยู่คู่กับสังคมไทยมาอย่างยาวนาน ไฮโล (Hilo) คือชื่อแรกที่ทุกคนนึกถึง และในวันนี้ UFABET ได้ยกระดับเกมพื้นบ้านนี้เข้าสู่ระบบออนไลน์ที่ทันสมัยที่สุด คุณไม่จำเป็นต้องไปหาที่เล่นตามงานวัดหรือบ่อนเถื่อนอีกต่อไป เพราะเรายกโต๊ะไฮโลมาตรฐานสากลมาไว้บนมือคุณ พร้อมดีลเลอร์สดที่ทำการเขย่าลูกเต๋าให้เห็นกันแบบวินาทีต่อวินาที มั่นใจได้ในความโปร่งใสและผลตอบแทนที่สูงกว่าที่เคยสัมผัส

สนุกกับ ไฮโล ออนไลน์ที่ UFABET แตกต่างจากที่อื่นอย่างไร?

การเลือกเล่น ไฮโล กับยูฟ่าเบทมอบประสบการณ์ที่เหนือชั้นกว่าการเล่นทั่วไป:

ความโปร่งใสที่ตรวจสอบได้: เราใช้โหลแก้วใสในการเขย่าลูกเต๋า และมีการถ่ายทอดสดแบบ Real-time มุมกล้องคมชัด เห็นลูกเต๋าชัดเจนทุกเม็ด ป้องกันปัญหาการใช้แม่เหล็กหรือการต้มตุ๋นทุกรูปแบบ
ตัวเลือกการเดิมพันที่หลากหลาย: นอกจาก สูง-ต่ำ หรือ เต็ง-โต๊ด แบบเดิมๆ แล้ว ในระบบออนไลน์ยังมีตัวเลือกการแทงแบบระบุแต้มรวม หรือแทงตองที่มีอัตราจ่ายสูงถึง 150 เท่า!
ไม่มีการหักค่าน้ำเยอะ: อัตราจ่ายของเราเป็นธรรมและให้ราคาดีที่สุด ช่วยให้ผู้เล่นได้รับกำไรแบบเต็มเม็ดเต็มหน่วย

วิธีการเล่น ไฮโล เบื้องต้นและการทำกำไรจากตัวเลข

สำหรับมือใหม่ที่ต้องการเริ่มต้นทำกำไรจากเกมลูกเต๋า กติกาพื้นฐานนั้นง่ายมาก:

การแทง สูง-ต่ำ: เป็นที่นิยมที่สุด โดยแต้มรวม 3-10 คือ “ต่ำ” และ 11-18 คือ “สูง”
การแทงเต็งเลข: คือการทายว่าลูกเต๋า 1 ใน 3 ลูกจะออกเลขอะไร (1-6)
การแทงโต๊ด: คือการทายเลข 2 ตัวที่จะออกพร้อมกันในตานั้นๆ
เทคนิคการวิเคราะห์: ในหน้าจอเดิมพันจะมี “ตารางสถิติย้อนหลัง” ให้คุณได้วิเคราะห์แนวโน้มของแต้มในรอบที่ผ่านมา เพื่อช่วยในการตัดสินใจวางเดิมพันในตาถัดไป

รูปแบบการแทง	อัตราจ่าย (เท่า)	ความน่าจะเป็น
สูง – ต่ำ	1 : 1	สูงมาก
เต็งเลข	1 : 1 (ต่อลูก)	ปานกลาง
แทงโต๊ด (เลขคู่)	1 : 5	ปานกลาง
แทงตอง (ระบุเลข)	1 : 150	ต่ำ (รางวัลใหญ่)

ข้อดีของการเล่น ไฮโล ผ่านระบบคาสิโนสด

การเล่น ไฮโล ในหมวดคาสิโนสดของ UFABET ช่วยเพิ่มอรรถรสในการเดิมพัน:

บรรยากาศจริง: คุณจะได้เห็นดีลเลอร์ตัวจริงทำการเขย่าลูกเต๋า ได้ยินเสียง และเห็นภาพสดๆ จากคาสิโน
เปิดให้บริการ 24 ชม.: ไม่ว่าคุณจะอยากลุ้นตอนไหน เพียงแค่ เข้าสู่ระบบ ก็สามารถร่วมสนุกได้ทันที
ระบบการเงินมั่นคง: เมื่อชนะเดิมพัน ยอดเงินจะถูกปรับเข้าบัญชีเครดิตของคุณโดยอัตโนมัติ และสามารถทำรายการถอนได้ทันทีผ่านระบบออโต้

FAQ: รวมคำถามที่พบบ่อยสำหรับนักเดิมพัน ไฮโล

1. แทงไฮโลออนไลน์ขั้นต่ำกี่บาท?

ตอบ: ที่ UFABET คุณสามารถเริ่มต้นวางเดิมพันไฮโลขั้นต่ำเพียง 10 บาทเท่านั้นครับ เหมาะสำหรับทั้งผู้เล่นที่ต้องการทดลองสูตรและผู้เล่นมืออาชีพ

2. ผลลัพธ์ลูกเต๋าเชื่อถือได้แค่ไหน?

ตอบ: ระบบของเราได้รับมาตรฐานสากล มีการตรวจสอบอุปกรณ์ทุกรอบ และเป็นการถ่ายทอดสดจากบ่อนจริง ท่านสามารถตรวจสอบความโปร่งใสได้จากหน้าจอเดิมพันตลอดเวลาครับ

3. มีสูตรไฮโลแจกฟรีไหม?

ตอบ: ในหน้าเว็บไซต์ของเรามีบทความแนะนำเทคนิคการเดินเงินและการอ่านสถิติเบื้องต้นให้สมาชิกได้ศึกษาครับ รายละเอียดเพิ่มเติมสามารถดูได้ที่ส่วน FAQ หรือบทความแนะนำกลยุทธ์ครับ

บทสรุป: สัมผัสความมันส์ระดับตำนานไปกับ ไฮโล UFABET

เปลี่ยนเกมพื้นบ้านให้กลายเป็นโอกาสสร้างรายได้ที่มั่นคงไปกับ ไฮโล ออนไลน์บนเว็บตรง UFABET ด้วยระบบที่ทันสมัย ปลอดภัย และจ่ายเงินจริง 100% ทำให้เราเป็นอันดับ 1 ในใจนักเดิมพันชาวไทยเสมอมา

สมัครสมาชิกวันนี้ เพื่อร่วมลุ้นระทึกไปกับเสียงลูกเต๋าและคว้าเงินรางวัลก้อนโตไปพร้อมกับเราครับ!

Puppet Blog: บาคาร่า UFABET เว็บตรงอันดับ 1 รวมค่ายดัง เล่นง่าย ถอนได้จริง

2026-03-17T04:20:23+00:00

หากพูดถึงเกมที่เป็นราชาแห่ง กาสิโน คงหนีไม่พ้น บาคาร่า (Baccarat) เกมไพ่ที่ได้รับความนิยมสูงสุดทั่วโลก ด้วยรูปแบบการเล่นที่รวดเร็ว เข้าใจง่าย และมีโอกาสชนะสูง ที่ UFABET เราได้รวบรวมโต๊ะบาคาร่าจากค่ายชั้นนำระดับโลกมาไว้ให้บริการสมาชิกในรูปแบบ “คาสิโนสด” (Live Casino) ที่ส่งตรงบรรยากาศจริงจากบ่อนกาสิโนมาถึงหน้าจอคุณ มั่นใจได้ในความโปร่งใสและระบบการเงินที่มั่นคงที่สุด

ทำไมต้องเล่น บาคาร่า กับ UFABET? ประสบการณ์ที่เหนือกว่าใคร

การเลือกเล่นบาคาร่าออนไลน์กับเว็บตรงอย่าง ยูฟ่าเบท มอบความได้เปรียบให้คุณในหลายด้าน:

รวมค่ายยักษ์ใหญ่: เรามีพาร์ทเนอร์ระดับโลกอย่าง SA Gaming, Sexy Baccarat, Evolution Gaming และ Venus Casino ให้คุณสลับเปลี่ยนบรรยากาศการเล่นได้ไม่มีเบื่อ
ระบบถ่ายทอดสดที่เสถียรที่สุด: สัญญาณภาพคมชัดระดับ Full HD เห็นทุกรายละเอียดการแจกไพ่ชัดเจน ไม่มีภาพสะดุดหรือดีเลย์
ค่าคอมมิชชั่นสูง: สมาชิกจะได้รับค่าคอมมิชชั่นคืน 0.7% ในทุกยอดการวางเดิมพันบาคาร่า ซึ่งถือเป็นเรทที่สูงที่สุดในตลาด

จุดเด่นของเกม บาคาร่า ออนไลน์: สนุก ลุ้นระทึก ทุกวินาที

เสน่ห์ของ บาคาร่า คือความง่ายที่ไม่ซับซ้อน แต่แฝงไปด้วยความตื่นเต้น:

กติกาเข้าใจง่าย: เพียงเลือกเดิมพันระหว่าง ฝั่งผู้เล่น (Player), ฝั่งเจ้ามือ (Banker) หรือ เสมอ (Tie) ใครมีแต้มใกล้เคียง 9 มากที่สุดจะเป็นผู้ชนะ
เดิมพันขั้นต่ำเพียง 10 บาท: ไม่ว่าจะมีทุนเท่าไหร่ก็สามารถร่วมสนุกและปั้นผลกำไรได้จริง
ความรวดเร็ว: ในแต่ละตาใช้เวลาเพียง 30-45 วินาที ทำให้คุณสามารถทำกำไรได้อย่างรวดเร็วในเวลาสั้นๆ

เทคนิคการเล่น บาคาร่า เบื้องต้นสำหรับมือใหม่

เพื่อให้การเล่นบาคาร่าของคุณมีโอกาสชนะมากขึ้น ควรศึกษาแนวทางเบื้องต้นดังนี้:

การอ่านเค้าไพ่: สังเกตสถิติย้อนหลังในตาราง (Roadmap) เพื่อดูแนวโน้มว่าไพ่ออกมาในลักษณะใด เช่น เค้าไพ่มังกร หรือเค้าไพ่ปิงปอง
การบริหารเงินทุน: ควรกำหนดงบประมาณในการเล่นในแต่ละวัน และกำหนดเป้าหมายกำไรที่ต้องการ เมื่อได้ตามเป้าแล้วควรหยุดพักเพื่อรักษาเงินกำไรไว้
เลือกฝั่งเจ้ามือ: ในระยะยาว การเดิมพันฝั่งเจ้ามือ (Banker) มีค่า House Edge ที่ต่ำกว่าฝั่งผู้เล่นเล็กน้อย (แม้จะมีค่าตง 5% ก็ตาม)

ค่ายเกมแนะนำ	จุดเด่น	สไตล์ดีลเลอร์
Sexy Baccarat	มีความสนุกสนาน เป็นกันเอง	ดีลเลอร์สาวสวยสวมบิกินี่
SA Gaming	มาตรฐานสูง ระบบสากล	ดีลเลอร์มืออาชีพ ชุดสุภาพ
Evolution Gaming	มีมุมกล้องที่หลากหลาย 4K	สไตล์ยุโรป หรูหรา

FAQ: รวมคำถามที่พบบ่อยเกี่ยวกับ บาคาร่า ออนไลน์

1. บาคาร่าออนไลน์เล่นแล้วได้เงินจริงไหม?

ตอบ: ได้เงินจริงแน่นอนครับ หากคุณเลือกเล่นกับ UFABET เว็บตรงที่ไม่ผ่านเอเย่นต์ เรามีความมั่นคงทางการเงินสูง ชนะหลักแสนหรือหลักล้านก็ถอนได้ทันที

2. สูตรบาคาร่าที่มีแจกทั่วไปใช้ได้จริงหรือเปล่า?

ตอบ: สูตรหรือโปรแกรมคำนวณเป็นเพียงตัวช่วยในการตัดสินใจจากสถิติครับ การเล่นที่ได้ผลที่สุดคือการมีสติและการอ่านเค้าไพ่ด้วยตัวเองประกอบกับการเดินเงินที่เหมาะสม

3. สามารถทดลองเล่น บาคาร่า ก่อนได้ไหม?

ตอบ: ทางเรามีระบบทดลองเล่นในบางค่าย หรือคุณสามารถเข้าไปดูบรรยากาศในห้องเดิมพันจริงก่อนวางเงินเดิมพันได้ครับ รายละเอียดเพิ่มเติมสามารถสอบถามแอดมินหรือดูที่หน้า FAQ ของระบบได้เลย

บทสรุป: มั่นใจทุกการวางเดิมพัน บาคาร่า ไปกับ UFABET

หากคุณกำลังมองหาเว็บสำหรับเล่น บาคาร่า ที่ปลอดภัย ภาพสวย และจ่ายเงินจริง UFABET คือคำตอบที่ดีที่สุด เราพร้อมให้บริการคุณด้วยมาตรฐานระดับโลกตลอด 24 ชั่วโมง

เริ่มต้นความรวยวันนี้ สมัครสมาชิกกับเราและสัมผัสความสนุกของบาคาร่าที่ดีที่สุดในเอเชียไปพร้อมกับเราครับ!

Puppet Blog: หวยออนไลน์ UFABET แทงง่าย จ่ายหนัก อัตราจ่ายสูงที่สุดในไทย

2026-03-17T04:20:04+00:00

สำหรับนักเสี่ยงโชคที่กำลังมองหาช่องทางในการซื้อหวยที่คุ้มค่าและปลอดภัยที่สุด หวยออนไลน์ บนแพลตฟอร์ม UFABET คือคำตอบที่คุณต้องการ เราให้บริการรับแทงหวยครบวงจรด้วยระบบที่ทันสมัย ใช้งานง่ายผ่านมือถือ และที่สำคัญที่สุดคือเรามีอัตราการจ่ายที่สูงกว่าหวยใต้ดินทั่วไป พร้อมระบบการจัดการที่มีความมั่นคงทางการเงินระดับสากล ทำให้คุณมั่นใจได้ว่าทุกตัวเลขที่คุณแทงจะได้รับค่าตอบแทนที่ยุติธรรมและจ่ายจริงทุกบาททุกสตางค์

ทำไมต้องแทง หวยออนไลน์ กับ UFABET? มั่นคง ปลอดภัย 100%

การซื้อหวยผ่านระบบออนไลน์ของ ยูฟ่าเบท มีข้อดีที่เหนือกว่าการซื้อผ่านเจ้ามือทั่วไปอย่างชัดเจน:

อัตราจ่ายสูงที่สุด: เราให้อัตราจ่ายเลขท้าย 3 ตัว และ 2 ตัว ในระดับที่สูงที่สุดในตลาด ช่วยให้คุณได้รับกำไรที่มากขึ้นจากเงินลงทุนเท่าเดิม
ไม่มีเลขอั้น (หรือน้อยมาก): เราเปิดรับแทงเกือบทุกตัวเลข รวมถึงเลขเด็ดเลขดังที่เจ้ามือทั่วไปมักจะปิดรับ ทำให้คุณไม่พลาดโอกาสในการทำกำไร
ระบบตรวจหวยอัตโนมัติ: เมื่อผลรางวัลออก ระบบจะทำการตรวจรางวัลให้คุณทันที และปรับยอดเงินเข้าบัญชีเครดิตอย่างรวดเร็วโดยไม่ต้องรอนาน

ประเภท หวยออนไลน์ ที่เปิดให้บริการ: สนุกได้ทุกวันไม่มีหยุด

ที่ UFABET เราไม่ได้มีแค่หวยรัฐบาลไทยเท่านั้น แต่เรายังมีหวยประเภทอื่นๆ ให้คุณได้ลุ้นรวยได้ตลอดทั้งวัน:

หวยรัฐบาลไทย: เปิดรับแทงล่วงหน้าก่อนวันหวยออก พร้อมอัตราจ่ายที่เร้าใจ
หวยฮานอย (หวยเวียดนาม): มีให้เล่นทุกวัน ทั้งฮานอยปกติ ฮานอยพิเศษ และฮานอย VIP
หวยลาว (ลาวพัฒนา): ออกรางวัลสัปดาห์ละ 3 วัน (จันทร์, พุธ, ศุกร์) เป็นที่นิยมอย่างมากในหมู่คอหวยไทย
หวยหุ้น: รวมหวยหุ้นจากทั่วโลก เช่น หุ้นไทย, นิเคอิ, ฮั่งเส็ง, และดาวโจนส์
หวยยี่กี: หวยที่ออกรางวัลทุกๆ 15-30 นาที เหมาะสำหรับคนที่ชอบลุ้นรางวัลตลอดทั้งวัน

ประเภทรางวัล	อัตราจ่ายโดยประมาณ (UFABET)	หมายเหตุ
3 ตัวบน (ตรง)	บาทละ 900 – 950	สูงกว่าหวยใต้ดินทั่วไป
3 ตัวโต๊ด	บาทละ 120 – 150	ลุ้นง่าย ได้เงินดี
2 ตัวบน / ล่าง	บาทละ 90 – 95	จ่ายหนัก มั่นใจได้
วิ่งบน / ล่าง	ตามเรทมาตรฐาน	ความเสี่ยงต่ำ

ข้อดีของการซื้อหวยผ่านระบบ UFABET

ความสะดวกสบาย: แทงผ่านสมาร์ทโฟนได้ทุกที่ทุกเวลา ไม่ต้องส่งโพยกระดาษให้ยุ่งยาก
ความปลอดภัยของข้อมูล: ข้อมูลการซื้อหวยของคุณจะถูกเก็บเป็นความลับสูงสุดด้วยระบบการเข้ารหัสที่ปลอดภัย
ประวัติการแทงชัดเจน: คุณสามารถตรวจสอบโพยย้อนหลังได้ทุกใบ มีหลักฐานการซื้อที่ชัดเจนในระบบ

FAQ: รวมคำถามที่พบบ่อยเกี่ยวกับ หวยออนไลน์

1. หวยออนไลน์ ของ UFABET ปิดรับแทงกี่โมง?

ตอบ: สำหรับหวยรัฐบาลไทย เราปิดรับแทงในวันหวยออกเวลา 15:20 น. ส่วนหวยประเภทอื่นๆ เช่น ฮานอย หรือลาว จะปิดรับก่อนเวลาผลออกประมาณ 15-30 นาทีครับ

2. หากถูกรางวัลเงินจะเข้าบัญชีเมื่อไหร่?

ตอบ: ระบบจะทำการปรับยอดเงินรางวัลให้ทันทีหลังจากที่ผลรางวัลอย่างเป็นทางการประกาศออกมา (โดยปกติไม่เกิน 5-10 นาที) คุณสามารถตรวจสอบยอดเงินได้ในหน้าประวัติการทำรายการ

3. มีขั้นต่ำในการแทงหวยหรือไม่?

ตอบ: เริ่มต้นเพียง 1 บาทเท่านั้นครับ เหมาะสำหรับนักเสี่ยงโชคทุกระดับทุน สามารถกระจายความเสี่ยงแทงได้หลายตัวเลขตามต้องการ

4. มีเลขอั้นเยอะไหม?

ตอบ: เราพยายามเปิดรับทุกตัวเลขให้มากที่สุดครับ หากมีเลขใดที่มีการแทงเข้ามาหนาแน่นจริงๆ ระบบอาจจะมีการปรับอัตราจ่ายลงเล็กน้อย (เลขจ่ายครึ่ง) ซึ่งจะมีการแจ้งให้ทราบล่วงหน้าในหน้าแทงหวยครับ หรือดูรายละเอียดได้ที่ส่วน FAQ ของเมนูหวย

บทสรุป: มั่นใจทุกตัวเลข เลือกแทง หวยออนไลน์ กับ UFABET

การเล่น หวยออนไลน์ จะไม่ใช่เรื่องที่น่ากังวลอีกต่อไปหากคุณเลือกใช้บริการกับ UFABET เว็บตรงที่มีรากฐานทางการเงินที่แข็งแกร่งและมีระบบการทำงานที่เป็นมืออาชีพ เราพร้อมมอบประสบการณ์การเสี่ยงโชคที่ดีที่สุด จ่ายหนัก จ่ายจริง และดูแลคุณตลอด 24 ชั่วโมง

เริ่มต้นเส้นทางเศรษฐีของคุณได้วันนี้ สมัครสมาชิกกับเราและเตรียมรับโชคจากตัวเลขที่คุณมั่นใจได้เลยครับ!

Puppet Blog: คาสิโนสด UFABET สัมผัสประสบการณ์เดิมพันระดับโลก ส่งตรงจากบ่อนจริง 24 ชม.

2026-03-17T04:17:20+00:00

ก้าวเข้าสู่มิติใหม่ของการเดิมพันออนไลน์กับ คาสิโนสด (Live Casino) ที่ UFABET เราได้ยกระดับมาตรฐานการเล่นเกม กาสิโน ให้มีความสมจริงเหมือนคุณได้เข้าไปนั่งอยู่ที่โต๊ะเดิมพันในคาสิโนระดับโลกจริงๆ ด้วยเทคโนโลยีการถ่ายทอดสดที่ทันสมัยที่สุด คุณจะได้พบกับดีลเลอร์สาวสวยมืออาชีพที่คอยให้บริการแจกไพ่และหมุนวงล้อแบบเรียลไทม์ มั่นใจได้ในความโปร่งใสและยุติธรรมในทุกตาการเดิมพัน

ทำไมต้องเล่น คาสิโนสด กับ UFABET? ความสมจริงที่เหนือระดับ

การเลือกใช้บริการ คาสิโนสด กับเรา มีข้อดีที่นักเดิมพันระดับมืออาชีพต่างไว้วางใจ:

ถ่ายทอดสดระบบ 4K: สัญญาณภาพคมชัดระดับ Full HD และ 4K ไม่มีการดีเลย์หรือกระตุก ให้คุณเห็นทุกรายละเอียดการแจกไพ่ชัดเจน 100%
รวมค่ายยักษ์ใหญ่: เราเป็นพันธมิตรกับค่ายชั้นนำระดับสากล เช่น SA Gaming, Sexy Baccarat, Evolution Gaming และ BG Casino เลือกเล่นได้ทุกค่ายในเว็บเดียว
เล่นได้ทุกที่ทุกเวลา: ระบบถูกออกแบบมาให้รองรับการเล่นผ่านมือถือได้อย่างลื่นไหล ไม่ว่าคุณจะอยู่ที่ไหนก็สามารถเข้าถึงโต๊ะเดิมพันระดับโลกได้ทันที

สมัครสมาชิก และ เข้าสู่ระบบ เลือกห้อง คาสิโนสด ที่คุณชื่นชอบ

คุณสามารถเริ่มต้นความตื่นเต้นได้ง่ายๆ เพียงไม่กี่ขั้นตอน:

สมัครสมาชิก: สมัครผ่านระบบอัตโนมัติที่หน้าเว็บไซต์ของเรา ใช้เวลาไม่ถึง 1 นาทีในการกรอกข้อมูลและรับ User
เข้าสู่ระบบ: เมื่อได้รับรหัสแล้ว ให้ทำการ เข้าสู่ระบบ และไปที่เมนู “คาสิโนสด” คุณจะพบกับรายชื่อค่ายเกมและห้องเดิมพันมากมาย ทั้งบาคาร่า, รูเล็ต, ไฮโล (ซิกโบ) และเกมโชว์สุดพิเศษ

มั่นใจทุกธุรกรรม: ฝากเงิน และ ถอนเงิน อัตโนมัติ รวดเร็วภายใน 10 วินาที

ความมั่นคงทางการเงินคือหัวใจหลักของ UFABET เพื่อให้การเล่น คาสิโนสด ของคุณราบรื่นที่สุด:

ฝากเงิน ทันใจ: ระบบ AI อัจฉริยะช่วยให้ยอดเงินของคุณถูกเติมเข้าเครดิตภายใน 10-20 วินาทีหลังจากทำรายการ ไม่ต้องส่งสลิปให้แอดมินตรวจสอบ
ถอนเงิน ชัวร์ 100%: เมื่อคุณได้กำไรจากการเดิมพัน สามารถกด ถอนเงิน ได้ทันทีโดยไม่มีขั้นต่ำ ระบบจะโอนเงินเข้าบัญชีธนาคารที่คุณลงทะเบียนไว้อย่างรวดเร็วและแม่นยำ

โปรโมชั่น สุดคุ้มสำหรับคอ คาสิโนสด และ กาสิโน ออนไลน์

เรามอบความคุ้มค่าให้สมาชิกอย่างต่อเนื่องด้วยข้อเสนอพิเศษ:

โปรโมชั่น ต้อนรับสมาชิกใหม่: รับเครดิตโบนัสเพิ่มทันทีเมื่อทำการฝากเงินครั้งแรกหลัง สมัครสมาชิก
คอมมิชชั่นคืนยอดเสีย: สำหรับสาย คาสิโนสด เรามีระบบคืนค่าคอมมิชชั่นและคืนเงินยอดเสียรายวัน เพื่อให้คุณมีทุนกลับมาแก้มือและสร้างกำไรได้ใหม่ในวันถัดไป

ประเภทเกมในคาสิโนสด	ค่ายแนะนำ	จุดเด่น
บาคาร่าสด	Sexy Baccarat	ดีลเลอร์สาวสวยในชุดบิกินี่ พร้อมเพลงสนุกๆ
รูเล็ตออนไลน์	Evolution Gaming	มีระบบ Multi-Camera เห็นลูกเหล็กชัดทุกมุม
ซิกโบ (ไฮโล)	SA Gaming	ระบบเขย่าลูกเต๋าที่โปร่งใส ตรวจสอบง่าย
เกมโชว์ (Game Shows)	Evolution Gaming	ประสบการณ์ใหม่ของการเสี่ยงโชคที่สนุกและตื่นเต้น

FAQ: รวมคำถามที่พบบ่อยเกี่ยวกับ คาสิโนสด UFABET

1. เล่น คาสิโนสด มีโอกาสโดนโกงไหม?

ตอบ: ไม่มีแน่นอนครับ UFABET เป็นเว็บตรงมาตรฐานสากล ทุกเกมในคาสิโนสดเป็นการถ่ายทอดสดแบบ Real-time มีนาฬิกาบอกเวลาสดในหน้าจอ ท่านสามารถตรวจสอบได้ทุกขั้นตอนครับ

2. ขั้นต่ำในการวางเดิมพัน คาสิโนสด คือเท่าไหร่?

ตอบ: เริ่มต้นเพียง 10 บาทเท่านั้นครับ (ขึ้นอยู่กับแต่ละค่ายและแต่ละโต๊ะ) เหมาะสำหรับทั้งผู้เล่นมือใหม่และระดับวีไอพี

3. หากเน็ตหลุดขณะวางเดิมพันต้องทำอย่างไร?

ตอบ: ระบบจะยึดตามผลการออกรางวัลจริงในรอบนั้นๆ หากท่านวางเดิมพันสำเร็จแล้วและผลชนะ ระบบจะเติมเงินเข้าบัญชีให้ท่านโดยอัตโนมัติเมื่อท่าน เข้าสู่ระบบ อีกครั้งครับ หรือศึกษาเพิ่มเติมได้ที่เมนู FAQ

บทสรุป: ยกระดับการเดิมพันของคุณไปกับ คาสิโนสด UFABET วันนี้

หากคุณกำลังมองหาความสนุกที่เหนือระดับและความมั่นคงทางการเงินสูงสุด คาสิโนสด บนเว็บไซต์ UFABET คือทางเลือกที่ดีที่สุดของคุณ ด้วยระบบที่ลื่นไหล ภาพสวยคมชัด และการบริการที่เป็นเลิศ

อย่ารอช้า! สมัครสมาชิก และ เข้าสู่ระบบ เพื่อสัมผัสบรรยากาศคาสิโนระดับพรีเมียมได้จากที่บ้านคุณ พร้อมรับ โปรโมชั่น สุดพิเศษที่เราเตรียมไว้ให้คุณวันนี้ครับ!

Puppet Blog: ซิกโบ UFABET เกมไฮโลออนไลน์ยอดนิยม อัตราจ่ายสูง เล่นสด 24 ชม.

2026-03-17T04:15:45+00:00

หากคุณเป็นแฟนพันธุ์แท้ของเกมลูกเต๋า ซิกโบ (Sic Bo) หรือที่รู้จักกันดีในชื่อ “ไฮโล” คือเกมที่คุณไม่ควรพลาดที่ UFABET เรายกระดับการเล่นไฮโลแบบเดิมๆ ให้กลายเป็นประสบการณ์ กาสิโน ระดับสากล ด้วยระบบการถ่ายทอดสดที่คมชัด โปร่งใส และมีรูปแบบการวางเดิมพันที่หลากหลาย พร้อมอัตราการจ่ายเงินรางวัลที่สูงกว่าที่ไหนๆ ทำให้คุณสามารถลุ้นเงินแสนได้ในเพียงชั่วพริบตา

ทำไมต้องเล่น ซิกโบ กับ UFABET? สนุกปลอดภัยกว่าที่อื่น

การเลือกเล่น ซิกโบ กับเว็บตรงอย่าง ยูฟ่าเบท ช่วยให้คุณมั่นใจในทุกการเดิมพัน:

ความโปร่งใสสูงสุด: เราใช้ระบบถ่ายทอดสด (Live Streaming) ส่งตรงจากคาสิโนจริง เห็นการเขย่าลูกเต๋าในโหลแก้วใสชัดเจนทุกมุมกล้อง ป้องกันการโกง 100%
อัตราจ่ายที่คุ้มค่า: นอกจากแทง สูง-ต่ำ หรือ เต็ง-โต๊ด แล้ว การแทง “ตองเลข” ในระบบของเรามีอัตราจ่ายสูงสุดถึง 150 เท่า!
อินเตอร์เฟซใช้งานง่าย: หน้ากระดานเดิมพันถูกออกแบบมาให้ดูง่าย รองรับทั้งภาษาไทยและสถิติย้อนหลังเพื่อช่วยในการวิเคราะห์

ขั้นตอนการ สมัครสมาชิก และ เข้าสู่ระบบ เพื่อร่วมสนุกกับ ซิกโบ

เริ่มต้นความตื่นเต้นกับเกมลูกเต๋าได้ง่ายๆ ดังนี้:

สมัครสมาชิก: ทำรายการผ่านระบบออโต้เพียงไม่กี่วินาที กรอกข้อมูลเบื้องต้นและบัญชีธนาคารเพื่อเปิด User ใหม่
เข้าสู่ระบบ: ล็อกอินเข้าใช้งานผ่านหน้าเว็บหรือแอปพลิเคชัน จากนั้นไปที่เมนู กาสิโน สด และเลือกค่ายเกมที่คุณชื่นชอบเพื่อเข้าสู่โต๊ะ ซิกโบ ได้ทันที

ระบบ ฝากเงิน และ ถอนเงิน อัตโนมัติ: รวดเร็วทันใจสำหรับคอไฮโล

เพราะจังหวะการเดิมพันเป็นเรื่องสำคัญ ระบบการเงินของ UFABET จึงทำงานด้วยความรวดเร็ว:

ฝากเงิน ทันใจ: เติมเครดิตผ่านระบบ AI ยอดปรับเข้าทันทีภายใน 10-20 วินาที ไม่ต้องส่งสลิปแอดมินให้เสียเวลา
ถอนเงิน ชัวร์: เมื่อคุณชนะรางวัลใหญ่จากการแทง ซิกโบ สามารถกด ถอนเงิน ได้ทันที ระบบจะดำเนินการโอนเงินเข้าบัญชีคุณอย่างรวดเร็วและครบถ้วนทุกบาท

โปรโมชั่น สุดพิเศษและสิทธิประโยชน์สำหรับสมาชิก UFABET

เรามอบความคุ้มค่าให้สมาชิกมากกว่าใครด้วยสิทธิพิเศษมากมาย:

โปรโมชั่น ต้อนรับสมาชิกใหม่: รับโบนัสเครดิตเพิ่มทันทีเมื่อทำการฝากเงินครั้งแรกหลัง สมัครสมาชิก
คืนค่าคอมมิชชั่น: ทุกยอดการเล่นในเกม ซิกโบ ท่านจะได้รับค่าคอมมิชชั่นคืนสูงสุด 0.7% เพื่อใช้เป็นทุนในการทำกำไรต่อไป
กิจกรรมพิเศษ: ลุ้นรับรางวัลใหญ่จากกิจกรรมแจกโบนัสรายสัปดาห์สำหรับสมาชิกที่มียอดเล่นสม่ำเสมอ

รูปแบบการแทงซิกโบ	อัตราการจ่ายเงิน	ความน่าสนใจ
สูง – ต่ำ	1 : 1	โอกาสชนะสูงถึง 50/50
แทงเลขเดี่ยว	1 : 1 (ถึง 3 เท่า)	ลุ้นง่ายๆ จากลูกเต๋าแต่ละลูก
แทงรวมแต้ม (9-12)	1 : 6	ผลตอบแทนคุ้มค่า
แทงตอง (ระบุเลข)	1 : 150	รางวัลใหญ่ที่สุดในเกม

FAQ: รวมคำถามที่พบบ่อยเกี่ยวกับเกม ซิกโบ ออนไลน์

1. เกม ซิกโบ กับ ไฮโลไทย แตกต่างกันอย่างไร?

ตอบ: กติกาพื้นฐานเหมือนกันครับ แต่ ซิกโบ ในระบบออนไลน์จะมีรูปแบบการวางเดิมพันที่ละเอียดกว่าและอัตราจ่ายที่สูงกว่าไฮโลพื้นบ้านทั่วไปมาก

2. สามารถเล่น ซิกโบ ผ่านมือถือได้หรือไม่?

ตอบ: ได้แน่นอนครับ ระบบของเรารองรับการเล่นผ่านมือถือทุกรุ่น ทั้ง iOS และ Android ภาพสวยลื่นไหลไม่แพ้ในคอมพิวเตอร์

3. ขั้นต่ำในการวางเดิมพัน ซิกโบ คือเท่าไหร่?

ตอบ: เริ่มต้นเพียง 10-20 บาทต่อตานะครับ (ขึ้นอยู่กับค่ายเกมที่เลือก) รายละเอียดเพิ่มเติมสามารถดูได้ที่เมนู FAQ ของระบบครับ

บทสรุป: มั่นใจทุกการเดิมพัน ซิกโบ ไปกับ UFABET เว็บตรงอันดับ 1

หากคุณต้องการความตื่นเต้นและผลตอบแทนที่รวดเร็ว เกม ซิกโบ บน UFABET คือคำตอบที่ดีที่สุด ด้วยมาตรฐานเว็บตรงที่มั่นคง โปร่งใส และระบบ ฝากเงิน-ถอนเงิน ที่รวดเร็วที่สุดในปี 2026

อย่ารอช้า! สมัครสมาชิก และ เข้าสู่ระบบ วันนี้ เพื่อรับ โปรโมชั่น สุดพิเศษและเริ่มต้นทำกำไรกับเกมลูกเต๋าระดับโลกไปพร้อมกับเราครับ!

Puppet Blog: ยิงปลา UFABET เกมยอดฮิตเล่นง่าย กราฟิกสวย ปลาตายไว ได้เงินจริง

2026-03-17T04:15:27+00:00

หากคุณกำลังมองหาเกมที่เปลี่ยนความแม่นยำให้กลายเป็นผลกำไร เกม ยิงปลา คือตัวเลือกอันดับ 1 ที่ UFABET เราภูมิใจนำเสนอ ด้วยรูปแบบเกมที่เล่นง่ายไม่ซับซ้อน กราฟิกสีสันสดใสระดับ HD และเอฟเฟกต์สุดตระการตา ทำให้เกมนี้ครองใจผู้เล่นทุกเพศทุกวัย ที่สำคัญคือระบบของเราปรับเปลี่ยนให้ “ปลาตายง่าย” และ “บอสแตกบ่อย” เพื่อให้สมาชิกได้รับผลตอบแทนที่คุ้มค่าที่สุด

ทำไมต้องเล่นเกม ยิงปลา กับ UFABET? สนุกกว่าที่เคยสัมผัส

การเลือกเล่นเกมยิงปลาในหมวด กาสิโน ของเรา มีจุดเด่นที่ทำให้เราแตกต่างจากเว็บอื่น:

รวมค่ายเกมชั้นนำ: เราคัดสรรค่ายเกมยิงปลาที่ดีที่สุด เช่น Joker Gaming, JILI และ Spadegaming มาไว้ในที่เดียว
ราคากระสุนยืดหยุ่น: เริ่มต้นราคากระสุนเพียงไม่กี่สตางค์ ไปจนถึงการใช้กระสุนพลังทำลายล้างสูงเพื่อล่าบอสรางวัลใหญ่
โบนัสพิเศษในเกม: มีไอเทมเสริมมากมาย เช่น ปืนเลเซอร์, ระเบิดแช่แข็งปลา หรือปืนสายฟ้า เพื่อช่วยให้คุณล่าแต้มได้ง่ายขึ้น

สมัครสมาชิก และ เข้าสู่ระบบ เริ่มต้นล่ารางวัลใต้ท้องทะเล

คุณสามารถเข้าสู่โลกใต้ทะเลเพื่อล่าสมบัติได้ในไม่กี่วินาที:

สมัครสมาชิก: สมัครง่ายผ่านระบบออโต้ เพียงกรอกเบอร์โทรศัพท์และบัญชีธนาคารเพื่อรับรหัสผ่าน
เข้าสู่ระบบ: ล็อกอินผ่านหน้าเว็บหรือแอปพลิเคชัน จากนั้นเลือกเมนูเกม ยิงปลา คุณจะพบกับห้องเดิมพันหลายระดับ ตั้งแต่ห้องสำหรับมือใหม่ไปจนถึงห้องระดับเซียน (High Roller)

ระบบ ฝากเงิน และ ถอนเงิน อัตโนมัติ: เติมกระสุนไว ไม่ขัดจังหวะการยิง

จังหวะที่ปลาบอสกำลังจะตายคือนาทีทอง ระบบการเงินของเราจึงถูกออกแบบมาให้เร็วที่สุด:

ฝากเงิน ทันใจ: เครดิตปรับยอดภายใน 10-20 วินาทีผ่านระบบ AI ไม่ต้องส่งสลิปให้แอดมิน เพื่อให้คุณเติมกระสุนได้ต่อเนื่อง
ถอนเงิน ชัวร์ 100%: เมื่อเก็บแต้มจากปลาตัวใหญ่ได้จนพอใจ สามารถกด ถอนเงิน ได้ทันที ระบบจะโอนกำไรเข้าบัญชีท่านอย่างแม่นยำและปลอดภัย

โปรโมชั่น สุดพิเศษและเกม กาสิโน อื่นๆ ในระบบ UFABET

เรามอบความคุ้มค่าให้สมาชิกสายยิงปลามากกว่าใคร:

โปรโมชั่น ต้อนรับสมาชิกใหม่: รับเครดิตเพิ่มสำหรับการเติมเงินครั้งแรกเพื่อใช้เป็นทุนกระสุน
คืนเงินยอดเสีย: เล่นไม่เข้าไม่ต้องกังวล เรามีระบบคืนเงินยอดเสียรายวันเพื่อเป็นทุนให้คุณกลับมาแก้ตัว
ความหลากหลาย: นอกจากเกมยิงปลา ท่านยังสามารถใช้กระเป๋าเครดิตเดียวกันสลับไปเล่น กาสิโน สด หรือสล็อตได้ทันทีโดยไม่ต้องโยกเงิน

ประเภทปลาในเกม	ความยากในการยิง	อัตราตัวคูณรางวัล
ปลาขนาดเล็ก	ง่ายมาก	x2 – x10
ปลาขนาดกลาง	ปานกลาง	x20 – x50
ปลาบอส / มังกร	ยาก (แต่คุ้ม)	x100 – x500+

FAQ: รวมคำถามที่พบบ่อยเกี่ยวกับเกม ยิงปลา

1. เกมยิงปลาใช้เงินขั้นต่ำเท่าไหร่?

ตอบ: เริ่มต้นขั้นต่ำเพียงนัดละ 0.1 บาทเท่านั้นครับ (ขึ้นอยู่กับแต่ละเกม) ทำให้ผู้เล่นทุนน้อยก็สามารถร่วมสนุกได้

2. มีเทคนิคยิงปลายังไงให้ได้เงินจริง?

ตอบ: แนะนำให้เลือกยิงปลาที่ว่ายออกมาจากขอบจอ และไม่ควรยิงค้างใส่ปลาที่กำลังจะหลุดจากจอครับ ท่านสามารถศึกษาเทคนิคเพิ่มเติมได้ในหน้า FAQ ของเรา

3. เล่นผ่านมือถือภาพจะกระตุกไหม?

ตอบ: ระบบของเราเสถียรมากครับ รองรับการเล่นผ่านมือถือทุกรุ่นอย่างลื่นไหล เพียงแค่มีอินเทอร์เน็ตที่เสถียรท่านก็สนุกได้ทุกที่

บทสรุป: สัมผัสประสบการณ์ล่าสมบัติใต้ทะเลกับ ยิงปลา UFABET วันนี้

เปลี่ยนเวลาว่างให้กลายเป็นกำไรไปกับเกม ยิงปลา ที่ดีที่สุดบน UFABET เว็บตรงที่มีความมั่นคงทางการเงินและระบบที่ทันสมัยที่สุด

อย่ารอช้า! สมัครสมาชิก และ เข้าสู่ระบบ วันนี้ เพื่อรับ โปรโมชั่น สุดพิเศษและเริ่มต้นผจญภัยใต้ท้องทะเลไปพร้อมกับเราครับ!

Puppet Blog: เกมไพ่ UFABET รวมทุกเกมยอดฮิต บาคาร่า เสือมังกร เล่นสด 24 ชม.

2026-03-17T04:15:02+00:00

สำหรับนักเดิมพันที่หลงใหลในความคลาสสิกและตื่นเต้น เกมไพ่ คือหมวดหมู่ที่ได้รับความนิยมสูงสุดตลอดกาลที่ UFABET เราได้รวบรวมสุดยอดเกมไพ่จากทั่วทุกมุมโลกมาไว้ในรูปแบบคาสิโนสด (Live Casino) ที่ส่งตรงจากสตูดิโอระดับโลก มั่นใจได้ในความโปร่งใส ทุกการแจกไพ่สามารถตรวจสอบได้แบบเรียลไทม์ พร้อมดีลเลอร์สาวสวยที่คอยให้บริการท่านตลอดวัน

ทำไมต้องเล่น เกมไพ่ กับ UFABET? สัมผัสประสบการณ์ระดับพรีเมียม

การเข้าเล่น เกมไพ่ ในหมวด กาสิโน ของเรามีความโดดเด่นที่เหนือกว่าใคร:

ความหลากหลายของค่ายดัง: เราคัดสรรค่ายยักษ์ใหญ่เช่น SA Gaming, Sexy Baccarat และ Evolution Gaming มาให้ท่านเลือกเล่นในบัญชีเดียว
ถ่ายทอดสดแบบ Full HD: ระบบสตรีมมิ่งที่เสถียรที่สุดในไทย ช่วยให้ท่านเห็นทุกรายละเอียดการแจกไพ่ ไม่มีภาพค้างหรือดีเลย์ให้เสียจังหวะ
เดิมพันขั้นต่ำเพียง 10 บาท: ไม่ว่าท่านจะมีทุนมากหรือน้อย ก็สามารถร่วมสนุกและทำกำไรจากเกมไพ่ยอดนิยมได้ทันที

ขั้นตอนการ สมัครสมาชิก และ เข้าสู่ระบบ เพื่อเข้าสู่โลกของ เกมไพ่

เริ่มต้นทำกำไรได้ง่ายๆ เพียงไม่กี่ขั้นตอน:

สมัครสมาชิก: สมัครง่ายผ่านระบบออโต้หน้าเว็บไซต์ เพียงกรอกข้อมูลพื้นฐานและบัญชีธนาคารเพื่อรับรหัสเข้าใช้งาน
เข้าสู่ระบบ: หลังจากได้รับ User แล้ว สามารถทำการ เข้าสู่ระบบ ได้ทันทีผ่านมือถือหรือคอมพิวเตอร์ จากนั้นเลือกหมวดหมู่ “คาสิโนสด” เพื่อพบกับอาณาจักร เกมไพ่ ที่ท่านชื่นชอบ

ระบบธุรกรรมเพื่อคอ เกมไพ่: ฝากเงิน และ ถอนเงิน รวดเร็วทันใจ

ความรวดเร็วทางการเงินคือสิ่งที่ UFABET ให้ความสำคัญที่สุด เพื่อให้การเดิมพันของท่านลื่นไหล:

ฝากเงิน อัตโนมัติ: เติมเครดิตได้ทันทีผ่านระบบ AI รองรับทุกธนาคารและวอลเล็ต ยอดปรับไวภายใน 10-20 วินาที ไม่ต้องแจ้งสลิป
ถอนเงิน ทันที: เมื่อสะสมกำไรจาก เกมไพ่ ได้ตามต้องการ ท่านสามารถทำรายการ ถอนเงิน ได้ด้วยตัวเอง ระบบจะโอนเงินเข้าบัญชีท่านโดยตรงอย่างรวดเร็วและปลอดภัย

โปรโมชั่น สุดพิเศษสำหรับสมาชิกใหม่และเซียน เกมไพ่

เรามี โปรโมชั่น ที่ออกแบบมาเพื่อเพิ่มโอกาสชนะให้สมาชิกโดยเฉพาะ:

โบนัสต้อนรับสมาชิกใหม่: รับเครดิตเพิ่มทันทีจากการฝากครั้งแรกหลัง สมัครสมาชิก
ค่าคอมมิชชั่นคืนยอดเสีย: ทุกยอดการเล่นในหมวดไพ่ เรามีระบบคืนเงินคอมมิชชั่นให้สูงสุด 0.7% เพื่อให้ท่านมีทุนไว้ทำกำไรต่อในรอบถัดไป

ประเภทเกมไพ่ยอดนิยม	จุดเด่นของเกม	อัตราการจ่าย (สูงสุด)
บาคาร่า (Baccarat)	กติกาเข้าใจง่าย จบเกมไว	1 : 11 (สำหรับแต้มคู่)
เสือมังกร (Dragon Tiger)	วัดดวงด้วยไพ่ใบเดียว	1 : 8 (สำหรับเสมอ)
ป๊อกเด้งออนไลน์	เกมคลาสสิกที่คนไทยคุ้นเคย	1 : 5 (สำหรับห้าเด้ง)

FAQ คำถามที่พบบ่อยเกี่ยวกับ เกมไพ่ ในระบบ UFABET

1. เกมไพ่ในคาสิโนสดมีการล็อคผลหรือไม่?

ตอบ: ไม่มีการล็อคผลแน่นอนครับ ระบบของเราเป็นการถ่ายทอดสดแบบ Real-time 100% มีนาฬิกาบอกเวลาสดและท่านสามารถตรวจสอบความโปร่งใสได้ทุกรอบการเดิมพัน

2. สามารถเล่น เกมไพ่ ผ่านมือถือได้ไหม?

ตอบ: ได้แน่นอนครับ ระบบของเราออกแบบมาให้รองรับการใช้งานบนสมาร์ทโฟนทุกรุ่นทั้ง iOS และ Android อย่างสมบูรณ์แบบ

3. หากมีปัญหาในการวางเดิมพัน ต้องติดต่อใคร?

ตอบ: ท่านสามารถตรวจสอบแนวทางเบื้องต้นได้ที่หน้า FAQ หรือติดต่อทีมงานซัพพอร์ตผ่านช่องทางที่ระบุไว้ได้ตลอด 24 ชั่วโมงครับ

บทสรุป: มั่นใจทุกการเดิมพัน เกมไพ่ ไปกับ UFABET เว็บตรง

ก้าวเข้าสู่ประสบการณ์การเดิมพันระดับสากลไปกับ เกมไพ่ ที่ดีที่สุดบน UFABET เว็บตรงที่ไม่ผ่านเอเย่นต์ มั่นใจได้ในเรื่องความปลอดภัยและการเงินที่มั่งคั่ง

อย่ารอช้า! สมัครสมาชิก และ เข้าสู่ระบบ วันนี้ เพื่อรับ โปรโมชั่น สุดพิเศษและเริ่มต้นทำกำไรกับเกมไพ่ที่ท่านถนัดไปพร้อมกับเราครับ!

Puppet Blog: สล็อต UFABET รวมทุกค่ายเกมดัง แตกง่าย จ่ายจริง ระบบออโต้ที่ดีที่สุด

2026-03-17T04:14:42+00:00

หากคุณกำลังมองหาแหล่งรวมเกม สล็อต ที่มีความหลากหลายและมีอัตราการจ่ายรางวัลสูงที่สุดในเอเชีย UFABET คือคำตอบสุดท้าย เราได้รวบรวมค่ายเกมสล็อตชั้นนำระดับโลกมาไว้ในที่เดียว เพื่อให้สมาชิกได้สัมผัสประสบการณ์การปั่นสล็อตที่สนุกสนาน กราฟิกตระการตา และที่สำคัญคือ “โบนัสแตกง่าย” พร้อมระบบการจัดการที่รวดเร็วทันใจในทุกขั้นตอน

ทำไมต้องเล่น สล็อต กับ UFABET? ประสบการณ์ปั่นสล็อตที่เหนือระดับ

การเลือกเล่นเกมสล็อตกับเว็บตรงอย่าง ยูฟ่าเบท มีข้อดีที่ทำให้นักเดิมพันมืออาชีพไว้วางใจ:

รวมค่ายดังระดับโลก: ไม่ว่าจะเป็น PG Soft, Joker Gaming, Pragmatic Play หรือ Spadegaming เรามีให้เลือกเล่นกว่า 1,000 เกม
มาตรฐานสากล: เกมทุกเกมได้รับใบเซอร์รับรองมาตรฐาน (RNG) มั่นใจได้ว่าไม่มีการปรับอัตราแพ้ชนะ ทุกการปั่นมีความยุติธรรม 100%
แจ็กพอตก้อนโต: ด้วยฐานผู้เล่นจำนวนมาก ทำให้ยอดสะสมของเงินรางวัลแจ็กพอตพุ่งสูงขึ้นอย่างรวดเร็ว พร้อมแจกโบนัสใหญ่ให้สมาชิกทุกวัน

สมัครสมาชิก และ เข้าสู่ระบบ เริ่มต้นปั่น สล็อต ได้ภายใน 1 นาที

เราให้ความสำคัญกับความสะดวกของสมาชิกเป็นอันดับหนึ่ง:

สมัครสมาชิก: คุณสามารถสมัครผ่านระบบออโต้ได้ด้วยตัวเอง เพียงกรอกเบอร์โทรศัพท์และบัญชีธนาคาร ไม่ต้องรอแอดมินอนุมัติ
เข้าสู่ระบบ: ล็อกอินเข้าเล่นผ่านหน้าเว็บหรือแอปพลิเคชันได้ทันที ระบบมีความเสถียรสูง รองรับการเล่นบนมือถือทุกรุ่น ทั้ง iOS และ Android

ระบบธุรกรรมที่ตอบโจทย์สายปั่น: ฝากเงิน และ ถอนเงิน ไม่มีขั้นต่ำ

เพื่อไม่ให้การล่าโบนัสไทม์ (Bonus Time) ต้องสะดุด ระบบการเงินของเราจึงทำงานด้วยความไวแสง:

ฝากเงิน รวดเร็ว: เติมเครดิตได้ทันทีผ่าน Mobile Banking และ True Wallet เครดิตปรับยอดภายใน 10 วินาที
ถอนเงิน ชัวร์ 100%: เมื่อสล็อตแตกหนัก แจ็กพอตลง คุณสามารถกด ถอนเงิน ได้ทันทีโดยไม่จำกัดยอดถอนสูงสุดต่อวัน มั่นใจได้ว่าเว็บตรงจ่ายจริงทุกบิล

โปรโมชั่น สุดคุ้มสำหรับแฟนพันธุ์แท้ สล็อต และ กาสิโน

เราจัดเตรียมความคุ้มค่าไว้ซัพพอร์ตนักเดิมพันในทุกๆ วัน:

โปรโมชั่น สล็อต: รับโบนัสฟรีสปิน หรือเครดิตเพิ่มสำหรับการฝากเงินครั้งแรกของวัน
คืนเงินยอดเสีย: ทุกยอดที่ปั่นสล็อตไม่เข้า เรามีระบบคืนเงินยอดเสียให้ทุกวัน เพื่อให้คุณมีทุนกลับมาแก้ตัวได้ใหม่
ครบวงจร: นอกจากสล็อตแล้ว คุณยังสามารถใช้กระเป๋าเครดิตเดียวกันสลับไปเล่น กาสิโน สด บาคาร่า หรือแทงบอลได้ทันทีโดยไม่ต้องโยกเงิน

ฟีเจอร์ของเกม	จุดเด่นของ UFABET	ผลประโยชน์ที่จะได้รับ
อัตราการแตก (RTP)	สูงกว่า 96% ในทุกเกม	มีโอกาสชนะรางวัลใหญ่บ่อยขึ้น
ระบบการเงิน	ออโต้ (AI Transaction)	ฝากเงิน – ถอนเงิน ไว ไม่รอนาน
บริการเสริม	สลับไปเล่น กาสิโน ได้	ความหลากหลายในการเดิมพัน

FAQ: รวมคำถามที่พบบ่อยเกี่ยวกับ สล็อต UFABET

1. เกมสล็อตค่ายไหนแตกง่ายที่สุดในตอนนี้?

ตอบ: ค่าย PG Soft และ Pragmatic Play เป็นค่ายที่ได้รับความนิยมสูงมากในหน้าเว็บเรา เนื่องจากมีฟรีเจอร์ซื้อฟรีสปินและตัวคูณที่ดุดัน

2. เริ่มต้นเดิมพัน สล็อต ขั้นต่ำกี่บาท?

ตอบ: สมาชิกสามารถเริ่มต้นเบท (Bet) ได้ตั้งแต่ 1 บาทขึ้นไป เหมาะสำหรับผู้เล่นทุกระดับทุนครับ

3. หากเกิดปัญหาขณะกำลังเล่นแจ็กพอตแตก ต้องทำอย่างไร?

ตอบ: ระบบของเรามีการบันทึกข้อมูลแบบ Real-time หากเกิดปัญหาอินเทอร์เน็ตขัดข้อง ยอดเงินรางวัลจะถูกเติมเข้าบัญชีให้ท่านโดยอัตโนมัติ หรือติดต่อแอดมินได้ 24 ชม.

บทสรุป: สัมผัสความสนุกและลุ้นโบนัสก้อนโตกับ สล็อต UFABET วันนี้

ก้าวเข้าสู่โลกแห่งความบันเทิงที่ไม่มีวันหลับใหลไปกับเกม สล็อต ที่ดีที่สุดบน UFABET เว็บตรงที่มีความมั่นคงทางการเงินและระบบที่ทันสมัยที่สุดในไทยอย่ารอช้า! สมัครสมาชิก และ เข้าสู่ระบบ เพื่อคว้าโอกาสเป็นเศรษฐีคนใหม่จากการปั่นสล็อตกับเราวันนี้ พร้อมรับ โปรโมชั่น สุดพิเศษที่รอคุณอยู่เพียบ!

Example 42: Silent is not idle

2026-03-14T00:00:00+00:00

Pabawi is Growing Fast: from v0.4 to v0.8 in Two Months Two months ago I wrote about Pabawi, a web frontend for classic infrastructures. At the time, v0.4.0 had just shipped with Bolt, PuppetDB, PuppetServer and Hiera integrations. It was a working prototype — useful, but rough around the edges. Today, four releases later, Pabawi is a different animal. This post is a catch-up: what changed, where we’re going, and why I think this project matters more than ever. What happened in two months Development moved fast. Here’s what each release brought: v0.5.0 — Deeper Puppet visibility Report filtering, Puppet run history visualization with timeline view, and an enhanced expert mode with frontend logging. If you use PuppetDB seriously, this version made Pabawi genuinely useful for day-to-day operations. v0.6.0 — Foundations Mostly internal: code consolidation, architecture cleanup, bug fixing. Not glamorous, but necessary. A project that grows this fast needs these stabilization moments. v0.7.0 — Ansible joins the party This was a big one. Ansible integration landed, meaning Pabawi is no longer a “Puppet tool” — it’s a multi-tool. If you run a mixed environment (and most people do), you can now see and act on Ansible-managed nodes from the same interface. Also: class-aware Hiera lookups, which makes the Hiera Data Browser significantly more useful. v0.8.0 — RBAC and SSH Role-based access control. Multiple users, controlled access, audit trail. This is what takes Pabawi from “personal tool on localhost” to something you can actually deploy for a team. SSH integration also landed, adding direct SSH-based node management and expanding the inventory sources available. The bigger picture When I started Pabawi, the goal was simple: I wanted a modern OSS web UI for Puppet and Bolt. The classic infrastructure space — physical servers, VMs, decades of accumulated systems — is enormous, but it’s been left behind by tooling. Everyone builds for Kubernetes. Everyone builds for cloud-native. But the people managing 200 bare-metal servers running CentOS 7 with Puppet? They get a CLI and a prayer. Pabawi is trying to fix that. Not by replacing Puppet or Ansible or Bolt — those tools are excellent at what they do. But by giving you a single, modern web interface to work with all of them together. The vision: one pane of glass for classic infrastructure. What’s coming Proxmox integration is in active development. If you manage VMs on Proxmox — and a lot of people do — this will let you see and interact with your virtualization layer alongside your configuration management data. After that, the roadmap extends further: Icinga / CheckMK — bring monitoring context into the same interface Terraform — infrastructure provisioning alongside configuration management EC2 / Azure — for hybrid environments that span on-prem and cloud Choria, scheduled executions, custom dashboards The pattern is consistent: wherever you have servers you care about, Pabawi should be able to see them and help you act on them. Try it Getting started is straightforward. Clone the repo and run the setup script: git clone https://github.com/example42/pabawi cd pabawi ./scripts/setup.sh Or use Docker: docker run -d \ --name pabawi \ -p 127.0.0.1:3000:3000 \ -v "$(pwd)/pabawi:/pabawi" \ --env-file ".env" \ example42/pabawi:latest Full docs at github.com/example42/pabawi. Give it a try — and tell me what you think If Pabawi looks useful for your infrastructure, the best thing you can do right now is try it and tell me what’s missing. Clone it, run ./scripts/setup.sh, and connect it to your existing Puppet, Bolt or Ansible setup. It should take less than 30 minutes to have something running. If it doesn’t, that’s already useful feedback. 👉 github.com/example42/pabawi If you find it useful, a GitHub star goes a long way for an open source project. If you find something broken or missing, open an issue — the roadmap is driven by real users. Want help setting it up? I’m still offering a free shared-screen setup session — 30 minutes, no strings attached. We get it running in your environment, connected to your tools. Reach out on LinkedIn to schedule a call. On behalf of Alessandro Franceschi

Example 42: Announcing Pabawi, a web frontend for classic infrastructures

2026-01-16T00:00:00+00:00

Is there still space in AI and Cloud native days for a new tool to manage classic infrastructures based on physical or virtual servers? If you handle good old servers, and use Puppet, Bolt or Ansible to configure and manage them, then the answer might be yes, and we may have a nice tool for you. Pabawi is a new, modern, sleek web frontend to inventory your systems, check their configuration management status, and run actions on them. Needless to sat that it’s also Open Source. Version 0.4.0, just released after a few weeks of AI based coding, has integrations with Bolt, Hiera, PuppetDB and PuppetServer. Current version is expected to be executed by a Puppet developer or user on her/his localhost, featuring: Multi-Source Inventory: View and manage nodes from Bolt inventory and PuppetDB Command Execution: Run ad-hoc commands on remote nodes with whitelist security Task Execution: Execute Bolt tasks with automatic parameter support Puppet Integration: Trigger Puppet agent runs with full configuration control Package Management: Install and manage packages across your infrastructure Execution History: Track all operations with detailed results and re-execution capability Dynamic Inventory: Automatically discover nodes from PuppetDB Node Facts: View comprehensive system information from Puppet agents Puppet Reports: Browse detailed Puppet run reports with metrics and resource changes Catalog Inspection: Examine compiled Puppet catalogs and resource relationships Event Tracking: Monitor individual resource changes and failures over time PQL Queries: Filter nodes using PuppetDB Query Language Hiera Data Browser: Explore hierarchical configuration data and key usage analysis Puppet code analysis: Analyses Puppet code base, reporting class usage, lint issues, outdated modules in Puppetfile More robust users management and RBAC, and Ansible and other tools integrations are planned for future versions. Check the git repository for installation instructions and details. Screenshots Here are some screenshots, from a test setup with few nodes. The interface adapts well and is still fast on way larger setups (currently tested with infrastructures up to 350 nodes). Nodes Inventory Node inventory with multi-source support, blazing fast search and filtering options Task Execution Bolt task execution interface with automatic parameters discovery Executions Tracking Execution history with filtering and detailed execution results with re-run capabilities Node Details Node detail page with access to facts, reports, events, managed resources and other useful info Puppet reports Puppet reports view, with run times and number of affected resources Free installation service (time limited) Pabawi is easy to integrate in your existing Puppet / Bolt infrastructure and has contextual setup instructions for each integration, but if you want help in trying it in your infrastructure, example42 offers a launch special, time limited, free installation service, no strings attached. In a shared screen call we can setup Pabawi together, either using its container image or via npm. We want to test and validate it in different conditions, collecting users’ feedback and suggestions. Just contact me on LinkedIN for planning a call: half an hour should be enough to set it up and see how it works. Alessandro Franceschi

R.I.Pienaar - www.devco.net: Choria Hierarchical Data

2025-11-24T23:00:00+00:00

As most are aware, I created the widely used Hiera system in Puppet. I introduced it in 2011, and it has since become essentially the only way to use Puppet in any meaningful fashion. Given its widespread adoption, I donated the code to Puppet, and it became integrated with Puppet core.

Unfortunately, during this integration we lost some key values—the command line and the ability to use it in scripts and elsewhere.

Meanwhile, our world is changing, and we are ever more focussing on small, single purpose compute. I intend to create a new kind of Configuration Management system that is focussed on the small, single, purpose needs. Filling the gap that has always existed - how to manage our applications rather than systems, an area Puppet has always been weak at.

There is then still the need for hierarchical data and given that I have the flexibility to start completely fresh I am at best taking some inspiration from Hiera.

So today I’ll introduce a new tool called Choria Hierarchical Data - current code name tinyhiera but that might change.

NOTE This post was first posted on the Choria blog.

Read on for the details

The big difference here is that this new system supports just one data file, you express a data structure that is the complete outcome of the query and then configure in the same file how to override and extend that data file.

Let’s look at it, here I’ll show the different sections, in reality it’s just one file.

This is the data we wish to manage:

data:
    log_level: INFO
    packages:
        - httpd
    web:
        listen_port: 80
        tls: false

Lets define the hierarchy for overriding this data; this should be familiar to Puppet users:

---
hierarchy:
    merge: deep # or first
    order:
        - env:{{ lookup('env') }}
        - role:{{ lookup('role') }}
        - host:{{ lookup('hostname') }}

And finally, we show the overrides, here we just specify how the data will be extended:

overrides:
    env:prod:
        log_level: WARN

    role:web:
        packages:
            - nginx

        web:
            listen_port: 443
            tls: true

    host:web01:
        log_level: TRACE
        web:
            listen_port: 8080

We can now call our CLI tool to resolve this entire structure.

We query the data setting the role fact to web, the data from the role:web section is merged into the data from the data section:

$ tinyhiera parse data.yaml role=web
{
  "log_level": "INFO",
  "packages": [
    "ca-certificates",
    "nginx"
  ],
  "web": {
    "listen_port": 443,
    "tls": true
  }
}
$ tinyhiera parse data.yaml role=web --query web.listen_port
443

Features and Differences

This is the basic feature, similar to what you might have used in Puppet except differing in a few areas:

It’s all one file and one data structure, it’s not key-lookup orientated. The entire outcome is rendered in one query
Expressions used in overrides and data lookups are a full query language called expr-lang, this means we can call many functions, generate data, derive data and easily extend this over time
The data is typed, if your facts have rich data the results can also be rich data, if value is a integer, array or map the result will be the same type x="{{ lookup("value") }}"
The CLI has built in system facts, can take facts on the CLI, read them from JSON and YAML files, parse your environment variables as facts or all at the same time
The CLI can emit data as environment variables for use in scripts
There is a Golang library to use it in your own code

Environment Variable Output

We want this to be usable in scripts, the easiest might be dig into the data and just get a single value:

PORT=$(tinyhiera parse data.yaml role=web --query web.listen_port)

But this involves many calls to the command, we can instead emit all the data as variables.

$ tinyhiera parse data.yaml role=web --env
HIERA_LOG_LEVEL=INFO

You can see the data is emitted as environment variables that you can just source into your shell script, obviously in this use case it benefits to have flat data.

Built-in facts

We have many ways to get facts into it such as files, environment variables, JSON and YAML files. The CLI also includes it’s own mini fact source called system which will return facts about the system it is running on.

To view the facts fully resolved, we can run the following, I am removing much of the details here but you can see this offers enough to make most required decisions:

$ tinyhiera facts --system-facts
{
  "host": {
    "info": {
      "hostname": "grime.local",
      "uptime": 1843949,
      "bootTime": 1762258234,
      "procs": 711,
      "os": "darwin",
      "platform": "darwin",
      "platformFamily": "Standalone Workstation",
      "platformVersion": "26.1",
      "kernelVersion": "25.1.0",
      "kernelArch": "arm64"
    }
  },
  "memory": {
    "swap": { },
    "virtual": { }
  },
  "network": {
    "interfaces": [ ]
  },
  "partition": {
    "partitions": [ ],
    "usage": [ ]
  }
}

Long-term view

Autonomous Agents

The goal here is to incorporate this into various other places, first we pull it into a Choria Autonomous Agents, these agents own the full lifecycle of an application:

Deploy dependencies
Configure the application
Run the application
Monitor the application
Restart the application on failure
Orchestrate rolling upgrades
Present APIs for interacting with the management layer

Agents can fetch data from a Key-Value store, but it’s kind of all the same data. With Hiera integrated into the KV feature, we get:

  - name: watch_tag
    type: kv
    interval: 10s
    success_transition: regional_update
    state_match: [RUN, RESTART]
    properties:
      bucket: NATS
      key: config
      hiera_config: true

Here the autonomous agent will check KV every 10 seconds for data, fully resolve it using Hiera and save the resulting data into the Autonomous Agent internal data store. If the KV data chanfes or the referenced facts change to the extent that the data change, the machine will update the stored data and fire the regional_update event.

This way we can create role-orientated specific data all in the same Key-Value key.

Configuration Management

I want to create a new CM system that takes the model we are used to in Puppet but brings it to scripts and reusable APIs.

The script use case would essentially be standalone commands:

$ marionette package ensure zsh --version 1.2.3
$ marionette service ensure ssh-server --enable --running
$ marionette service info httpd

This should be familiar to Puppet users, we’re basically pulling the resources and RAL into standalone commands. The commands will be fully idempotent like Puppet and support multiple Operating Systems.

For integration with other languages, you can also deal with JSON-in-JSON-out style:

# Can be driven by JSON in and returns JSON out instead
$ echo '{"name":"zsh", "version":"1.2.3"}'|marionette package apply
{
....
}

I do not want to create something huge like Puppet, but just basically enough that can enable the package-config-service trio pattern, ultimately a manifest would look like this:

cat <<EOF>manifest.yaml
data:
    resources:
        - package:
            name: myapp
            ensure: present
        - service:
            name: myapp
            ensure: running
            enabled: true

hierarchy:
    merge: deep
    order:
        - platform:{{ lookup('host.info.platform') }}
        - hostname:{{ lookup('host.info.hostname') }}

overrides:
    platform:darwin
        resources:
            - package:
                ensure: MyApp-1.2.3.dmg
EOF

$ marionette apply manifest.json --system-facts

Pull this into Autonomous Agents and you have self-contained, self-managing applications similar to Kubernetes Operators but anywhere.

Use this in scripts, simple setups, during container creation or orchestration, or even in CI pipelines.

We should even be able to compile this manifest, or a full autonomous agent, into a single, static, binary that you can just run as ./setup or ./manage and the entire lifecycle is managed with zero dependencies.

Availability and Status

You can get the command on GitHub choria-io/tinyhiera, we are pretty far along but expect some more breaking changes including a potential name change.

Overlook InfraTech: The new gem server in town

2025-10-06T00:00:00+00:00

If you’re in the Ruby world you may have been following the RubyGems shenanigans of the last few weeks. They suffered a poorly communicated corporate led rug-pull, not all that dissimilar to the games Perforce has played over the last year or so. Amusingly, they also claimed it was for security purposes without providing any actual rationale supporting that claim.

As you can guess, this caused a lot of consternation, especially in projects like OpenVox based on Ruby and in companies like Overlook InfraTech whose livelihood depends on Ruby.

You may want to read that last bit again. This heavily impacts companies whose livelihoods depend on Ruby.

Ah. Now that’s the root of the problem, isn’t it? There aren’t enough companies financially supporting the projects they’ve built their own businesses on top of. For example, Puppetserver would not be possible without JRuby and yet Puppet/Perforce didn’t bother helping the project through its funding crisis until they were publicly named and shamed and it became a PR problem for them.

We don’t believe in doing business that way and we now have an opportunity to live up to our ideals. The original RubyGems team has announced a community led and governed gem server. This means that we now have the opportunity to help build a new ecosystem that’s not supported and dominated by a single company out of touch with its community.

Post by @getajobmike@ruby.social

View on Mastodon

They don’t currently have a way to sponsor the project, so we are using GitHub Sponsors to throw down $100USD monthly for each of the current developer team. We encourage you and/or your employers to do the same by clicking the {sponsor} icon on each of these GitHub profiles.

Here’s to a better and more resilient Ruby ecosystem going forward!

Camptocamp Blog: Platform Engineering at CNS Munich

2025-08-26T14:33:58+00:00

This year Cloud Native Summit (CNS) in Munich gathered adopters and technologists from open source and cloud native communities.

Compared to last year's Kubernetes Communities Days (KCD), the agenda dedicated many slots to Platform Engineering. This discipline can be seen as a way to fill gaps between different stakeholders of an Internal Developer Platform (IDP). Last year I wrote an article on this topic at the KCD Munich. This year I would like to share fresh ideas or principles from some talks given during the conference.

Identifying problems before solutions

Day 1 opened with a presentation of "Product thinking" approach made by Stéphane Di Cesare (Deutsche Kreditbank) and Dominik Schmidle (Giant Swarm). They reminded some core principles and techniques of "Platform Engineering" to manage the link between problem space and solution space.

Day 1 also closed with a panel discussion on "Platform Engineering" animated by Max Körbächer (Liquid Reply), focused on the adoption of IDPs by end users and within projects.

Video 1 Platform Thinking

Video 2 Panel Discussion

AI workloads on K8s

"Use platform engineering for AI workloads on K8s", that was the motto of the presentation given by Mario-Leander Reimer (QAware GmbH). He tackled emerging challenges for deploying Agentic AI workloads and introduced an example of what a platform should cover including quality plane and compliance plane. His talk is part of an open source initiative launched at QAware this year to mature the concepts of a dedicated control plane: the agentic layer.

Video 3 Architecting and Building a K8s-based AI Platform

Composable platforms on Kubernetes

Hossein Salahi (Liquid Reply) presented a reference implementation to streamline the delivery of services for developers. Some of the challenges were to link dev and ops, to manage services in configuration, to orchestrate infrastructure deployment and to manage access. For that purpose the open source tools Kratix codify a contract between dev and ops. Combined with Backstage, this abstraction allows services to be packaged and delivered to developers.

Video 4 Modular Platform Engineering with Kratix and Backstage

Reduce cognitive workloads

Interestingly the problem of cognitive workloads due to some platform complexity was a recurring theme. But Michel Murabito (Mia Platform) positioned platform engineering as a way to reduce cognitive workloads. He highlighted essential building blocks and features that can reduce mental burden.

Video 5 Creating a smooth Developer Experience

Involved user as contributor

Lian Li (lianmakesthings) told us a story of what can go wrong when building a platform based on real examples and some facts. She advocated some receipts that can improve communication among teams in an organisation and explain some benefits of having contributing users in the loop.

Video 6 Many Cooks, One Platform: Balancing Ownership and Contribution for the Perfect Broth

Convergence

Evelyn Osman (enmacc) discussed the importance of convergence when building a platform in order to avoid fragmentation in teams and solutions. She shared some important steps that foster innovations and better meet user expectations.

Video 7 Convergence on Platforms

Conclusion

This is not an exhaustive list of what was discussed, but somehow it made it clear that Platform Engineering approach can help picking the right solution in the open source landscape. Some enablers already provide a strong integration with Kubernetes to develop and publish new services on top of it. And depending on the organization, some shift in practices also might be required to follow the evolution of the platform at build and runtime. The conference was a great place to exchange with the community on technical and organization challenges.

References

betadots: 🧩 Puppet Module Update Process

2025-07-11T07:59:30+00:00

🔍 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

betadots: 🧩 Puppet Modul Update Prozess

2025-07-11T07:58:40+00:00

🔍 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

Overlook InfraTech: So much for being developer first

2025-06-12T00:00:00+00:00

Well, it appears that Perforce has taken another step down the enshittification journey. For some strange reason, it appears that they don’t want you writing Puppet modules unless you’re a paying customer. That’s right, they killed the open source PDK and sequestered the source away, just like they did with Puppet. They would like you to pay for the privilege of creating content for them.

This is a very strange strategic move on their part. Their ecosystem is almost entirely supported by community authors building and maintaining Puppet modules. A full 96% of their paying customers use modules supported by Vox Pupuli, many of which are open source users. They barely even maintain their own modules in the puppetlabs namespace. Most of the contributions there have for years come from community members using the Trusted Contributors program that I built when I was still there.

On a related note, it also appears that they’ve shut down the Trusted Contributors program as it’s no longer mentioned on their website.

In reality, they don’t even have a dedicated modules team anymore! One with any sense at all would think that given this lack that they’d want to encourage people to build and maintain quality content in the ecosystem rather than putting barriers in place to make that harder to do. 🤔

My only assumption can be that the Puppet Core sales aren’t so hot and they need something, anything, to juice the numbers a bit.

But does it actually matter?

In all reality, many of us never really liked using the PDK. It’s really big and inflexible. The customization options are confusing and tedious. It generates way too many random config files for services that most people never used, unless you customize it, which again is super awkward. And maybe worst of all, it was designed primarily for the use of Puppet’s modules team (it still existed back then) rather than being designed for community developers. For example, until a few years ago, it configured PR testing and publishing workflows with GitHub actions that assumed that you were using Honeycomb for profiling and hardcoded the puppetlabs namespace.

Vox Pupuli developer tools

Luckily, Vox Pupuli has been working on replacements for a while. We believe that developer tools should be small and purpose-built rather than trying to jam pack all the things for all the people into a single massively overloaded tool.

Rather than using the exact same command used to

create a module from a template
run unit testing in CI pipeline
manage installed Puppet versions
build and publish modules
drop into the debugger REPL that you probably didn’t even know existed,

Vox Pupuli’s toolkit includes smaller tools that do one or two things well instead of being mediocre at trying to do everything.

For example, our modulesync tool makes it easy to create, manage, and update a group of modules based on a template. No more broken dependencies because you haven’t remembered to update one of your modules for the last four years. All your modules, whether that’s one or one hundred, will be in a consistent state and tested against your current infrastructure.

Or you can get zero-install access to a whole suite of module testing and management tasks with voxbox. Update your module’s metadata, validate all of its dependencies, and publish a new version all with a few podman commands.

The Vox Pupuli Devkit SDK

Now that easy access to the PDK is disappearing, we’ve put together a project to collect all these tools and more into a coherent suite that’s usable, discoverable, and maintainable. We’ll build the missing parts along the way. For example, I’m currently working on an asdf / mise plugin to easily manage OpenVox versions using an industry standard tool rather than something bespoke that’s constrained to very specific and limited workflows.

We don’t have a timeline on this yet. But luckily, there’s not much development on the PDK except to make it harder for you to use. You can very likely simply continue to use the version you already have installed until we have more news for you.

Watch this space and we’ll soon have information for you about the new Devkit SDK!

Overlook InfraTech: OpenVox InfraTales - MacOS Signing and Notarization

2025-05-12T00:00:00+00:00

Hi everyone! Nick here. I figured it was time I finally write a blog post. If you’ve seen me around on the Vox Pupuli Slack, you know that I’ve been deep in the trenches of OpenVox build code for some time now, getting the various bits to a secure and stable place where it’s easily accessible to community contributors.

Today’s story is about wrestling with MacOS’s Gatekeeper so we can release a production-ready MacOS agent build.

No unsigned code, ever

Perforce recently dropped a LinkedIn post about their latest Puppet Core release, bragging about how secure and enterprise-ready Puppet Core is. The one that stuck out to me: Fully signed binaries and agents - no unsigned code, ever

They’re right - unsigned binaries are like showing up to a formal dinner party in a crab costume. In OpenVox-land, all of our Linux binaries are fully signed. However, just like how Perforce’s internal dev builds are not always signed, our prerelease, non-final MacOS and Windows agents were unsigned (Windows remains so until we navigate the extortion racket that is paying for an Extended Validation code signing certificate from a vendor).

I applaud Perforce on their journey towards creating the safest, most secure Puppet environment possible, so I thought I’d write this little guide to help them take the next step. In order to reach the utopia of a fully signed and notarized MacOS agent that Gatekeeper is happy with, we have to not only sign the right things, but notarize it as well.

Gatekeeper: The ever vigilant security guard of MacOS

Apple’s Gatekeeper ensures that the software you download and run is trusted and safe. If your software isn’t both signed and notarized in the correct way, it will flat out refuse to open it (without extra shenanigans), warning that you potentially downloaded a radioactive piece of malware and you should be ashamed of yourself.

To make Gatekeeper happy, all you used to have to do in the halcyon days of pre-Sonoma was to sign the specific binary entrypoints into your app with an “application developer identity” (certificate + private key). Let’s dive into the GitHub mines and see how this is currently done.

Warning: There be dragons in these mines

The way that Perforce does this signing process for their current MacOS agents (or at least they did before taking everything private, but I don’t believe it has changed) is by sending the three executable files in the puppet-agent package to a signing server, which signs those files, and then sends them back to continue the build process. You can see how this is defined in the puppet-agent repo. This utilizes Vanagon’s ExtraFilesSigner to lay down a bash file to run the command, rsync the file over, run the command, then rsync the file back. This process is embedded in Vanagon’s MacOS platform build process. This code ends up with a dmg that contains a pkg installer, which contains all the files, including those three signed binaries. Finally, the pkg file must be signed with a different “installer developer identity”. Perforce does this by mounting the created dmg, signing the pkg with that identity, then recreating the dmg file with that signed pkg.

Signing and Notarization: Everyone’s favorite migraines

While this worked fine before, as of MacOS 15 Sonoma, the requirements are much more stringent. Not only must you sign the these binaries, but you must sign every single binary, dylib, and bundle file, no exceptions. And on top of that, you have to sign all of them specifying it should use the hardened runtime via the --options runtime flag to the codesign tool, as well a secure timestamp via the --timestamp flag. Doesn’t matter if the files are already signed in a different manner. MacOS 15 has a refined palate and will only consume the finest artisinal binaries. Yes, it’s probably for the best, but I digress.

Additionally, you must notarize either the dmg or pkg file. This involves sending your file to Apple, where their system scans for any hidden nasties and verifies everything that should be signed, is signed in the correct way. Once approved, you then must staple the notarization to the dmg or pkg so Gatekeeper can stop judging us.

Bringing a first pass of order to chaos

Right now in OpenVox, unlike Linux agents where we use containers to build them, we’re building the MacOS agent in a VM that is configured in a particular way with the appropriate bits and bobs installed. This is similar to how Perforce does it, except that this particular VM template also includes the bits needed for signing and notarization. This is not highly portable and accessible to people yet, but we wanted to get this agent into your hands as soon as possible. Soon, we’ll be moving the process into GitHub Actions and hopefully finding a way to build it locally without a Mac as well. We’ll take this awkward Ford Pinto and turn it into a Ferrari. Or at least a Honda Accord.

For this first pass at MacOS agent signing and notarizing, I moved the process entirely into Vanagon. While this may not be where we want to leave it since it reduces potential future flexibility, it makes sense for now since the only MacOS thing we sign is the agent, and this keeps the signing code from being spread across three different repos. This also streamlines the process, since we can do the signing and notarizing as part of the build, rather than having to unpack the build, sign the pkg, then repackage it into a dmg.

This new code hard-codes where to look for binaries that need signing within the agent package. This is not at all ideal, and is ripe for future improvements like moving this definition back into the vanagon project itself. But because it isn’t obvious which files need signing (i.e. binaries don’t all live in the same place, don’t all have a particular suffix), this is an easy way for us to utilize find -exec to sign all the pieces. Another improvement made here is that at every step, we verify the signing/notarizing worked correctly. This gives us an extra layer of confidence that the delivered agent will not shout obscenities at you.

As before, we sign the pkg file, but we do it before building the dmg. Then, we build the dmg and sign that, after which we notarize using the notarytool in Xcode. Usually, the notary process takes less than 2 minutes. On our initial submissions, it took days as they were being manually reviewed. Now that the system recognizes our submission, it is much faster. Once notarization is approved, we staple that notarization to the dmg and then check with Gatekeeper that it isn’t going to complain.

The Bureaucracy: D-U-N-S numbers and Overlook InfraTech, Inc.

Figuring out this whole process was quite a bear. Apple’s documentation mostly assumes you are developing with the Xcode GUI app, and not trying to do everything from the command line. It isn’t terribly clear exactly what needs to be signed and notarized and how without some more digging and trial and error.

Another thing that isn’t terribly ideal is that in order to have a developer account tied to an organization, that organization has to be a full fledged legal entity with a D-U-N-S number. If you ever start a business, you’ll find that you need a franky ridiculous amount of different identification numbers that tell people your business is, in fact, a real business, and this number is just one of many. Vox Pupuli doesn’t have this, so the agent is signed with the Overlook InfraTech, Inc. account. This has the side effect that our company name shows as the one that owns the puppet and pxp-agent background tasks. This should absolutely say Vox Pupuli and hopefully one of these days we can change that.

Final thoughts: Let’s work together

To my knowledge, Perforce does not have their MacOS 15 agent notarized, nor signed with MacOS 15’s newer stringent requirements (repeating my disclaimer: I do not know for sure, as none of us has visibility into their current build process or access to their current agents without signing a EULA which prevents you from inspecting any of the code anyway). I’d love to submit some PRs to their repos, but unfortunately, they have seemingly completely abandoned them in favor of their internal forks. That’s a bummer, because security is a team sport, and we all benefit when the ecosystem is safe. Nevertheless, I invite them to take a look at our work here to assist in getting their MacOS agents notarized, and I’d be more than happy to work with their engineers to assist. Thrilled, in fact. And I promise I’m not being sarcastic about that.

If you’re curious for more details about how we did this or how we do any of the OpenVox things, drop by the Vox Pupuli Slack or IRC, both of which you can find in the Connect menu of voxpupuli.org. I’m always happy to chat, even while I’m debugging why a binary isn’t signing properly at 2AM. If you have any other topics you’d be interested in hearing more about in this blog, drop me a line any time.

Overlook InfraTech: The OSU Open Source Lab needs your help today

2025-05-01T00:00:00+00:00

Have you been looking at the OpenVox project and wondered what you could do to help out? What if I told you about an opportunity to help us, and also hundreds of other OSS projects that you probably rely on? The OSU Open Source Lab is OpenVox’s primary package host and helped us get the project off the ground right from the start. They help hundreds of open source projects with critical infrastructure needs that many projects (like us) would not have been able to afford on their own.

🔔 tl;dr; the Open Source Lab needs your help

Not only that, but they have been training the next generation of FOSS DevOps and system infrastructure engineers for YEARS. Many of the first Puppet community practitioners came up through the OSL. They contributed many of the first Puppet modules. The venerable Pro Puppet second edition was written by OSL students in collaboration with PuppetLabs developers, including myself.

OSL has played a HUGE part in Puppet’s story and helped Puppet, Vox Pupuli, and OpenVox get to where they are today. I’d wager that your company uses OSL resources on a regular basis and may not even realize it. Take a look at the list and you’re certain to find something business critical.

However, with the current crisis in academic funding in the USA, they are in critical need of funding and without your help, they may cease to exist. See this blog post for more information and go talk to your boss today! Don’t hesitate to drop them some cash yourself if you can spare it.

Camptocamp Blog: Talos Linux: a new standard for on-premises Kubernetes clusters?

2025-04-22T17:44:21+00:00

A few weeks ago, I was at KubeCon Europe 2025 in London and I had the opportunity to attend a presentation that tackled the monumental challenge of migrating 35 Kubernetes clusters in an air-gapped environment from nodes deployed with a mix of kubeadm/Ansible/Puppet to Talos Linux nodes deployed using Cluster API.

While the presentation was quite interesting (you can get the slides here and watch the session recording on CNCF's YouTube Channel), I want to dive more into the Talos Linux project and its features.

What is Talos Linux?

Talos Linux is a modern Linux distribution purpose-built for running Kubernetes clusters. Some noteworthy characteristics of Talos Linux are:

Immutable: Talos Linux is designed to be immutable and always runs from a SquashFS image. This means that the operating system is read-only and cannot be modified at runtime. This immutability provides a strong security posture and means that there is no need to worry about unintended changes to the operating system.
Minimal: Talos Linux is a minimal operating system that only includes the components necessary to run Kubernetes. All the OS is built from the ground-up and no unnecessary components are included. This minimalism reduces the attack surface and improves performance.
Ephemeral and Declarative: Talos Linux nodes are ephemeral and everything written to disk is reconstructible. It is also declarative, meaning that the desired state of the system is defined in a configuration file and gRPC API, which is perfect for someone that loves automation and reproducibility, like myself.
Secure: As a consequence of its design, Talos Linux provides enhanced security features, ensuring that the system remains robust against various threats.
Agnostic: Talos Linux is cloud-agnostic, allowing it to run on various cloud providers and on-premises environments without vendor lock-in.

In summary, and I'm quoting the official documentation, "Talos is meant to do one thing: maintain a Kubernetes cluster, and it does this very, very well."

My thoughts

I have been following the Talos Linux project for a while, and I was gladly surprised to see a Swiss-bank like PostFinance being on the forefront of adopting such modern solutions like Talos Linux and Cluster API.

I think Talos Linux will be a key player in the Kubernetes ecosystem, especially for organizations looking for an on-premises solution that's secure, efficient and easy to manage.

The fact that Talos is declarative and immutable might seem like a drawback at first for someone used to the old ways of managing infrastructure with Ansible or Puppet, but I believe that this is the future of managing Kubernetes clusters.

I want my nodes to behave like pods that I can easily create, destroy, and replace. Besides, I don't want to deal with the overhead of managing the operating system. I already have enough to deal with the on-premises infrastructure for the network and storage and the Kubernetes cluster itself, so why not offload the management of the operating system to a purpose-built distribution like Talos?

With Omni, Sidero Lab's SaaS platform for managing Talos Linux clusters, I believe Sidero Labs have a good revenue model to continue developing Talos Linux. As a fan of open-source, we are all aware of the challenges of maintaining a project like Talos Linux, and I believe that having a SaaS platform to manage Talos Linux clusters is a good way to ensure the project's sustainability.

Talos Linux vs. other solutions

Red Hat OpenShift is a well-known solution in large enterprises. However, more than a Kubernetes distribution, it is a complete platform that includes a lot of features and components, including CI/CD tools, monitoring, etc. It is also expensive.

On the other hand, Talos Linux shines with its simplicity and minimalism, which brings more flexibility and allows teams to choose their solution to complete the platform as they see fit.

RKE2 is another Kubernetes distribution that focuses on simplicity and security, making it a strong contender for organizations looking for a lightweight solution. However, it still requires an underlying operating system that you need to operate.

Bonus

While at KubeCon, I had the opportunity to visit the Sidero Labs' booth and talk to the team behind Talos Linux. I thank the team for a warm welcome and great conversations about the project.

Go further

I wanted to keep this blog post short and not too technical, but if you want to learn more about Talos Linux, I recommend checking out the following resources:

Overlook InfraTech: A whirlwind conversation on trademarks

2025-03-20T00:00:00+00:00

Quite a few people over the last few months have helpfully pointed out the name collisions in the OpenVox Puppet fork. If you didn’t recognize it, there’s also a VoIP/PBX provider called OpenVox. Surely that’s got to be a violation of some kind of law, right? Even Google gets it very wrong! See how our information is interleaved in this autogenerated profile?

Hold up though. Not so fast because it’s not quite that simple. Lemme tell you a quick story about a name that I’m pretty familiar with: Bolt.

The Bolt story

In August of 2017, Puppet began work on a new project intended to be an agent-less orchestration tool for automating the manual work it takes to maintain your infrastructure. Sure, it started life as an Ansible competitor, but it grew to be pretty neat. For the first time, you could trivially and seamlessly interleave shell scripts and Puppet code and just push that configuration out to nodes in your infrastructure as needed.

Imagine my surprise when I visited the Slack booth at KubeCon the following year and saw their new application library called… none other than Bolt. It had gone through several name iterations, including Slapp which is my personal favorite, but Bolt is what they settled on. I asked if they knew about our tool and they nodded and brushed off my concerns. Obviously, I raised it to our Legal team and was surprised when they also brushed it off.

So then I started noticing all the things named Bolt.

In the Pacific Northwest where I lived, we had the Bolt Bus
There were the Bolt e-bike rentals
There’s the Bolt rideshare and rental company
There’s the silly Bolt movie about “superhero” dog.
There’s an ecommerce platform named Bolt
There’s a mobile app tool named Bolt
There’s a CMS named Boltcms
There’s an investment platform named Bolt.
There’s a gear lock brand named BOLT
There’s a biotech company named Bolt
There’s an insurance company named Bolt

Aaaaand I’m tired of typing out that list, so I’m just gonna stop at that.

What purpose does trademark serve?

Clearly there’s more to trademark enforcement than just the name itself. As it turns out, that’s only a small part of it. At this point, I’ll take a real quick aside to remind you that I’m an open source software nerd, not a lawyer. And I’m certainly not your lawyer so none of this is legal advice. In any case, the concept of trademark law isn’t really to give you an asset to own, it’s to protect consumers in the market from brand confusion. You’ll notice that none of those companies I listed are named Bolt and also do infrastructure orchestration.

A trademark is a word, phrase, or logo that identifies the source of goods or services. Trademark law protects a business’ commercial identity or brand by discouraging other businesses from adopting a name or logo that is “confusingly similar” to an existing trademark. The goal is to allow consumers to easily identify the producers of goods and services and avoid confusion.
– Wikipedia

There’s a commonly used rubric called the DuPont Factors which can help identify whether there is a probable infringement. The rubric has 13 criteria, but they boil down roughly to

Similarity of the marks.
Similarity of goods/services.
Similarity of trade channels.

So that explains why we aren’t concerned with the fact that there’s a product out there named OpenVox but is in a totally unrelated industry. In other words, someone looking for an infrastructure management system isn’t likely to accidentally purchase a PBX system, even if the name is the same.

What about the filenames?

But there’s another point that comes up frequently that’s not quite as clear. That’s the name and paths of the executables and the configuration files and such within the OpenVox packages. At this point, they’re exactly the same as the original Puppet packages. In other words, to configure OpenVox, you edit the puppet.conf file and to run the agent you invoke puppet agent -t. We negotiated this point very heavily with Perforce in order to not cause community disruption.

There are a few non-legally-defensible reasons why Perforce might agree to this usage and a couple reasons that are legally defensible. First off, let’s look at why Perforce might be motivated to allow this usage. These are not reasons that would stand up in court, if it came to that, but are ways in which Perforce benefits from it.

They get a little bit of free marketing. Every time someone types puppet agent -t they’re reminded of where OpenVox came from.
If someone using the system were to be confused by the name, it would likely be to Perforce’s benefit. In other words, if someone trialled OpenVox and typed ‘puppet’ a whole bunch, there is a small chance that when they submit an order to their purchasing department that they might accidentally request a Puppet purchase. It would never go the other direction.
If we had to change all the commands and paths today, then the ecosystem would be forced to write complex abstractions or explanations with every module, tool, tutorial, README, guide, etc. It’s more likely that they’d take the easy way out and choose one or the other, thereby fragmenting the ecosystem.

That last point deserves more explanation. OpenVox and Puppet by themselves aren’t terribly useful. Their value comes from the modules that enable the management of Apache, MySQL, SELinux, etc. So the modules and the tools that make building modules easier are of utmost importance. All these modules and tools and the documentation around them are currently written with the expectation of the existing paths.

If we changed these paths, then every single part of the ecosystem would have to account for the path change. It’s a comparatively high lift to abstract the name and paths out, whether it’s in code or docs, so it’s likely that most people will just choose a side and then search and replace ‘openvox’ for ‘puppet’. This is why Puppet modules and GitHub repos are all still in the puppetlabs namespace, for example.

There are two reasons why Perforce would be on the losing end of that schism. First is that Perforce is now attempting to sell something infinitely more expensive than its former price of free. Very few people creating and sharing free open source content would choose to support that ecosystem rather than the FOSS alternative. The second reason is that 96% of Puppet’s enterprise customers use Vox Pupuli modules and, for all practical purposes, 100% of them use Vox Pupuli’s dev tools since they’re vendored into the PDK. Vox Pupuli is obviously choosing to support OpenVox even if that has to be at the exclusion of Puppet itself.

There are also legally defensible reasons. Even if Perforce weren’t convinced by the reasons already stated, these would almost certainly lead to them losing a court case if it came to it.

By the time that someone has researched, and purchased (or not), and downloaded, and installed, and configured the system, it’s highly unlikely that they would be confused about whether they were running Puppet or OpenVox. Remember that the goal of trademark laws are to protect against confusion in the market. Several of the DuPont factors look at trade channels and the difference between downloading an OSS tool and talking to Sales is quite stark. If this were the only point we had to go on, it probably would not be enough. But there are better defenses.
Trademark is intended to protect a brand, not functionality. If something is used for functional purposes, then it cannot under the Functionality Doctrine be considered a trademark infringement. The canonical case here is Sega v. Accolade of 1992. Sega included a “Trademark Security System” which relied on the string “SEGA” to exist in a known memory address on a game cartridge. If the code were present, the game system would display a trademark notification and play the game. If it were not present, then the game wouldn’t play. Accolade added the code to their games and won the court case when Sega sued them for trademark infringement because the trademark was used for functionality.
Command names and file paths are a functional interface to a piece of software. In other words, if a tool or system wants to integrate with Puppet, then it will often do so by configuring puppet.conf or running puppet commands. If we are to build a Puppet-compatible product, then it has to use the same command names and paths. Our industry is littered with examples of this going back for many decades. Think about how many MTAs install /usr/sbin/sendmail, for example. On my Mac, that’s provided by Postfix. The actual Sendmail company, now owned by my former employer Proofpoint, has had three decades to dispute that use and has not. Another example is MySQL, owned by what might be the most litigious company in existence (Oracle.) When MariahDB forked away, it was ten years before they bothered to replace the admin commands like mysqladmin and even today they ship symlinks so you can still run that command.

The path forward

We have no concerns about trademark infringement today. The OpenVox PBX system is in an entirely different industry and won’t be confused with the OpenVox configuration management system. Perforce and OpenVox are both incentivized for us to keep using the existing command names and paths. And even if they weren’t, there is significant legal precedence to defend our use.

With that said, it would benefit our own brand to have our own command names and paths. Over the next year or so, we have a roadmap to achieving this safely and with as little community disruption as possible. We will first build an integration acceptance test framework so that we can tell quickly when we screw it up. Then we’ll gradually start replacing commands and paths with our own versions while leaving symlinks in place so that integrations continue to work. Then finally, we’ll extract those symlinks into an optional openvox-puppet-compat package that will likely never go away.

In order to make Puppet extensions universal, we aren’t planning to ever change the internal file hierarchy that makes up the documented API. And if that ever does change, we’ll do it in cooperation with Perforce to retain compatibility.

Overlook InfraTech: Paying their fair share

2025-02-28T00:00:00+00:00

The other day someone shared a Puppet Community Slack post in which a very senior Perforce sales engineer stated plainly that the reason for their sequestered source shenanigans is that they’re “asking open source users to pay their fair share.” Now, I don’t want to sound like I’m poking fun at this particular corporate flunky, he’s only repeating what he’s clearly been told over and over again, but What. The. Fuck.

Besides making it exceedingly clear that the only thing that Perforce understands about open source communities is a bunch of people who happen to own wallets or purses, this also demonstrates a devastating lack of understanding of their own product. Let’s break it down, shall we?

What you think of as a big beastly monolithic application called Puppet Enterprise is mostly a lot of open source tools jammed together with some proprietary business logic duct tape and baling wire. No surprise there, that’s how most enterprise apps are built these days.

The puppetserver application is business logic implemented in the open source Clojure runtime. It drives puppet via the open source jRuby runtime. These are packaged up into a jar with a lot of open source components like the open source Bouncy Castle which is of course built on top of the open source OpenSSL library. This jar is then run with the open source openjdk Java runtime. To build it, they use the open source Jenkins CI/CD platform. Packages are generated with the open source fpm tool.

And that’s only puppetserver. The puppet-agent package uses open source nssm (now defunct) to run on Windows because they couldn’t be arsed to write their own service management. PuppetDB is just a business logic wrapper over the open source PostgreSQL database server which was chosen because it was the only one with the primitives they needed. The Puppet Enterprise Console is built on the open source Ember framework. I could go on listing the projects that Puppet depends on, but that would easily triple the length of this article.

There is very literally not a single part of Puppet Enterprise that stands alone. More of the PE installer is open source packages than it’s Puppet Enterprise itself. And yet how much do they contribute back? Do you think they “pay their fair share?”

No. It’s zero. When jRuby put out a desperate call for funding, do you think Perforce chipped in? Have they ever contributed to OpenSSL? Has @whack ever seen a dime for the thousands of packages Puppet built with fpm? No. None. Perforce has never contributed a penny. They’ve just taken and taken.

Update, hey neat! Looks like raising the issue finally got jRuby some support. Let’s hope that they continue funding their dependencies.

Post by @headius@mastodon.social

View on Mastodon

To be clear though, that’s not the part of this that’s so offensive. Perforce’s sponsorship record is pretty standard for the corporate world. Puppet itself, prior to Perforce, didn’t contribute all that much more. What is utterly offensive is this idea that somehow the very community that built the foundation that Puppet sits on isn’t “paying their fair share”.

Let me tell you about “their fair share.” Many of you know that I spent thirteen years at Puppet and I ran Community for a large part of that. So I can give you actual real numbers. A full 96% of Puppet’s paid customers uses Vox Pupuli’s open source community modules. And the remaining 4% would have except their policies required them to write all their own content.

When it comes to paid Puppet customers, we should acknowledge how many of them are customers because of the community. I’ve attended many “vendor appreciation dinners” where the point of me being there as a community representative was to make sure that Puppet, Inc continued to remember that investing in community was required. The single biggest deal Puppet ever closed hinged on a community interaction that I and some Vox Pupuli members enabled. We talked through a hypothetical solution to the problem at hand and then I built it on my spare time as a community member.

Then if you want, we can get down to raw contributor data and I could show you how many community members contribute to Puppet codebases more even than most Puppet employees. A quick count shows that only 54 of the top 100 were Puppet employees.

Puppet’s community is the foundation for Puppet Enterprise and the whole company. When we did the massive upgrade from 3 to 4 and needed all the tooling to find all the weird edge cases, the community is who pointed out what we needed to validate and built tools like catalog-diff to give us a starting point. When we pulled core resources out to modules in Puppet 6 and broke every testing pipeline in the world, the community worked with Josh to fix it. And now that Perforce is insisting on shooting its own feet, the community is once again stepping up to ensure that an open source community actually continues to exist and help each other out. That community still includes their paid clients and somehow Perforce continues to lose sight of that fact.

The fact that the messaging that their representatives share is that open source community users need to step up and “pay their fair share” is a slap in the face to the community that has provided the foundation for the entire company to exist on. Without these people Puppet by Perforce would not exist.

Puppet by Perforce doesn’t pay their fair share in any way shape or form, and for them to self-righteously demand that from their users demonstrates how little they understand the space and how parasitic they are. I wish that they weren’t so representative of the industry.

The reality is that open source projects help your company. They accelerate your GTM (go to market) velocity a TON. And open-sourcing your own product leads to rapid adoption by open source community users who give you so much free marketing and product feedback and are the final line of QA before changes hit your paying customers. All in addition to the code and docs and expertise contributions. But this doesn’t come without cost to you. If you use the benefits of open source software then you have to pay the costs of open source software. It’s not a lot. It just means that you have to understand that the value you derive from open source communities is inherently a function of your product being freely available. When the vultures swoop in and try to alter that power balance, then you lose the benefits of the open source community.

And before you demand a “fair share” from your users, make sure that you’re doing the same. If your company uses open source software then contribute back. Either sponsor the project or contribute code, resources, or time. And if your community contributes code, or docs, or troubleshooting, or anything then freaking appreciate them for it.

Overlook InfraTech: CfgMgmtCamp wrapup

2025-02-17T00:00:00+00:00

Well, we’re back from Belgium after another successful week of conferences. First we attended FOSDEM in Brussels, then we hustled down to Ghent for the CfgMgmtCamp speaker’s dinner. This year is special to me because it’s the first year that I’ve not gone to represent someone else. It was also special because the atmosphere was so positive. There were a ton of great talks, more sponsorship dollars, attendance was up, more people showed up for the optional third day add-on than ever before, and people responded really well to the talk lineup. Chef even showed up to try and rebuild their community engagement!

In other words, it felt a bit like a revival. But I’ll come back to that. (Or you can skip directly to it, just like online recipes!)

Main stage panel at FOSDEM

It started on Jan. 21, 10 days before FOSDEM. There were some last minute schedule changes that I won’t speculate about too much ^{(they’re the same link, just two days apart)} and I was invited to participate in a panel discussion about project forks, why they happen, what they can do to the community and so on. Read more about it and see the recording right on the FOSDEM schedule page.

What a fun experience! Dawn was the original architect of the Puppet community and was my boss for all of a hot minute when I moved onto the team. But somehow this is the first time I’ve shared a stage with her. Everyone on stage was super knowledgeable and I learned a ton. In particular, Stephen Walli explains that statistically two criteria predict the success of a community fork

The community is put into existential crisis by actions of the original IP holder, and
One or more respected non-employee members of the community step up to serve as anchors.

This bodes very well for the future of OpenVox.

A busy week in Ghent

The main stage lineup at CfgMgmtCamp was fascinating. First, Hazel Weakly talked about the humanity behind software, configuration, and infrastructure management. This is an interesting perspective to me. As I see it, humanity is the unsaid reason behind the devops movement in the first place but we’ve now shifted far away from it. It’s no surprise that Puppet’s slogan used to be the human-forward “freeing you to do what the robots can’t” and now it’s bland corporate scare-words “avoid business disruption and minimize downtime.”

The thematic arc of the morning took us through these ideals we held when starting the devops movement, to the nitty gritty of OpenTofu’s escape from the corporate thumbscrews and recapturing their own personal power, to the real value of a content ecosystem and musing on a better way to build sustainable ecosystems.

Of course, the rest of the conference was just as good. We had two full days of two solid Puppet / OpenVox tracks covering all kinds of topics, from the technical to the speculative to the damage control. On the main stage Adam talked about the hypergraph of the future. James kept you on your toes by throwing fire again. There were a couple of talks about compliance. Stahnke showed us how he put his EPEL and Puppet knowledge to work with NixOS.

But there was still a vibe running through. Florian talked about toxic corporate environments and Nick explained how “source available” is such a woefully inadequate substitute for open source and ways to better appreciate your contributors. A lot of talks hinted at disillusionment with corporatism and the current state of the world. Lunch conversations debated the merits of various open source licenses and whether or not the GPL would prevent the licensing smash-and-grab ploys that so many once-great companies are pulling today. I lost track of how many people thanked me for my “yes, I’m a dirty hippie” slide.

I even overheard someone at a table nearby talking about their challenges in forming a tech union. I didn’t catch who or where it was, so if this was you, I’d love to hear more about it.

And that’s not even mentioning the overwhelming interest in OpenVox. Our community dinner (traditionally the Puppet Community and now the Vox Pupuli Community) filled the first floor of the Royal India. This was a nice healthy increase from years past and brought together several generations of Puppet / OpenVox community collaborators.

Some people were there for their first time and some had been there since the beginning; back when CfgMgmtCamp was still called a Puppet Camp and none of us had been acquired by private equity yet. But we were all united by two common interests: 1) keeping a community alive despite the best efforts of Puppet’s current owner to repeatedly shoot its own feet, and 2) excellent Indian cuisine enjoyed with friends.

For context: the conference is two days long, but they book the venue for a third day to make space for mini-events to tag along and colocate. Puppet has traditionally used this for a Puppet Community Day; Ansible and Foreman have similar events.

The optional third day is where this enthusiasm really shone through though. Not only were there more people who stayed for the third day than in years past, but every single person left the Puppet Community Day to join the OpenVox working session breakout. And as a measure of their commitment, at 5pm there were still 40-50 people in the room still hard at it, which is unheard of. Most people trickle out to catch their trains during the day.

We did not get quite as much done as we’d hoped, but everyone had the opportunity to participate and we set the groundwork for a stable and healthy project. In short, we adopted a Fedora SIG style governance and decided to remain an independent project via OpenCollective for the time being. As we mature a bit, we’ll continue investigating the Linux Foundation and other options.

Notes for the entire third day, including the Puppet Community Day and the OpenVox working session breakout can be seen in our wiki, thanks to Gene Liverman and Alex Fisher.

Insights

I think the positive vibes were mainly the result of three different factors.

First, the obvious

I don’t need to spend much time on this. With the media coverage and the furor around the clumsy way Perforce is stumbling through its community changes and the blatant money-grab, it’s no surprise to see excitement in our community. We shall see how much of that excitement is lasting.

What’s old is new again

For years, it seemed inevitable; cloud was eating our lunch. Every workload was becoming cloud-native, whether or not it really fit there, and the idea of managing configuration of long-lived instances was beginning to feel quaint. But there was a lot of foreshadowing, especially for those of us who’d been around for a few boom-bust cycles. A lot of the same problems being solved, a lot of the same challenges being (re-)discovered, opaque builds, semi-reproducible artifacts. And so much of it is tied together with not much more than the shell scripts I used to build production chroots back in the day.

The expected savings from cloud-native workflows haven’t really materialized either. If your workload is suited for, designed for, and optimized for the cloud then it can often be cheaper. But costs that were trivial at testing or prototyping stages have a tendency to unexpectedly balloon out of control at scale.

It’s not that cloud is bad. We’re actually moving a lot of workflows (such as the OpenVox build pipelines) to containers and it’s drastically simplifying what we’re doing. But now that the craze is dying down, people are realizing that it’s not the be-all end-all that it was promised to be. There are a ton of workflows well-suited to cloud & containers, especially transient and stateless tasks. But there are also a lot of workloads that benefit from being on-prem, or on long-lived stateful instances, or just don’t need the layers and layers of complexity.

And for these jobs, good old fashioned configuration management is right here waiting with its predictable pricing. The pendulum is swinging back to a hybrid infrastructure and we’ll all benefit from playing in the same sandbox. This year we saw a resurgence in config management community investment. But we also had a full Kubernetes track. And I find that very promising.

The industry, the world, and everything

There’s a lot going on right now. There’s somehow a blustery orange man-baby in the American White House again. For some unexplained reason, that gives Elon Musk the ability to go Twitter on the American government and slash essential departments protecting everything from consumer rights to the environment. “AI” is unsustainably disrupting industries and exploding the wealth gap. A lot of companies & industries aren’t fully recovered from COVID yet.

And right in the middle of that are company after company turning to corporate vampires and sucking the open source communities that built them dry. Is it any wonder that people are activating?

Back in the early 2000’s, I regularly protested with the EFF on the Santa Monica Pier in support of all sorts of digital rights and privacy protections. Not all the bystanders knew who the EFF was or what we were talking about. But most did or were curious to hear about it.

I’m getting some of the same vibes now. People are realizing that they need to take their interests into their own hands again. VC money has been cheap and easy for a very long time. And along with the foosball tables, that meant quite a bit of budget flexibility. It didn’t matter so much if you spent a few days polishing up a patch to contribute upstream when the runway was so long.

That’s been on the downswing for a while, but this last year really brought everything to a head. The investors and board members have come calling and they want their pound of flesh. And when it comes down to it, your boss cares more about the bottom line and the market cap than they do about you or your silly open source ideals. The days of founding a startup with a pair of dice are done. No more Uber but for dogwalking or AirBnb but for retirement homes or Tinder but for telling jokes.

Now it’s time for solidarity. People are realizing that the company they once trusted doesn’t actually have their best interests in mind. They’re seeing through the permissive license and contributor license agreement blinders. And they’re viscerally coming to grips with the idea that very few businesses include “provide something of value” as an actual business goal.

And they’re starting to do something about it.

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

2025-01-28T15:00:38+00:00

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

Overlook InfraTech: First release, hot off the presses!

2025-01-21T00:00:00+00:00

It’s been quite a journey, y’all. But we’re excited to announce the first release of OpenVox, the community-maintained open source implementation of Puppet. OpenVox 8.11 is functionally equivalent to Puppet and should be a drop-in replacement. Be aware, of course, that even though you can type the same commands, use all the same modules and extensions, and configure the same settings, OpenVox is not yet tested to the same standard that Puppet is.

Migrating is fairly simple, just replace the packages following instructions on the handy dandy new install page. You’ll notice that they’re still using the apt|yum.overlookinfratech.com repositories. As we get our infrastructure built out, these will probably be moved to the voxpupuli.org namespace. Please don’t use these packages on critical production infrastructures yet, unless you’re comfortable with troubleshooting and reporting back on the silly errors we’ve made while rebranding and rebuilding.

If you’d like professional assistance in the migration, check out our new OpenVox migration service.

We consider OpenVox a soft-fork because we intend to maintain downstream compatibility for as long as we are able. As such, Vox Pupuli is working with Perforce create a Puppet™️ Standards Steering Committee to set the direction of features and language evolutions.

The OpenVox project goals are pretty straightforward and aim to alleviate pain points observed by the community over the last few years:

Modernizing the OpenVox codebase and ecosystem including supporting current operating systems.
Recentering and focusing on community requirements; user needs will drive development.
Democratizing platform support by allowing community members to contribute what they need instead of waiting for business requirements to align.
Maintaining an active and responsive open source community like the rest of Vox Pupuli’s namespace.

Migration Service

Overlook InfraTech is an actual company with bills to pay and everything, so you knew there was going to be a plug here eventually. But we’ll keep it short and tasteful. We have been instrumental to the OpenVox fork right from the very beginning and we know inside and out what changes to expect. We are best situated to help you, so if you’d like professional assistance, or even just someone to look over your (virtual) shoulder during the process, we have a very reasonably priced migration service. Whether you’re ready to jump in and try it out today, or you’d rather wait a bit and let the dust settle, we’ll be here to help.

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

2025-01-20T18:50:29+00:00

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

betadots: Die Ruby-Seite von Puppet - Teil 3 - Benutzerdefinierte Typen und Provider

2025-01-20T18:48:32+00:00

Dies ist der letzte Beitrag in einer dreiteiligen Serie, die die Konzepte und Best Practices für die Erweiterung von Puppet mithilfe von benutzerdefinierten Fakten, benutzerdefinierten Funktionen und benutzerdefinierten Typen sowie Providern behandelt.

Teil 1 untersucht, wie man benutzerdefinierte Fakten erstellt, die es Knoten ermöglichen, Informationen an den Puppet-Server zu senden.

Teil 2 behandelt den Aufbau benutzerdefinierter Funktionen zur Verarbeitung von Daten oder zur Ausführung spezifischer Aufgaben.

Teil 3 (dieser Beitrag) konzentriert sich auf benutzerdefinierte Typen und Provider, mit denen Puppets DSL erweitert und Systemressourcen verwaltet werden können.

Typen stehen im Zentrum der deklarativen DSL von Puppet. Typen beschreiben den gewünschten Zustand des Systems und zielen auf spezifische, konfigurierbare Teile ab (manchmal betriebssystemspezifisch). Puppet bietet eine Reihe von Kern-Typen, die mit jeder Puppet-Agent-Installation verfügbar sind.

Einige der Kern-Typen umfassen:

file
user
group
package
service

Warum benutzerdefinierte Typen und Provider erstellen:

Es gibt mehrere Gründe, benutzerdefinierte Typen und Provider zu entwickeln:

Vermeiden von den oft unzuverlässigen oder schwer zu wartenden exec-Ressourcen.
Verwalten einer Anwendung, die CLI-Befehle zur Konfiguration benötigt.
Handhaben von Konfigurationen mit hochspezifischer Syntax, die bestehende Puppet-Typen nicht verwalten können (wie file oder concat).

Inhalt:

Allgemeine Konzepte
Typen und Provider in Modulen
Typbeschreibung
Provider-Implementierung
Verwendung benutzerdefinierter Typen in der Puppet DSL
Resourcen-API
Zusammenfassung

Allgemeine Konzepte

Ein Typ besteht aus zwei Hauptteilen:

Typdefinition: Diese definiert, wie der Typ in der Puppet DSL verwendet wird.
Provider-Implementierung(en): Ein oder mehrere Provider pro Typ definieren, wie mit dem System interagiert wird, um Ressourcen zu verwalten.

Typdefinition

Der Typ beschreibt, wie Puppet-Ressourcen in der DSL deklariert werden. Zum Beispiel, um die Konfiguration einer Anwendung zu verwalten:

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

Typdefinition haben einen Namevar (ein Schlüsselbezeichner) und mehrere Parameter und Properties (Eigenschaften).

Namevar: Der Schlüssel, der die Ressourceninstanz in der Typdeklaration identifiziert.
Properties (Eigenschaften): Diese repräsentieren etwas Messbares im Zielsystem, wie die UID oder GID eines Benutzers oder einen Konfigurationswert einer Anwendung.
Parameter: Parameter beeinflussen, wie Puppet eine Ressource verwaltet, spiegeln jedoch nicht direkt etwas Messbares im System wider. Zum Beispiel ist manage_home im user-Typ ein Parameter, der Puppets Verhalten beeinflusst, aber keine Eigenschaft des Benutzerkontos ist.

Der Unterschied zwischen Parametern und Eigenschaften wird auf der Puppet-Typ/Provider-Entwicklungsseite gut beschrieben:

Properties:

"Eigenschaften entsprechen etwas Messbarem im Zielsystem. Zum Beispiel sind die UID und GID eines Benutzerkontos Eigenschaften, da ihr aktueller Zustand abgefragt oder geändert werden kann. Praktisch bedeutet das, dass das Festlegen eines Wertes für eine Eigenschaft eine Methode im Provider aufruft."

Parameter:

"Parameter ändern, wie Puppet eine Ressource verwaltet, entsprechen jedoch nicht unbedingt direkt etwas Messbarem. Zum Beispiel ist das managehome-Attribut des Benutzertyps ein Parameter – sein Wert beeinflusst, was Puppet tut, aber die Frage, ob Puppet ein Home-Verzeichnis verwaltet, ist keine angeborene Eigenschaft des Benutzerkontos."

In unserem Beispiel ist die Eigenschaft der Wert des Konfigurationseinstellungen, während der Parameter die Anwendungsattribute angibt.

Provider-Implementierungen

Provider definieren die Mechanismen zur Verwaltung des Zustands der durch Typen beschriebenen Ressourcen. Sie behandeln:

Bestimmung, ob die Ressource bereits existiert
Erstellen oder Entfernen von Ressourcen.
Ändern von Ressourcen.
Optional das Auflisten aller vorhandenen Ressourcen des Typs.

Typen und Provider in Modulen

Benutzerdefinierte Typen und Provider werden im Verzeichnis lib/puppet eines Moduls platziert.

Die Typdatei befindet sich in lib/puppet/type und ist nach dem Ressourcentyp benannt (app_config.rb in diesem Fall).
Provider-Implementierungen gehen in das Verzeichnis lib/puppet/provider, in ein Unterverzeichnis, das nach dem Ressourcentyp benannt ist. Jeder Provider ist nach seiner Provider-Implementierung benannt (z.B. ruby.rb, cli.rb, cert.rb, token.rb, user.rb)

Beispiel:

Typ: app_config
Provider:
- cert
- token
- user

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

Typbeschreibung

Neue benutzerdefinierte Typen können mit zwei verschiedenen API-Versionen erstellt werden. APIv1 ist die alte, klassische Methode, die Getter und Setter innerhalb der Provider verwendet. APIv2 ist eine neue Implementierung, die in PDK integriert ist – diese Implementierung wird auch als Resource-API bezeichnet.

Im nächsten Abschnitt stellen wir die APIv1-Implementierung vor. Die Implementierung der Ressourcen-API wird später in diesem Dokument behandelt.

APIv1

Die traditionelle Methode verwendet Puppet::Type.newtype, die den Typ definiert. Es wird empfohlen, die Typdokumentation in den Code einzufügen. Dies ermöglicht es den Benutzern, puppet describe <type> auf ihrem System auszuführen, um die Dokumentation anzuzeigen.

# lib/puppet/type/app_config.rb
Puppet::Type.newtype(:app_config) do
  @doc = %q{Verwalten der Anwendungsconfig. Es gibt drei Möglichkeiten
    zur Authentifizierung: Zertifikat, Token, Benutzer. Zertifikat ist der Standard
    Provider.

    Beispiel:

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

Verwaltung

Die wichtigste Funktion eines Typs besteht darin, etwas zum System hinzuzufügen oder zu entfernen. Dies wird normalerweise mit der ensure-Eigenschaft behandelt. Um ensure zu aktivieren, ist eine einzige Zeile erforderlich: ensurable

# lib/puppet/type/app_config.rb
Puppet::Type.newtype(:app_config) do
  @doc = %q{Verwalten der Anwendungsconfig. Es gibt drei Möglichkeiten
    zur Authentifizierung: Zertifikat, Token, Benutzer. Zertifikat ist der Standard
    Provider.

    Beispiel:

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

Namevar

Bei der Deklaration des Typs muss ein Titel angegeben werden – dies könnte man als Typinstanz-Identifikator bezeichnen. In der Regel spiegelt dies wider, wofür der Typ verantwortlich ist.

user { 'betadots': # <- Titel
}

Die einfachste Implementierung besteht darin, einen Parameter mit dem Namen :name hinzuzufügen.

# lib/puppet/type/app_config.rb
Puppet::Type.newtype(:app_config) do
  @doc = %q{Verwalten der Anwendungsconfig. Es gibt drei Möglichkeiten,
    sich zu authentifizieren: Zertifikat, Token, Benutzer. Zertifikat ist der Standard
    Provider.

    Beispiel:

      app_config: { 'enable_logging':
        ensure   => present,
        value    => true,
      }
  }
  ensurable
  newparam(:name) do
    desc "Das Anwendungsconfig-Element, das verwaltet werden soll. Siehe app_cli conf --help"
  end
end

Das Übergeben des Schlüssels namevar: true an den Parameter ist eine weitere Möglichkeit, einen Namevar zu identifizieren:

newparam(:key, namevar: true) do
  desc 'Der Schlüssel des Anwendungsconfig-Elements, das verwaltet werden soll. Siehe app_cli conf --help'
end

Eigenschaften

Als Nächstes fügen wir die andere Eigenschaft hinzu. Jede Eigenschaft kann durch ihren Inhalt validiert werden. In unserem Demo-Fall erwarten wir einen Stringwert.

# lib/puppet/type/app_config.rb
Puppet::Type.newtype(:app_config) do
  @doc = %q{Verwalten der Anwendungsconfig. Es gibt drei Möglichkeiten,
    sich zu authentifizieren: Zertifikat, Token, Benutzer. Zertifikat ist der Standard
    Provider.

    Beispiel:

      app_config: { 'enable_logging':
        ensure   => present,
        value    => true,
      }
  }
  ensurable
  newparam(:name) do
    desc "Das Anwendungsconfig-Element, das verwaltet werden soll. Siehe app_cli conf --help"
  end
  newproperty(:value) do
    desc "Der zu setzende Konfigurationswert."
    validate do |value|
      unless value =~ /^\w+/
        raise ArgumentError, "%s ist kein gültiger Wert" % value
      end
    end
  end
end

Außerdem kann man spezifische gültige Werte angeben, die automatisch validiert werden:

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

Bitte beachten, dass Arrays als Eigenschaftswerte auf andere Weise validiert werden:

Von der Website Puppet benutzerdefinierte Typen:

Standardmäßig wird eine Eigenschaft, die mehrere Werte in einem Array zugewiesen bekommt:

Als synchron betrachtet, wenn einer dieser Werte dem aktuellen Wert entspricht.

Wenn keiner dieser Werte übereinstimmt, wird der erste Wert beim Synchronisieren der Eigenschaft verwendet.

Wenn alle Array-Werte übereinstimmen sollen, muss die Eigenschaft array_matching auf :all gesetzt werden. Der Standardwert ist :first.

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

Der Zugriff auf Werte kann auf zwei Arten erfolgen:

should für Eigenschaften, value für Parameter.
value für sowohl Eigenschaften als auch Parameter.

Wir bevorzugen die expliziten Methoden, da dies klarer macht, ob wir es mit einer Eigenschaft oder einem Parameter zu tun haben.

Parameter

Parameter werden auf ähnliche Weise definiert:

# lib/puppet/type/app_config.rb
Puppet::Type.newtype(:app_config) do
  @doc = %q{Verwalten der Anwendungsconfig. Es gibt drei Möglichkeiten,
    sich zu authentifizieren: Zertifikat, Token, Benutzer. Zertifikat ist der Standard
    Provider.

    Beispiel:

      app_config: { 'enable_logging':
        ensure   => present,
        value    => true,
        cli_args => ['-p'], # Persistenz
      }
  }
  ensurable
  newparam(:name) do
    desc "Das Anwendungsconfig-Element, das verwaltet werden soll. Siehe app_cli conf --help"
  end
  newproperty(:value) do
    desc "Der zu setzende Konfigurationswert."
    validate do |value|
      unless value =~ /^\w+/
        raise ArgumentError, "%s ist kein gültiger Wert" % value
      end
    end
  end
  newparam(:cli_args, :array_matching => :all) do
    desc "CLI-Optionen, die während der Befehlsausführung verwendet werden sollen."
    validate do |value|
      unless value.class == Array
        raise ArgumentError, "%s ist kein Array" % value
      end
    end
    defaultto ['-p']
  end
end

Boolean-Parameter

Parameter, die einen booleschen Wert erhalten, sollten auf andere Weise behandelt werden, um Codewiederholungen zu vermeiden.

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

Automatische Abhängigkeiten

Innerhalb des Typs können wir weiche Abhängigkeiten zwischen verschiedenen Typen angeben.

Beispiel: Das app_cli sollte einen Benutzer verwenden, der im System verfügbar sein muss.

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

Von nun an kann der neue benutzerdefinierte Typ bereits in Puppet DSL verwendet werden, der Compiler wird ein Katalog erstellen, aber der Agent wird einen Fehler produzieren, da es keine funktionalen Provider gibt.

Vorabprüfung auf der Agentenseite

Es ist möglich, dass der Agent zunächst einige Dinge überprüft, bevor der Katalog angewendet wird. Dafür kann die Methode :pre_run_check verwendet werden.

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

Merkmale

Bei der Verwendung mehrerer Provider (ähnlich der Ressourcenpakete) wollen wir sicherstellen, dass der Provider alle erforderlichen Implementierungen (Merkmale - Features) hat. Ein Typ kann ein Merkmal erfordern:

# lib/puppet/type/app_config.rb
Puppet::Type.newtype(:app_config) do
  @doc = %q{Verwalten der Anwendungsconfig. Es gibt drei Möglichkeiten,
    sich zu authentifizieren: Zertifikat, Token, Benutzer. Zertifikat ist der Standard
    Provider.

    Beispiel:

      app_config: { 'enable_logging':
        ensure   => present,
        value    => true,
        file     => '/opt/app/etc/app.cfg',
        cli_args => ['-p'], # Persistenz
      }
  }
  ensurable
  # globales Merkmal
  # feature :cli, "Das CLI-Merkmal erfordert einige Parameter", :methods => [:cli]
  newparam(:name) do
    desc "Das Anwendungsconfig-Element, das verwaltet werden soll. Siehe app_cli conf --help"
  end
  newproperty(:value) do
    desc "Der zu setzende Konfigurationswert."
    validate do |value|
      unless value =~ /^\w+/
        raise ArgumentError, "%s ist kein gültiger Wert" % value
      end
    end
  end
  # Die Eigenschaft config_file muss gesetzt werden, wenn die CLI
  #   Option zur Konfiguration von App verwendet wird.
  # Der CLI-Provider wird nach einem Merkmal suchen.
  newproperty(:file, :required_features => %w{cli}) do
    desc "Die zu verwendende Konfigurationsdatei."
    validate do |value|
      unless (File.expand_path(value) == value)
        raise ArgumentError, "%s ist kein absoluter Pfad" % value
      end
    end
    defaultto '/opt/app/etc/app.cfg'
  end
  newparam(:cli_args, :array_matching => :all) do
    desc "CLI-Optionen, die während der Befehlsausführung verwendet werden sollen."
    validate do |value|
      unless value.class == Array
        raise ArgumentError, "%s ist kein Array" % value
      end
    end
    defaultto ['-p']
  end
end

Provider-Implementierung

Sobald der Typ definiert ist, muss der Anbieter steuern, wie die Ressource verwaltet wird. Anbieter implementieren typischerweise Methoden, um:

Überprüfen, ob die Ressource existiert (exists?).
Eine neue Ressource erstellen (create).
Vorhandene Ressourcenattribute lesen (prefetch oder ein Getter).
Eine Ressource ändern (flush oder ein Setter).
Eine Ressource löschen (destroy).

# lib/puppet/provider/app_config/cli.rb
Puppet::Type.type(:app_config).provide(:cli) do
  desc "Der CLI-Anbieter des app_config-Typs."
end

Es ist auch möglich, bestehende Anbieterklassen wiederzuverwenden und zu erweitern. Gemeinsamer Code kann in einem generischen Anbieter (lib/puppet/provider/app_config.rb) platziert werden.

# lib/puppet/provider/app_config/cli.rb
Puppet::Type.type(:app_config).provide(:cli, :parent => Puppet::Provider::App_config) do
  desc "Der CLI-Anbieter des app_config-Typs verwendet gemeinsamen Code aus app_config.rb."
end

Wenn eine gemeinsame Funktionalität für mehrere Anbieter hinzugefügt werden soll, kann man den Code im Puppet_X-Modulverzeichnis ablegen: lib/puppet_x/<unternehmens_name>/<eindeutiger Klassenname>.

# lib/puppet/provider/app_config/cli.rb
require_relative '../../puppet_x/betadots/app_api.rb'
Puppet::Type.type(:app_config).provide(:cli) do
  desc "Der CLI-Anbieter des app_config-Typs verwendet gemeinsamen Code aus app_config.rb."
end

Ein neuer Anbieter kann erstellt werden, indem er von einem bestehenden Anbieter erbt und diesen erweitert:

# lib/puppet/provider/app_config/token.rb
Puppet::Type.type(:app_config).provide(:token, :parent => :api, :source => :api) do
  desc "Der Token-Anbieter des app_config-Typs ist eine Erweiterung des API-Anbieters."
end

Zusätzlich kann man jeden Anbieter von jedem Typ wiederverwenden:

# lib/puppet/provider/app_config/file.rb
Puppet::Type.type(:app_config).provide(:file, :parent => Puppet::Type.type(:ini_setting).provider(:ruby)) do
  desc "Der Datei-Anbieter des app_config-Typs ist eine Erweiterung des API-Anbieters."
end

Auswahl des Anbieters

Der Puppet-Agent muss wissen, welcher Anbieter zu verwenden ist, wenn mehrere Anbieter vorhanden sind. Man kann den provider-Meta-Parameter verwenden oder die Anbieter Überprüfungen durchführen lassen, um festzustellen, ob sie für das System gültig sind. Die Optionen umfassen:

Überprüfung	Beispiel	Beschreibung
Befehle	`commands :app => "/opt/app/bin/app.exe"`	Gültig, wenn der Befehl `/opt/app/bin/app.exe` existiert. Der Befehl kann später mit `:app` verwendet werden.
Einschränkung - existiert	`confine :exists => "/opt/app/etc/app.conf"`	Gültig, wenn die Datei existiert.
Einschränkung - bool	`confine :true => /^10\./.match(%x{/opt/app/bin/app.exec version})`	Gültig, wenn die Version 10.x ist.
Einschränkung - Fakt	`confine 'os.family' => :debian`	Gültig, wenn der Faktwert übereinstimmt.
Einschränkung - Funktion	`confine :feature => :cli`	Gültig, wenn der Anbieter die Funktion hat.
defaultfor	`defaultfor 'os.family' => :debian`	Anbieter als Standard für Debian-basierte Systeme.

Lesen und Anwenden von Konfigurationen

Der Anbieter benötigt die Fähigkeit, einzelne Konfigurationszustände zu erstellen, zu lesen, zu aktualisieren und zu löschen (CRUD-API).

Jede Konfigurationseigenschaft benötigt eine getter- (lesen) und eine setter- (ändern) Methode.

# lib/puppet/provider/app_config/cli.rb
#   app_config: { 'enable_logging':
#     ensure   => present,
#     value    => true,
#   }
#
Puppet::Type.type(:app_config).provide(:cli) do
  desc "Der CLI-Anbieter des app_config-Typs."

  # Einschränkung auf bestehenden Befehl
  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, 'Mehrere Konfigurationselemente gefunden, bitte beheben Sie dies'
    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

Es wird empfohlen, auch die instances-Klassenmethode zu erstellen, die alle Instanzen eines Ressourcentyps in einem Hash sammeln kann. Der Namevar ist der Hash-Schlüssel, der einen Hash von Parametern und Eigenschaften als Wert hat.

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

Manchmal ist es nicht möglich, alle Instanzen zu sammeln, z. B. beim file-Ressourcentyp. In solchen Fällen wird keine instance-Methode definiert.

Die instance-Methode wird indirekt von jedem Typ verwendet, wenn prefetch aufgerufen wird, um die aktuelle Konfiguration zu erhalten und die @property_hash-Instanzvariable zurückzugeben.

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

Dies ermöglicht es dem Typ, Getter und Setter zu verwenden, um die Instanzvariable zu lesen und zu manipulieren, anstatt für jeden Typ getter- und setter-Methoden zu schreiben. Dieses Verhalten wird durch die Deklaration der mk_resource_methods-Klassenmethode hinzugefügt.

Sobald dies implementiert ist, kann man den Befehl puppet resource app_config ausführen, um alle vorhandenen Konfigurationen abzurufen.

Refresh-Ereignisse

In einigen Fällen ist es erforderlich, eine Ressource zu aktualisieren (refresh), beispielsweise um einen Dienst neu zu starten, ein Laufwerk erneut zu mounten oder eine Exec-Ressource erneut auszuführen. Damit ein Typ/Anbieter auf ein Aktualisierungsereignis reagieren kann, ist eine spezielle Behandlung erforderlich.

Innerhalb des Typs muss die refreshable-Funktion aktiviert werden, und eine refresh-Definition wird hinzugefügt.

Die folgenden Beispiele stammen vom Puppet service Typ und Anbieter. Die Funktion beschreibt, welche Anbieterdefinition bei einem Aktualisierungsereignis ausgeführt werden soll.

# lib/puppet/type/services.rb
# ...
  feature :refreshable, "Der Anbieter kann den Dienst neu starten.",
    :methods => [:restart]
# ...
  def refresh
    # Nur neu starten, wenn wir tatsächlich laufen
    if (@parameters[:ensure] || newattr(:ensure)).retrieve == :running
      provider.restart
    else
      debug "Neustart überspringen; Dienst läuft nicht"
    end
  end
# ...

Verwendung benutzerdefinierter Typen in Puppet DSL

Sobald der benutzerdefinierte Typ und Anbieter implementiert sind, kann man diesen in Puppet Manifesten wie folgt verwenden:

# Typdeklaration
app_config { 'enable_logging':
  ensure    => present,
  value     => true,
  require   => File['/opt/app/etc/app.cfg'],
  subscribe => Service['app'],
}
# Typreferenz
service { 'app':
  ensure    => running,
  subscribe => App_config['enable_logging'],
}
# Typdeklaration mit Lambda und Splat-Operator
$config_hash.each |String $key, Hash $hash| {
  app_config { $key:
    * => $hash,
  }
}
# Virtuelle oder exportierte Ressource
@@app_config { 'app_mount':
  ensure => present,
  value  => "${facts['networking']['fqdn']}/srv/app_mount",
  tag    => 'blog',
}
# Ressourcen-Sammler
App_config <<| tag == 'blog' |>>

Resourcen-API

Die moderne Ressourcen-API hat eine Einschränkung: Man kann Typen nicht aktualisieren! Außerdem besteht sie aus Typen und Anbietern, die am selben Ort wie die bestehende Implementierung platziert werden müssen.

Ressourcen-API-Typ

Der Ressourcen-API-Typ verwendet einen Attributs-Hash, um alle Parameter und Eigenschaften aufzulisten. Innerhalb des type-Schlüssels kann man jeden der integrierten Puppet-Datentypen verwenden.

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

Puppet::ResourceApi.register_type(
  name: 'app_config',
  docs: <<-EOS,
      @summary Der Typ zur Verwaltung von App-Konfigurationseinstellungen
      @example
      app_config { 'key':
        ensure => present,
        value  => 'value',
      }

      Dieser Typ bietet Puppet die Möglichkeit, unsere Anwendungsconfig zu verwalten.
    EOS
  features: []
  attributes: {
    ensure: {
      type:    'Enum[present, absent]',
      desc:    'Ob die Einstellung hinzugefügt oder entfernt werden soll',
      default: 'present',
    },
    name: {
      type:     'String',
      desc:     'Die Einstellung, die verwaltet werden soll',
      behavior: :namevar,
    },
    value: {
      type: 'Variant[String, Integer, Array]',
      desc: 'Der Wert, der gesetzt werden soll'
    }
  }
)

Ressourcen-API-Anbieter

Die einfachste Lösung ist die Verwendung der Klasse SimpleProvider. Dieser Anbieter benötigt bis zu 4 Definitionen:

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: Alle lesbaren Konfigurationseinstellungen in einen Hash abrufen
  def get(context)
    context.debug('Gibt Daten vom Befehl zurück')

    @result = []
    stdout, stderr, status = Open3.capture3('/opt/app/bin/app.exe list')
    raise ParseError "Fehler beim Ausführen des Befehls: \n#{stderr}" unless status.success?
    # Fehlende Fehlerbehandlung. Dies dient nur zur 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: Eine neue Konfigurationseinstellung mit Name und Sollwert hinzufügen
  def create(context, name, should)
    context.notice("Erstelle '#{name}' mit #{should[:value]}")
    _stdout, _stderr, status = Open3.capture3("/opt/app/bin/app.exe set #{name} #{should[:value]}")
    # Fehlende Fehlerbehandlung. Dies dient nur zur Demo
    return true unless status.success?
  end

  # Update: Eine vorhandene Einstellung mit Namen korrigieren und durch den Sollwert ersetzen
  def update(context, name, should)
    context.notice("Aktualisiere '#{name}' mit #{should[:value]}")
    _stdout, _stderr, status = Open3.capture3("/opt/app/bin/app.exe set #{name} #{should[:value]}")
    # Fehlende Fehlerbehandlung. Dies dient nur zur Demo
    return true unless status.success?
  end

  # Delete: Eine Konfigurationseinstellung entfernen
  def delete(context, name)
    context.notice("Lösche '#{name}'")
    _stdout, _stderr, status = Open3.capture3("/opt/app/bin/app.exe rm #{name}")
    # Fehlende Fehlerbehandlung. Dies dient nur zur Demo
    return true unless status.success?
  end
end

Zusammenfassung

Typen und Anbieter sind nicht komplex. Sie beschreiben im Grunde das CRUD-Verhalten von Puppet. Der Typ definiert, wie man die Puppet DSL verwendet, während der Anbieter steuert, wie spezifische Einstellungen überprüft und behandelt werden.

Eine exzessive Nutzung der exec Resource ist zu vermweiden. In den meisten Fällen ermöglicht ein einfacher Typ und Anbieter eine bessere Analyse, Fehlerbehandlung und Kontrolle über das, was passiert. Darüber hinaus: benutzerdefinierte Typen und Anbieter führen schneller aus im Vergleich zur Verwendung des exec-Typs - viel schneller!

Die Beispielanwendung und die funktionierenden Typen und Anbieter aus diesem Posting sind auf GitHub verfügbar:

Die App: Workshop-Demo-App
Das Puppet-Modul mit Typen und Anbietern für die App: Workshop-Demo-Modul

App-Nutzung:

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

# Puppet-Modul installieren:
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

Viel Spaß beim Puppetisieren,

Martin

betadots: The Ruby side of Puppet - Part 2 - Custom Functions

2025-01-14T16:04:08+00:00

This is the second post in a series of three, covering the concepts and best practices for extending Puppet using custom facts, custom functions and custom types and providers.

Part 1 covers Custom Facts, which explain how a node can provide information to the Puppet Server.

Part 2 (this post) focuses on Custom Functions, demonstrating how to develop functions for data processing and execution.

Part 3 covers Custom Types and Providers, showing how to extend Puppet's DSL functionality.

Custom Functions in Puppet:

Functions in Puppet are executed on the Puppet server, specifically inside the compiler. These functions have access to all facts and Puppet variables, as long as they exist within the function’s namespace.

There are two main types of functions in Puppet:

Statement functions
Return value functions

Statement functions can interact with Puppet internals. The most common statement functions are include or contain, which add classes to the catalog, or noop and notice, which set all resources into simulation mode or print entries into the Puppet server log file.

Return value functions such as lookup or read_url, return values from Hiera or external sources like web servers.
Some return value functions can also manipulate data (each, filter, map, reduce).

Why Create Custom Functions?

Here are some reasons you might develop custom functions in Puppet:

Writing a custom Hiera lookup function
Converting data structures for specific needs

Content:

Function development
Functions in Modules
General API
Dispatcher and Define
Using functions in Puppet DSL
Summary

Function development

Since functions are executed only at compile time, it is advisable to first focus on their core functionality before integrating them with the Function API. This allows you to test the logic with local data, avoiding issues on the Puppet server that could break compilation or even crash the server.

For example, imagine you have a data structure that outlines various aspects of a system's configuration. Using a function, you can expose specific parts of this data structure as variables.

Example Data Structure:

server_hash:
  'postfix':
    'config':
      'transport': 'mta'
      'ssl': true
  'apache':
    'config':
      'vhost': 'server.domain.tld'
      'document_root': '/srv/www/html/server.domain.tld'
      'ssl': true
      'proxy_pass': 'http://localhost:8080'
  'tomcat':
    'config':
      'application': 'crm'
      'service': 'frontend'

Assume that this data structure comes from Hiera, and you want to allow other teams, who may write their own modules, to reuse this data without performing additional lookups. This would allow you to modify the data structure internally while still providing teams with the required information.

Example Function:

# test data
server_hash = {
  'postfix' => {
    'config' => {
      'transport' => 'mta',
      'ssl' => true
    }
  },
  'apache' => {
    'config' => {
      'vhost' => 'server.domain.tld',
      'document_root' => '/srv/www/html/server.domain.tld',
      'ssl' => true,
      'proxy_pass' => 'http://localhost:8080'
    }
  },
  'tomcat' => {
    'config' => {
      'application' => 'crm',
      'service' => 'frontend'
    }
  }
}
# function definition
def read_service_config(data, service)
  data[service]
end
# testing the function
puts read_service_config(server_hash, 'tomcat')

Functions in Modules

Puppet provides an API for creating custom functions. To ensure the Puppet agent can locate these functions, they must be placed in specific directories within a module.

Files inside the module's lib directory are synchronized across all agents. Note that it is not possible to limit which files are synchronized.

Custom functions can be added to one of two directory structures:

lib/puppet/parser/functions - Functions API v1
lib/puppet/functions - Functions API v2

The newer Functions API v2 supports subdirectories, allowing you to namespace your functions. The filename should match the function name.

In this post, we’ll focus on the modern API v2.

Example Directory Structure:

# <modulepath>/stdlib/
  \- lib/
    \- puppet/
      \- functions/
        \- stdlib/
          \- to_yaml.rb

# stdlib/lib/puppet/functions/stdlib/to_yaml.rb
Puppet::Functions.create_function(:'stdlib::to_yaml') do
  # ...
end

We recommend prefixing custom functions with the module name to avoid naming conflicts.

General API

To create custom functions in Puppet, use the following structure:

Example:

# <modulepath>/betadots/lib/puppet/functions/betadots/resolve.rb
Puppet::Functions.create_function(:'betadots::resolve') do
  # ...
end

Note that the namespace must be identical to the module name.

Dispatcher and Define

Within the do ... end of the function, you need to add a dispatcher. The dispatcher validates the input data and links it to a named definition, which executes the corresponding Ruby code.

The dispatcher can check data types using param and map values to Ruby symbols. The definition uses the dispatcher’s name and the parameters provided in the dispatcher.

The final command in the definition determines the return value.

Example Dispatcher for an IPv4 Address:

# <modulepath>/betadots/lib/puppet/functions/betadots/resolve.rb
Puppet::Functions.create_function(:'betadots::resolve') do
  dispatch :ip do
    param 'Regexp[/^(\d{1,3}).(\d{1,3}).(\d{1,3}).(\d{1,3})$/]', :ipaddr
  end
end

Here’s a table of common parameter methods used in dispatchers:

Method	Description
`param` or `required_param`	A mandatory argument. May occur multiple times. Position: All mandatory arguments must come first.
`optional_param`	An argument that can be omitted. You can use any number of these. When there are multiple optional arguments, users can only pass latter ones if they also provide values for the prior ones. This also applies to repeated arguments. Position: Must come after any required arguments.
`repeated_params` or `optional_repeated_params`	A repeatable argument, which can receive zero or more values. A signature can only use one repeatable argument. Position: Must come after any non-repeating arguments.
`required_repeated_param`	A repeatable argument, which must receive one or more values. A signature can only use one repeatable argument. Position: Must come after any non-repeating arguments.
`block_param` or `required_block_param`	A mandatory lambda (block of Puppet code). A signature can only use one block. Position: Must come after all other arguments.
`optional_block_param`	An optional lambda. A signature can only use one block. Position: Must come after all other arguments.

Adding a Definition:

Description	Dispatcher	Definition
Name	`dispatch :ip`	`def ip`
Parameter	`param ..., :ipaddr`	`def ip(ipaddr)`

# <modulepath>/betadots/lib/puppet/functions/betadots/resolve.rb
Puppet::Functions.create_function(:'betadots::resolve') do
  require 'resolv'
  dispatch :ip do
    param 'Regexp[/^(\d{1,3}).(\d{1,3}).(\d{1,3}).(\d{1,3})$/]', :ipaddr
  end

  def ip(ipaddr)
    Resolv.getname ipaddr
  end
end

Now additional dispatchers and definitions can be added:

# <modulepath>/betadots/lib/puppet/functions/betadots/resolve.rb
Puppet::Functions.create_function(:'betadots::resolve') do
  require 'socket'
  dispatch :ip do
    param 'Regexp[/^(\d{1,3}).(\d{1,3}).(\d{1,3}).(\d{1,3})$/]', :ipaddr
  end

  dispatch :dnsname do
    param 'Regexp[/.*/]', :dnsname
  end

  dispatch :local_hostname do
    param 'Regexp[//]', :local_hostname
  end

  def ip(ipaddr)
    Addrinfo.tcp(ipaddr, '80').getnameinfo[0]
  end

  def dnsname(dnsname)
    Addrinfo.ip(dnsname).getnameinfo[0]
  end

  def local_hostname
    Socket.gethostname
  end
end

Using functions in Puppet DSL

Within Puppet the functions usually gets executed during compile time.
A special case is the deferred function which gets executed on the agent.

Let's consider two use-cases:

using resolv function on the compiler
using resolv function on the agent

Use case 1: compiler execution

The function can be used anywhere in the code:

class betadots::resolver (
  Stdlib::Fqdn $local_hostname = betadots::resolve(),
) {
  $ip_from_google = betadots::resolve('www.google.com')
}

Use case 2: agent execution

The function must be declared to run in deferred mode in Puppet. Avoid using the function within the class header, as this could potentially overwrite the function call from hiera data.

class betadots::local_resolve (
) {
  $local_api_ip = Deferred('betadots::resolve', ['api.int.domain.tld'])
}

Summary

Puppet provides a stable API for creating custom functions.
Before creating a new function, check whether a solutions already exists in Stdlib- or Extlib-Module.

Remember to prefix your functions with your module name to avoid conflicts and help identify their origin.

Happy puppetizing,
Martin

betadots: Die Ruby-Seite von Puppet - Teil 2 - Benutzerdefinierte Funktionen

2025-01-14T16:01:03+00:00

Dies ist der zweite Beitrag einer dreiteiligen Serie, in der die Konzepte und Best Practices zum Erweitern von Puppet mithilfe von benutzerdefinierten Facts, benutzerdefinierten Funktionen und benutzerdefinierten Typen und Providern behandelt werden.

Teil 1 behandelt Benutzerdefinierte Facts, die erklären, wie ein Knoten Informationen an den Puppet-Server übermitteln kann.

Teil 2 (dieser Beitrag) konzentriert sich auf Benutzerdefinierte Funktionen und zeigt, wie man Funktionen für Datenverarbeitung und Ausführung entwickelt.

Teil 3 stellt dar, wie man die DSL-Funktionalität von Puppet mit neuen Typen und Provider erweitert.

Benutzerdefinierte Funktionen in Puppet:

Funktionen in Puppet werden auf dem Puppet-Server, insbesondere im Compiler, ausgeführt. Diese Funktionen haben Zugriff auf alle Facts und Puppet-Variablen, solange sie mit dem Namensraum angegeben werden.

Es gibt zwei Haupttypen von Funktionen in Puppet:

Anweisungsfunktionen
Rückgabefunktionen

Anweisungsfunktionen können mit den internen Mechanismen von Puppet interagieren. Die gebräuchlichsten Anweisungsfunktionen sind include und contain, die Klassen zum Katalog hinzufügen, oder noop und notice, die alle Ressourcen in den Simulationsmodus versetzen oder Einträge in die Protokolldatei des Puppet-Servers schreiben.

Rückgabefunktionen wie lookup oder read_url geben Werte aus Hiera oder externen Quellen wie Webservern zurück. Einige Rückgabefunktionen können auch Daten manipulieren (each, filter, map, reduce).

Warum benutzerdefinierte Funktionen erstellen?

Hier sind einige Gründe, warum man benutzerdefinierte Funktionen in Puppet entwickeln könnte:

Erstellen einer benutzerdefinierten Hiera-Suchfunktion
Umwandeln von Datenstrukturen für spezifische Anforderungen

Inhalt:

Funktion-Entwicklung
Funktionen in Modulen
Allgemeine API
Dispatcher und Definition
Verwendung von Funktionen in der Puppet-DSL
Zusammenfassung

Funktion-Entwicklung

Da Funktionen nur zur Kompilierzeit ausgeführt werden, empfiehlt es sich, sich zunächst auf ihre Kernfunktionalität zu konzentrieren, bevor sie in die Funktions-API integriert werden. Dadurch kann die Logik mit lokalen Daten getestet werden, ohne dass Probleme auf dem Puppet-Server auftreten, die die Kompilierung unterbrechen oder den Server sogar zum Absturz bringen könnten.

Als Beispiel wird eine Datenstruktur definiert, die verschiedene Aspekte der Konfiguration eines Systems darstellt. Mit einer Funktion kann man bestimmte Teile dieser Datenstruktur als Variablen verfügbar machen.

Beispiel für eine Datenstruktur:

server_hash:
  'postfix':
    'config':
      'transport': 'mta'
      'ssl': true
  'apache':
    'config':
      'vhost': 'server.domain.tld'
      'document_root': '/srv/www/html/server.domain.tld'
      'ssl': true
      'proxy_pass': 'http://localhost:8080'
  'tomcat':
    'config':
      'application': 'crm'
      'service': 'frontend'

Angenommen, diese Datenstruktur stammt aus Hiera, und man möchte anderen Teams, die ihre eigenen Module schreiben, die Wiederverwendung dieser Daten ohne zusätzliche Abfragen ermöglichen. Dadurch kann man die interne Datenstruktur ändern und die Funktion anpassen, während die Teams weiterhin die benötigten Informationen zur Verfügung gestellt bekommen.

Beispiel für eine Funktion:

# Test Daten
server_hash = {
  'postfix' => {
    'config' => {
      'transport' => 'mta',
      'ssl' => true
    }
  },
  'apache' => {
    'config' => {
      'vhost' => 'server.domain.tld',
      'document_root' => '/srv/www/html/server.domain.tld',
      'ssl' => true,
      'proxy_pass' => 'http://localhost:8080'
    }
  },
  'tomcat' => {
    'config' => {
      'application' => 'crm',
      'service' => 'frontend'
    }
  }
}
# Funktion definition
def read_service_config(data, service)
  data[service]
end
# Testen der Funktion
puts read_service_config(server_hash, 'tomcat')

Funktionen in Modulen

Puppet stellt eine API zum Erstellen benutzerdefinierter Funktionen zur Verfügung. Damit der Puppet Compiler diese Funktionen finden kann, müssen sie in bestimmten Verzeichnissen innerhalb eines Moduls abgelegt werden.

Dateien im lib-Verzeichnis des Moduls werden auf alle Agenten synchronisiert. Es ist nicht möglich, zu steuern, welche Dateien synchronisiert werden.

Benutzerdefinierte Funktionen können zu einer der beiden folgenden Verzeichnisstrukturen hinzugefügt werden:

lib/puppet/parser/functions - Funktionen API v1
lib/puppet/functions - Funktionen API v2

Die neuere Funktionen-API v2 unterstützt Unterverzeichnisse, sodass man Funktionen in Namespaces organisieren können. Der Dateiname sollte mit dem Funktionsnamen übereinstimmen.

In diesem Beitrag konzentrieren wir uns auf die moderne API v2.

Beispiel für eine Verzeichnisstruktur:

# <modulepath>/stdlib/
  \- lib/
    \- puppet/
      \- functions/
        \- stdlib/
          \- to_yaml.rb

# stdlib/lib/puppet/functions/stdlib/to_yaml.rb
Puppet::Functions.create_function(:'stdlib::to_yaml') do
  # ...
end

Wir empfehlen, benutzerdefinierte Funktionen mit dem Modulnamen zu präfixen, um Namenskonflikte zu vermeiden.

Allgemeine API

Um benutzerdefinierte Funktionen in Puppet zu erstellen, verwendet man die folgende Struktur:

Beispiel:

# <modulepath>/betadots/lib/puppet/functions/betadots/resolve.rb
Puppet::Functions.create_function(:'betadots::resolve') do
  # ...
end

Bitte beachten, dass der Funktions Namespace identisch zum Modulnamen (betadots) sein muss.

Dispatcher und Definition

Innerhalb des do ... end Blocks der Funktion muss ein Dispatcher und eine Definition hinzugefügt werden. Der Dispatcher validiert die Eingabedaten und verknüpft sie mit einer benannten Definition, die den entsprechenden Ruby-Code ausführt.

Der Dispatcher kann Datentypen mithilfe von param prüfen und Werte Ruby-Symbolen zuordnen. Die Definition verwendet den Namen des Dispatchers und die im Dispatcher bereitgestellten Parameter.

Der letzte Befehl in der Definition bestimmt den Rückgabewert.

Beispiel für einen Dispatcher für eine IPv4-Adresse:

# <modulepath>/betadots/lib/puppet/functions/betadots/resolve.rb
Puppet::Functions.create_function(:'betadots::resolve') do
  dispatch :ip do
    param 'Regexp[/^(\d{1,3}).(\d{1,3}).(\d{1,3}).(\d{1,3})$/]', :ipaddr
  end
end

Hier ist eine Tabelle mit gängigen Methoden für Parameter in Dispatchern:

Methode	Beschreibung
`param` oder `required_param`	Ein obligatorisches Argument. Kann mehrfach verwendet werden. Position: Alle Pflichtargumente müssen zuerst erscheinen.
`optional_param`	Ein Argument, das ausgelassen werden kann.
`repeated_params` oder `optional_repeated_params`	Ein wiederholbares Argument, das null oder mehr Werte annehmen kann.
`required_repeated_param`	Ein wiederholbares Argument, das einen oder mehr Werte annehmen muss.
`block_param` oder `required_block_param`	Ein obligatorisches Lambda.
`optional_block_param`	Ein optionales Lambda.

Hinzufügen einer Definition:

Beschreibung	Dispatcher	Definition
Name	`dispatch :ip`	`def ip`
Parameter	`param ..., :ipaddr`	`def ip(ipaddr)`

# <modulepath>/betadots/lib/puppet/functions/betadots/resolve.rb
Puppet::Functions.create_function(:'betadots::resolve') do
  require 'resolv'
  dispatch :ip do
    param 'Regexp[/^(\d{1,3}).(\d{1,3}).(\d{1,3}).(\d{1,3})$/]', :ipaddr
  end

  def ip(ipaddr)
    Resolv.getname ipaddr
  end
end

Nun können zusätzliche Dispatcher und Definitionen hinzugefügt werden:

# <modulepath>/betadots/lib/puppet/functions/betadots/resolve.rb
Puppet::Functions.create_function(:'betadots::resolve') do
  require 'socket'
  dispatch :ip do
    param 'Regexp[/^(\d{1,3}).(\d{1,3}).(\d{1,3}).(\d{1,3})$/]', :ipaddr
  end

  dispatch :dnsname do
    param 'Regexp[/.*/]', :dnsname
  end

  dispatch :local_hostname do
    param 'Regexp[//]', :local_hostname
  end

  def ip(ipaddr)
    Addrinfo.tcp(ipaddr, '80').getnameinfo[0]
  end

  def dnsname(dnsname)
    Addrinfo.ip(dnsname).getnameinfo[0]
  end

  def local_hostname
    Socket.gethostname
  end
end

Verwendung von Funktionen in der Puppet-DSL

Innerhalb von Puppet werden Funktionen in der Regel während der Kompilierzeit ausgeführt.
Eine besondere Ausnahme bildet die deferred function, die auf dem Agenten ausgeführt wird.

Im folgenden betrachten wir die zwei Anwendungsfälle:

Verwendung der resolve-Funktion im Compiler
Verwendung der resolve-Funktion auf dem Agenten

Anwendungsfall 1: Ausführung im Compiler

Die Funktion kann an beliebiger Stelle im Code verwendet werden:

class betadots::resolver (
  Stdlib::Fqdn $local_hostname = betadots::resolve(),
) {
  $ip_from_google = betadots::resolve('www.google.com')
}

Anwendungsfall 2: Ausführung auf dem Agenten

Die Funktion muss in deferred mode deklariert werden, um in Puppet auf dem Agenten ausgeführt zu werden. Die Funktion sollte nicht als Parameter im Header der Klasse verwendet werden, da dies möglicherweise den Funktionsaufruf mit hiera-Daten überschreiben könnte.

class betadots::local_resolve (
) {
  $local_api_ip = Deferred('betadots::resolve', ['api.int.domain.tld'])
}

Zusammenfassung

Puppet bietet eine stabile API zum Erstellen benutzerdefinierter Funktionen.
Bevor eine neue Funktion erstellt wird, bitte prüfen, ob bereits eine Lösung im Stdlib- oder Extlib-Modul vorhanden ist.

Funktionen sollten mit dem Modulnamen zu präfixen, um Konflikte zu vermeiden und deren Herkunft zu kennzeichnen.

Viel Erfolg beim Puppetisieren,
Martin

Overlook InfraTech: The strength of community

2025-01-08T00:00:00+00:00

Everything’s been super hectic with the holidays and so nobody noticed that I didn’t post the last two weeks, right? I joke, but not really. We’ve been super busy too and not just with the regular holiday stuff. In between the celebrations and glühwein, we’ve been working on community building.

As a community, we decided on the name for our new community maintained Puppet™️ fork and we decided that Vox Pupuli would adopt it. Now we’re busy creating the organization governance, porting all the repositories in, and setting up the pipelines and build tooling to streamline package publication. You’ll see a lot more information about things soon when everything’s done and we make the official announcement, but that’s a lot of work for a few weeks over the holidays when people are usually checked out!

Our biggest remaining challenge right now is determining release criteria that balances establishing our own brand presence against ecosystem safety all while respecting Perforce’s trademarks. I’m talking about agreeing on what names need to be changed before we can release packages and call them our own. I’m grateful for David, Jake, Sara, and others from Perforce who have given us loads of their own time to help us get to a resolution in everyone’s benefit.

This ability to pull together and work to find solutions, even over strong disagreements, is one of the indicators of a strong community. I’m confident that this spirit of collaboration is going to continue as we build the new Puppet™️ Language Steering Committee to guide our shared future. I’m quite excited for this steering committee because it’s got representatives from the entire community, even including Perforce itself. It’s the first time that community user needs sit at the same table as the business needs do without anyone having veto power over the other.

Being at the same table ensures that we don’t diverge too much and that we stay compatible and interoperable. These efforts, along with others like converging on acceptable compatibility names, will help ensure that the same Puppet™️ Forge works for all of us, that Vox Pupuli developer tools remain usable on Puppet Enterprise, that the PDK builds modules for whatever Puppet™️ implementation you happen to be running, and that our entire ecosystem remains collaborative and engaging regardless of where we work.

I’m kind of digging where we are. Some of it may have been born out of conflict and there were some hurt feelings all around. But being able to talk things over, share our needs, and work together to resolve them means that together we are a community and together we will build an ecosystem that’s stronger than it ever has been before.

betadots: Die Ruby-Seite von Puppet - Teil 1 - Benutzerdefinierte Fakten

2025-01-01T17:26:54+00:00

Dies ist der erste von drei Beiträgen, die die Konzepte und Best Practices zur Erweiterung von Puppet mit Hilfe von benutzerdefinierten Fakten, benutzerdefinierten Funktionen, benutzerdefinierten Typen und Providern behandeln.

Teil 1 (dieser Beitrag) erklärt benutzerdefinierte Fakten und wie ein Puppet Agent dem Puppet-Server Informationen bereitstellen kann.

Teil 2 konzentriert sich auf benutzerdefinierte Funktione und erläutert detailliert, wie Datenverarbeitungs- oder Ausführungsfunktionen entwickelt werden können.

Teil 3 deckt benutzerdefinierte Typen und Provider ab, die die Funktionalität der Puppet-DSL erweitern.

Benutzerdefinierte Fakten:

Es gibt mehrere Gründe, benutzerdefinierte Fakten zu entwickeln:

Wann immer ein VM-Namensschema verwendet wird, empfehlen wir, das Namensschema als benutzerdefinierten Fakt bereitzustellen.
Es ist manchmal erforderlich, den Zustand bestimmter Konfigurationen zu bestimmen oder ob bestimmte Software installiert ist.
Die Rechenzentrumsabteilung benötigt möglicherweise einen Überblick über die physische Hardware, Details zu den Hardwareanbietern und End-of-Life (EOL)-Supportdaten. Darüber hinaus kann die Finanzabteilung Informationen über die Anzahl der verwendeten kommerziellen Lizenzen und die Versionen der installierten Software benötigen.

Wann immer Informationen von einem Puppet Agenten benötigt werden, bietet Puppet die Möglichkeit, benutzerdefinierte Fakten zu implementieren.

Inhalt:

Faktenerstellung
Fakten in Modulen
Allgemeine API
Einschränkungen
Hilfsfunktionen
Zugriff auf andere Fakten
Rückgabewerte
Windows-Fakten
Weitere Konzepte
Codierungsstrategien und strukturierte Daten
Zusammenfassung

Faktenerstellung

Benutzerdefinierte Fakten können lokal auf einem Arbeitsplatz oder auf dem System entwickelt werden, auf dem der Fakt benötigt wird. Bevor der ungetestete Fakt in den Puppet-Code aufgenommen wird, kann der Faktladepfad auf zwei Arten angegeben und unabhängig gestestet werden.

Die folgende Verzeichnisstruktur wird verwendet:

ls ~/new_fact/
betadots_application_version.rb

Um den Fakt auszuführen, verwenden man einen der folgenden Befehle:

FACTERLIB=~/new_fact facter betadots_application_version
facter --custom-dir ~/new_fact betadots_application_version

Fakten in Modulen

Puppet stellt eine API zur Entwicklung benutzerdefinierter Fakten bereit. Um sicherzustellen, dass der Puppet-Agent sie findet, müssen benutzerdefinierte Fakten in einem bestimmten Verzeichnis innerhalb eines Moduls abgelegt werden.

Alle Dateien im lib-Verzeichnis von Modulen werden auf alle Agenten synchronisiert. Es ist nicht möglich, einzuschränken, welche Dateien synchronisiert werden.

Benutzerdefinierte Fakten sollten im Verzeichnis lib/facter eines Moduls abgelegt werden. Obwohl man einen beliebigen Dateinamen wählen kann, wird empfohlen, den Namen des Fakts als Dateinamen zu verwenden, um eine einfache Identifikation zu gewährleisten. Der Dateiname muss mit .rb enden.

Wir empfehlen außerdem, dem Namen des benutzerdefinierten Fakts einen Firmen- oder Abteilungspräfix hinzuzufügen.

Allgemeine API

Facter bietet eine API zum Erstellen neuer benutzerdefinierter Fakten.

Beispiel:

# ~/new_fact/betadots_application_version.rb
Facter.add(:betadots_application_version) do
  setcode do
    # Code hier
  end
end

Der Block setcode do ... end enthält den gesamten Ruby-Code für den Fakt. Das Ergebnis des letzten Befehls oder der letzten Variablen wird als Rückgabewert des Fakts verwendet.

Einschränkungen

Da alle benutzerdefinierten Fakten an alle Puppet-Agenten verteilt werden, ist es wichtig sicherzustellen, dass betriebssystem- oder anwendungsspezifische Fakten nur dort ausgeführt werden, wo es erforderlich ist.

Dies wird durch Einschränkungen (confining) erreicht.

Einschränkungen können auf einfache oder strukturierte Fakten oder auf anderen Ruby-Code wie File.exist? angewendet werden.

Einfache Fakt-Einschränkung:

# ~/new_fact/betadots_application_version.rb
Facter.add(:betadots_application_version) do
  confine kernel: 'Linux'

  setcode do
    # Code hier
  end
end

Einschränkung unter Verwendung eines Ruby-Blocks und Fakten:

# ~/new_fact/betadots_application_version.rb
Facter.add(:betadots_application_version) do
  confine 'os' do |os|
    os['family'] == 'RedHat'
  end

  setcode do
    # Code hier
  end
end

Einschränkung unter Verwendung eines Ruby-Blocks und Ruby-Code:

# ~/new_fact/betadots_application_version.rb
Facter.add(:betadots_application_version) do
  confine do
    File.exist?('/etc/sysconfig/application')
  end

  setcode do
    # Code hier
  end
end

Hilfsfunktionen

Facter bietet mehrere Hilfsmethoden, die verwendet werden können, ohne dass die Klasse facter erforderlich ist:

Hilfsfunktion	Beschreibung
`Facter::Core::Execution::execute`	Führt ein ausführbares Programm auf dem System mit einer Timeout-Option aus, um das Aufhängen von Facter-Läufen zu verhindern.
`Facter::Core::Execution::which`	Prüft, ob ein ausführbares Programm verfügbar ist. Funktioniert auf jedem unterstützten Betriebssystem und durchsucht die Standardpfade `ENV['PATH'] + ['/sbin', '/usr/sbin']`.
`Facter.value`	Bietet Zugriff auf den Wert eines anderen Fakts. Achtung! Loops vermeiden!

Weitere Informationen findet man in der API-Dokumentation.

Bitte beachten, dass Facter::Core::Execution::exec zugunsten von Facter::Core::Execution::execute veraltet ist. Dies ist wichtig, wenn man von älteren Versionen von Facter migriert.

Die timeout-Options-Hash kann auf zwei Arten festgelegt werden:

Gültig für den gesamten Fakt:

Facter.add('<name>', {timeout: 5}) do
  ...
end

Pro Ausführungsmethode:

Facter::Core::Execution::execute('<cmd>', options = {:timeout => 5})

Zum Beispiel, wenn eine Anwendung ihre Konfiguration über /opt/app/bin/app config zurückgibt, kann man ein Timeout von 5 Sekunden festlegen:

# ~/new_fact/betadots_application_version.rb
Facter.add(:betadots_application_version) do
  confine do
    File.exist?('/etc/sysconfig/application')
  end

  setcode do
    Facter::Core::Execution.execute('/opt/app/bin/app config', {:timeout => 5})
  end
end

Das Ergebnis des letzten Befehls oder die Angabe einer Variable wird als Faktenergebnis verwendet.

# ~/new_fact/betadots_application_version.rb
Facter.add(:betadots_application_version) do
  confine do
    File.exist?('/etc/sysconfig/application')
  end

  setcode do
    config_list = Facter::Core::Execution.execute('/opt/app/bin/app config', {:timeout => 5})
    config_list
  end
end

Zugriff auf andere Fakten

Es ist möglich, dass ein benutzerdefinierter Fakt den Wert eines anderen Fakts verwendet, indem er Facter.value verwendet. Dies sollte jedoch vorsichtig geschehen, um zyklische Abhängigkeiten zwischen Fakten zu vermeiden.

In unserem Beispiel hat die Anwendung unterschiedliche Konfigurationspfade für verschiedene Betriebssysteme.

RedHat - /etc/sysconfig/application
Debian - /etc/default/application

Beispiel mit Zugriff auf einen anderen Fakt:

# ~/new_fact/betadots_application_version.rb
Facter.add(:betadots_application_version) do
  confine do
    app_cfg_file = case Facter.value('os')['family']
                   when 'RedHat'
                     '/etc/sysconfig/application'
                   when 'Debian'
                     '/etc/default/application'
                   end

    File.exist?(app_cfg_file)
  end

  setcode do
    Facter::Core::Execution.execute('/opt/app/bin/app config')
  end
end

Das Beispiel ruft den os-Fakt ab und verwendet den family-Schlüssel, um das Betriebssystem zu vergleichen, und wendet dann eine Logik an, um zu bestimmen, welchen Anwendungskonfigurationspfad geprüft werden soll.

Rückgabewerte

Puppet erwartet, dass benutzerdefinierte Fakten einen gültigen Werttyp zurückgeben, insbesondere Strings, Ganze Zahlen oder Arrays.
Wenn der Wert eines Fakts nil oder undef ist, wird der Fakt einfach nicht definiert.

Windows-Fakten

Facter ist eine plattformübergreifende API und stellt die gleichen Funktionen auf allen Betriebssystemen bereit. Es ist jedoch wichtig zu beachten, dass Pfade und ausführbare Dateien in einer Windows-Umgebung unterschiedlich sein können.

Mit Hilfe des Facter::Core::Execution.execute werden üblicherweise Powershell Kommandos gestartet.

Das folgende Beispiel erstellt einen Windows-Fakt:

# ~/new_fact/windows_version.rb
Facter.add(:windows_version) do
  confine osfamily: 'windows'

  setcode do
    Facter::Core::Execution.execute('reg query "HKLM\Software\Microsoft\Internet Explorer" /v svcVersion', {:timeout => 5})
  end
end

Das Beispiel verwendet den reg query-Befehl, um die Version des Internet Explorers zu erhalten.

Bitte beachten, dass die Win32 API calls seit Ruby 1.9 deprecated sind.
Man kann statt dessen die Fiddle oder andere Ruby Bibliotheken nutzen.

Weitere Konzepte

Protokollierung

Zur Analyse eines Facts kann man auf die debug Methode zugreifen.

Facter.add(:betadots_application_version) do
  setcode do
    Facter.debug("Custom fact 'betadots_application_version' running")
    ...
  end
end

Es sind folgende Log Level möglich: debug, info, warn, error und fatal.

Aggregierung

Eine weitere Option ist das Zusammenstellen von Facts als Hash mit Hilfe von aggregates und chunks.
Jeder chunkbenötigt einen Namen (key) und einen Wert (value), wobei der Wert entweder ein Array oder ein Hash sein muss!

Nachdem Facter alle chunks eingelesen und validiert hat, werden diese aggregiert. Als default werden die Arrays oder Hashes gemerged.
Es besteht die Möglichkeit, eine eigene Aggregierungs Funktion zu schreiben.

Wir gehen davon aus, dass unsere Beispielanwendung es uns ermöglicht, Einstellungen auszulesen: /opt/app/bin/app config <key>.

# ~/new_fact/betadots_application_version.rb
Facter.add(:betadots_application_version, :type => :aggregate) do
  confine do
    app_cfg_file = case Facter.value('os')['family']
                   when 'RedHat'
                     '/etc/sysconfig/application'
                   when 'Debian'
                     '/etc/default/application'
                   end

    File.exist?(app_cfg_file)
  end

  chunk(:config_version) do
    {:version => Facter::Core::Execution.execute('/opt/app/bin/app config version')}
  end

  chunk(:config_cache_size) do
    {:cache_size => Facter::Core::Execution.execute('/opt/app/bin/app config cache_size')}
  end

  chunk(:config_log_level) do
    {:log_level => Facter::Core::Execution.execute('/opt/app/bin/app config log_level')}
  end
end

Ergebnis:

betadots_application_version => {
  version => '1.2.4',
  cache_size => '400M',
  log_level => 'info',
}

Gewichtung

Facter ermöglicht es, den Rückgabe Wert auf unterschiedliche Arten zu ermitteln. Die einzelnen Arten bekommen eine Gewichtung, damit Facter danach entscheiden kann, welche Art (Methode) vals Rückgabewert verwendet werden soll.

Wir gehen davon aus, dass unsere Besipielanwendung entweder über systemd oder über eine andere Art gestartet wurde (PID Datei).

Hinweis: Externe Fakten haben eine Gewichtung von 1000. Man kann externe Fakten überschreiben, indem man für den Custom Fakt den gleichen Namen verwendet und eine Gewichtung über 1000 hinterlegt.

Weitere Informationen findet man in der Fact precedence Sektion der Custom facts overview Seite.

Facter.add('application_running') do
  has_weight 100

  setcode do
    Facter::Core::Execution.execute('systemctl status app')
  end
end

Facter.add('application_running') do
  has_weight 50

  setcode do
    File.exist?('/var/run/application.pid')
  end
end

Blocking und Caching

Normalerweise werden Facts bei jedem Lauf eines Puppet Agenten erneut ermittelt. Dies kann bei manchen Facts dazu führen, dass Facter mehr Zeit benötigt, bis alle Facts geladen sind. Dies gilt insbesondere, wenn Facts eine Anwendung abfragen und diese Abfrage eine hohe Last erzeugt und lange dauert oder es gibt "teure" Facts, die gar nicht benötigt werden.
Facter ermöglicht es, einen Cache zu verwenden, so dass Facts nur einmalig und danch erst nach der Lebensdauer des Cache Objektes erneut abgefragt werden und man kann Blacklisten mit unerwünschen Facts pflegen.

Die Facter Konfiguration erfolgt in /etc/puppetlabs/facter/facter.conf auf *nix Systemen oder in C:\ProgramData\PuppetLabs\facter\etc\facter.conf auf Windows.
Bitte beachten, dass die Konfiguration auf dem Puppet Agent erfolgen muss!

# /etc/puppetlabs/facter/facter.conf
facts : {
  blocklist : [ "file system", "EC2", "processors.isa" ]
  ttls : [
    { "timezone": 30 days },
    { "my-fact-group": 30 days },
  ]
}
fact-groups : {
  my-fact-group : [ "os", "ssh.version"]
}

Innerhalb des Elementes blocklist kann man entweder einen Fact, ein Subelement eines Fact Hashes oder eine Facter Gruppe angeben.
Existierende Facter Gruppen kann man aus Facter auslesen:

Facter block groups

facter --list-block-groups
EC2
  - ec2_metadata
  - ec2_userdata
file system
  - mountpoints
  - filesystems
  - partitions
hypervisors
  - hypervisors

Facter cache groups

facter --list-cache-groups
EC2
  - ec2_metadata
  - ec2_userdata
GCE
  - gce
...

Außerdem kann man eigene Facter Gruppen innerhalb der facts-group Sektion hinterlegen.

Bitte beachten, dass das Dylan Ratcliffe's facter_cache Module seit Puppet 6 nicht mehr notwendig ist.

Mehr Informationen findet man auf der Puppet Webseite im Bereich facter.conf settings.

Codierungsstrategien und strukturierte Daten

Anzahl dr Fakten redizieren
Hashes verwenden
Generischer Code und Ruby Module

Wenn ein Fakt komplexe Daten zurückgeben muss, sollten strukturierte Daten verwendet werden, um hierarchische Informationen bereitzustellen. Weitere Informationen zur Strukturierung von Daten finden Sie in der Puppet-Dokumentation zu strukturierten Daten in benutzerdefinierten Fakten.

Eine bewährte Praxis besteht darin, sich für eine Struktur zu entscheiden, wenn ein Fakt mehr als eine einzelne Zeichenfolge zurückgeben soll. Solche Daten werden in der Regel in Hashes oder Arrays organisiert, die wahlweise direkt einen Hash liefern oder über aggregates zusammengesetzt werden:

Lösung 1: Hash in Ruby:

Facter.add(:betadots_file_check) do
  setcode do
    file_list = case Facter.value(:kernel)
                when 'windows'
                  [
                    'c:/Program Data/Application/bin/app',
                    'c:/backup/state.txt',
                  ]
                when 'Linux'
                  [
                    '/opt/app/bin/app',
                    '/etc/backup/state.txt',
                  ]
                end

    result = {}

    file_list.each |name| do
      result[name] = {
        :size => File.size(name),
        :world_writable => File.world_writable?(name)
      } if File.exist?(name)
    end

    result
  end
end

Facter Ergebnis:

{
  '/opt/app/bin/app' => {
    size => 64328,
    world_writable => null,
  },
  '/etc/backup/state.txt' => {
    size => 0,
    world_writable => 438,
  }
}

Lösung 2: Hashes mit Hilfe von aggregate:

Facter.add(:betadots_file_check, :type => :aggregate) do
  file_list = case Facter.value(:kernel)
              when 'windows'
                [
                  'c:/Program Data/Application/bin/app',
                  'c:/backup/state.txt',
                ]
              when 'Linux'
                [
                  '/opt/app/bin/app',
                  '/etc/backup/state.txt',
                ]
              end

  chunk(:file_size) do
    result = {}

    file_list.each |name| do
      result[name] = { :size => File.size(name) } if File.exist?(name)
    end

    result
  end

  chunk(:file_world_writable) do
    result = {}

    file_list.each |name| do
      result[name] = { :world_writable => File.world_writable?(name) } if File.exist?(name)
    end

    result
  end
end

Facter Ergebnis:

{
  '/opt/app/bin/app' => {
    size => 64328,
    world_writable => null,
  },
  '/etc/backup/state.txt' => {
    size => 0,
    world_writable => 438,
  }
}

Ein weiteres Facter Besipiel liest das Agent Zertifikat aus und liefert die Zertifikatserweiterungen als Fact Hash:

Facter.add(:betadots_cert_extension) do
  setcode do
    require 'openssl'
    require 'puppet'
    require 'puppet/ssl/oids'

    # set variables
    extension_hash = {}
    certdir = Puppet.settings[:certdir]
    certname = Puppet.settings[:certname]
    certificate_file = "#{certdir}/#{certname}.pem"

    # get puppet ssl oids
    oids = {}
    Puppet::SSL::Oids::PUPPET_OIDS.each do |o|
      oids[o[0]] = o[1]
    end

    # read the certificate
    cert = OpenSSL::X509::Certificate.new File.read certificate_file

    # cert extensions differs if we run via agent (numeric) or via facter (names)
    cert.extensions.each do |extension|
      case extension.oid.to_s
      when %r{^1\.3\.6\.1\.4\.1\.34380\.1\.1}
        short_name = oids[extension.oid]
        value = extension.value[2..-1]
        extension_hash[short_name] = value unless short_name == 'pp_preshared_key'
      when %r{^pp_}
        short_name = extension.oid
        value = extension.value[2..-1]
        extension_hash[short_name] = value unless short_name == 'pp_preshared_key'
      end
    end

    extension_hash
  end
end

Zusammenfassung

Dieser Beitrag hat die Grundlagen zur Erstellung von benutzerdefinierten Fakten in Puppet beschrieben. Benutzerdefinierte Fakten sind ein leistungsfähiges Werkzeug, um einem Puppet-Server oder einem Management-Tool Informationen zu liefern. Facts werden in Modulen hinterlegt und sollten bei Bedarf eingeschränkt (confine) werden. Die Rückgabewerte sollten als Hash oder Array und nur in seltenen Fällen als Bool, String oder Integer ausgegeben werden.

Ein letzter Hinweis: Nur lokale Kommandos ausführen! Wenn man Remote Systeme in Kombination mit Facter nutzen möchte, müssen diese Hochverfügbar und skaliert aufgebaut sein.

Happy puppetizing,
Martin

betadots: The Ruby side of Puppet - Part 1 - Custom Facts

2025-01-01T17:26:04+00:00

This is the first in a series of three posts covering the concepts and best practices for extending Puppet using custom facts, custom functions and custom types and providers.

Part 1 (this post) explains custom facts and how a node can provide information to the Puppet Server.

Part 2 focuses on custom functions, detailing how to develop data processing or execution functions.

Part 3 covers custom types and providers, extending Puppet DSL functionality.

Custom Facts:

There are several reasons to develop custom facts:

Whenever a VM naming model is used, we recommend providing the naming schema as a custom fact.
It is sometimes necessary to determine the state of certain configurations or whether specific software is installed.
The datacenter department may need an overview of physical hardware, hardware vendor details, and end-of-life (EOL) support dates. Additionally, the finance department may require information on the number of commercial licenses in use and the versions of installed software.

Whenever information from a node is needed, Puppet offers the option to deploy custom facts.

Content:

Fact Development
Facts in Modules
General API
Confining
Helpers
Accessing Other Facts
Return Values
Windows Facts
Additional Concepts
Coding Strategies and Structured Data
Summary

Fact Development

You can develop custom facts locally on a workstation or on the system where the fact is needed. Before adding the untested fact to your Puppet code, you can specify the fact load path in two ways.

The following directory structure is used:

ls ~/new_fact/
betadots_application_version.rb

To execute the fact, use one of the following commands:

FACTERLIB=~/new_fact facter betadots_application_version
facter --custom-dir ~/new_fact betadots_application_version

Facts in Modules

Puppet provides an API to develop custom facts. To ensure the Puppet agent finds them, custom facts must be placed in a specific directory within a module.

All files in the lib directory of modules are synchronized to all agents. It’s not possible to restrict which files are synchronized.

Custom facts should be placed in the lib/facter directory of a module. Although you can choose any filename, it's recommended to use the fact name as the filename for easy identification. The filename must end with .rb.

We also recommend prefixing the custom fact name with a company or department identifier.

General API

Facter provides an API to create new custom facts.

Example:

# ~/new_fact/betadots_application_version.rb
Facter.add(:betadots_application_version) do
  setcode do
    # Code here
  end
end

The setcode do ... end block contains all the Ruby code for the fact. The result of the last command or variable is used as the fact’s return value.

Confining

Since all custom facts are distributed to all Puppet agents, it’s essential to ensure that OS- or application-specific facts are only executed where necessary.

This is achieved by confining facts.

Confinement can be applied to simple or structured facts or any other Ruby code, such as File.exist?.

Simple fact confinement:

# ~/new_fact/betadots_application_version.rb
Facter.add(:betadots_application_version) do
  confine kernel: 'Linux'

  setcode do
    # Code here
  end
end

Confinement using Ruby block and facts:

# ~/new_fact/betadots_application_version.rb
Facter.add(:betadots_application_version) do
  confine 'os' do |os|
    os['family'] == 'RedHat'
  end

  setcode do
    # Code here
  end
end

Confinement using Ruby block and Ruby code:

# ~/new_fact/betadots_application_version.rb
Facter.add(:betadots_application_version) do
  confine do
    File.exist?('/etc/sysconfig/application')
  end

  setcode do
    # Code here
  end
end

Helpers

Facter provides several helper methods that can be used without requiring the facter class:

Helper	Description
`Facter::Core::Execution::execute`	Runs an executable on the system with a timeout option to prevent hanging facter runs.
`Facter::Core::Execution::which`	Checks if an executable is available. Works on any supported OS, searching the default paths `ENV['PATH'] + ['/sbin', '/usr/sbin']`
`Facter.value`	Provides access to the value of any other fact. Be careful to avoid loops!

More information is available in the API documentation.

Please note that Facter::Core::Execution::exec has been deprecated in favor of Facter::Core::Execution::execute. This is important when migrating from older versions of Facter.

The timeout options hash can be set in two ways:

Valid for the whole fact:

Facter.add('<name>', {timeout: 5}) do
  ...
end

Per execute method

Facter::Core::Execution::execute('<cmd>', options = {:timeout => 5})

For example, if an application returns its configuration via /opt/app/bin/app config, you can set a timeout of 5 seconds:

# ~/new_fact/betadots_application_version.rb
Facter.add(:betadots_application_version) do
  confine do
    File.exist?('/etc/sysconfig/application')
  end

  setcode do
    Facter::Core::Execution.execute('/opt/app/bin/app config', {:timeout => 5})
  end
end

The result of the last command or a variable with content is used as fact result.

# ~/new_fact/betadots_application_version.rb
Facter.add(:betadots_application_version) do
  confine do
    File.exist?('/etc/sysconfig/application')
  end

  setcode do
    config_list = Facter::Core::Execution.execute('/opt/app/bin/app config', {:timeout => 5})
    config_list
  end
end

Accessing Other Facts

It’s possible for a custom fact to leverage the value of another fact by using Facter.value.However, this should be done cautiously to avoid introducing cyclic dependencies between facts.

In our example the application has to different config paths for different OS.

RedHat - /etc/sysconfig/application
Debian - /etc/default/application

Example with access to another fact:

# ~/new_fact/betadots_application_version.rb
Facter.add(:betadots_application_version) do
  confine do
    app_cfg_file = case Facter.value('os')['family']
                   when 'RedHat'
                     '/etc/sysconfig/application'
                   when 'Debian'
                     '/etc/default/application'
                   end

    File.exist?(app_cfg_file)
  end

  setcode do
    Facter::Core::Execution.execute('/opt/app/bin/app config')
  end
end

The example retreives the os fact and uses the family key to compare the OS, then applies logic to determine which application config path to check for.

Return values

Puppet expects custom facts to return a valid value type, specifically strings, integers, booleans, or structured data (such as arrays and hashes). If the fact cannot determine a valid value, it should return nil or undef to indicate that no fact value is available.

Windows Facts

Windows-based systems support custom facts just like Linux or other Unix-like systems.
The main difference is that many Windows-specific tasks (such as checking installed software or reading from the registry)may require platform-specific Ruby code.

Within the Facter::Core::Execution.execute usually powershell commands is used.

Here's an example of a Windows custom fact that retrieves the version of Internet Explorer:

# ~/new_fact/betadots_internet_explorer_version.rb
Facter.add(:betadots_internet_explorer_version) do
  confine kernel: 'windows'

  setcode do
    Facter::Core::Execution.execute('reg query "HKLM\Software\Microsoft\Internet Explorer" /v svcVersion')
  end
end

In this example, we use the reg querycommand to check the Internet Explorer version in the Windows registry.

Please note that the Win32 API calls are deprecated since ruby 1.9.
Please consider using Fiddle or other Ruby-based libraries for interacting with the system.

Additional Concepts

Logging

It's often useful to include logging within custom facts to help with troubleshooting and development. You can log messages using Puppet's built-in logging mechanism:

Facter.add(:betadots_application_version) do
  setcode do
    Facter.debug("Custom fact 'betadots_application_version' running")
    ...
  end
end

Logging levels include debug, info, warn, error, and fatal.

Aggregates

Another option to create structured facts is the usage of chunks.
Each chunk must have a name and returns a data structure which must be of type array or hash.
After reading all chunks, the chunks will be aggregated. The default is to merge arrays or hashes.

It is possible to write a different aggregate definition.

We assume that our app can directly read config keys: /opt/app/bin/app config <key> returns the value.

# ~/new_fact/betadots_application_version.rb
Facter.add(:betadots_application_version, :type => :aggregate) do
  confine do
    app_cfg_file = case Facter.value('os')['family']
                   when 'RedHat'
                     '/etc/sysconfig/application'
                   when 'Debian'
                     '/etc/default/application'
                   end

    File.exist?(app_cfg_file)
  end

  chunk(:config_version) do
    {:version => Facter::Core::Execution.execute('/opt/app/bin/app config version')}
  end

  chunk(:config_cache_size) do
    {:cache_size => Facter::Core::Execution.execute('/opt/app/bin/app config cache_size')}
  end

  chunk(:config_log_level) do
    {:log_level => Facter::Core::Execution.execute('/opt/app/bin/app config log_level')}
  end
end

Result:

betadots_application_version => {
  version => '1.2.4',
  cache_size => '400M',
  log_level => 'info',
}

Weight

Facter offers the option to select a value based on priority of a fact.
Let's assume that an application is either started form systemd or in any other way (so it has a pid file).

Note: external facts have a built in weight value of 1000. Overriding external facts is possible by creating a fact with the same name and specifying a weight value over 1000.

More details can be found in the Fact precedence section of the Custom facts overview page.

Facter.add('application_running') do
  has_weight 100

  setcode do
    Facter::Core::Execution.execute('systemctl status app')
  end
end

Facter.add('application_running') do
  has_weight 50

  setcode do
    File.exist?('/var/run/application.pid')
  end
end

Blocking and Caching

By default, facts are recalculated each time they are queried. In certain scenarios, this might be inefficient, especially for computationally expensive facts or facts that rarely change. Facter offers a caching mechanism that allows you to persist fact values between Puppet runs.

Besides this some facts might be of no interest, but take long time to read.
In this case Facters blocklist can be used.

Configuration takes place in /etc/puppetlabs/facter/facter.conf on *nix systems or C:\ProgramData\PuppetLabs\facter\etc\facter.conf on Windows.
Please note that this configuratoin must be done on the Puppet agents!

# /etc/puppetlabs/facter/facter.conf
facts : {
  blocklist : [ "file system", "EC2", "processors.isa" ]
  ttls : [
    { "timezone": 30 days },
    { "my-fact-group": 30 days },
  ]
}
fact-groups : {
  my-fact-group : [ "os", "ssh.version"]
}

As you can see: within the blocklist we can mention the facts itself, a sub fact, or a fact group.
Existing facter groups can be read on the command line:

Facter block groups

facter --list-block-groups
EC2
  - ec2_metadata
  - ec2_userdata
file system
  - mountpoints
  - filesystems
  - partitions
hypervisors
  - hypervisors

Facter cache groups

facter --list-cache-groups
EC2
  - ec2_metadata
  - ec2_userdata
GCE
  - gce
...

Besides this we can add our own fact groups using the facts-group setting.

Please note that in the past people were using Dylan Ratcliffe's facter_cache Module. This is no longer needed as of Puppet 6, when the facter.conf settings were introduced.

The Puppet website provides more information on facter.conf settings.

Coding Strategies and Structured Data

Limit the total number of facts
Use data hashes
Generic code and Ruby modules

In more advanced cases, facts can return structured data, such as arrays or hashes. Structured facts allow for more complex data to be passed back to the Puppet server.

It is absolutely required to limit the total number of facts for a node. Main reason is the performance of PuppetDB.

Hashes or arrays can be built directly in Ruby code or via Facter aggregates.

e.g. We need the state of several files.

Solution 1: Hash in Ruby:

Facter.add(:betadots_file_check) do
  setcode do
    file_list = case Facter.value(:kernel)
                when 'windows'
                  [
                    'c:/Program Data/Application/bin/app',
                    'c:/backup/state.txt',
                  ]
                when 'Linux'
                  [
                    '/opt/app/bin/app',
                    '/etc/backup/state.txt',
                  ]
                end

    result = {}

    file_list.each |name| do
      result[name] = { 'size' => File.size(name), 'world_writable' => File.world_writable?(name) } if File.exist?(name)
    end

    result
  end
end

Will return:

{
  /opt/app/bin/app => {
    size => 64328,
    world_writable => null,
  },
  /etc/backup/state.txt => {
    size => 0,
    world_writable => 438,
  }
}

Solution 2: Hashes using aggregate:

Facter.add(:betadots_file_check, :type => :aggregate) do
  file_list = case Facter.value(:kernel)
              when 'windows'
                [
                  'c:/Program Data/Application/bin/app',
                  'c:/backup/state.txt',
                ]
              when 'Linux'
                [
                  '/opt/app/bin/app',
                  '/etc/backup/state.txt',
                ]
              end

  chunk(:file_size) do
    result = {}

    file_list.each |name| do
      result[name] = { :size => File.size(name) } if File.exist?(name)
    end

    result
  end

  chunk(:file_world_writable) do
    result = {}

    file_list.each |name| do
      result[name] = { :world_writable => File.world_writable?(name) } if File.exist?(name)
    end

    result
  end
end

Will return:

{
  /opt/app/bin/app => {
    size => 64328,
    world_writable => null,
  },
  /etc/backup/state.txt => {
    size => 0,
    world_writable => 438,
  }
}

Another example reads the Puppet agent certificate and provides the certificate extensions as a Facter hash:

Facter.add(:betadots_cert_extension) do
  setcode do
    require 'openssl'
    require 'puppet'
    require 'puppet/ssl/oids'

    # set variables
    extension_hash = {}
    certdir = Puppet.settings[:certdir]
    certname = Puppet.settings[:certname]
    certificate_file = "#{certdir}/#{certname}.pem"

    # get puppet ssl oids
    oids = {}
    Puppet::SSL::Oids::PUPPET_OIDS.each do |o|
      oids[o[0]] = o[1]
    end

    # read the certificate
    cert = OpenSSL::X509::Certificate.new File.read certificate_file

    # cert extensions differs if we run via agent (numeric) or via facter (names)
    cert.extensions.each do |extension|
      case extension.oid.to_s
      when %r{^1\.3\.6\.1\.4\.1\.34380\.1\.1}
        short_name = oids[extension.oid]
        value = extension.value[2..-1]
        extension_hash[short_name] = value unless short_name == 'pp_preshared_key'
      when %r{^pp_}
        short_name = extension.oid
        value = extension.value[2..-1]
        extension_hash[short_name] = value unless short_name == 'pp_preshared_key'
      end
    end

    extension_hash
  end
end

Summary

Custom facts are a powerful way to extend Puppet’s built-in facts with your organization’s specific information. Whether you’re retrieving application versions, monitoring system configuration, or providing custom details for a specific environment, custom facts help ensure that Puppet has the right data to apply the correct configuration.

In this post, we’ve covered the basics of custom fact development, including:

How to create custom facts in a local environment or as part of a module.
The API for creating and confining facts.
Accessing other facts and helper methods to enhance fact functionality.
Returning structured data for complex requirements.

One more advise: Run local commands only! If connections to remote systems are required you must ensure scalability and high availability.

Happy puppetizing,
Martin

Overlook InfraTech: Letting go of control

2024-12-19T00:00:00+00:00

Events of the last week have me thinking about something that’s true in a lot of contexts. A lot of people like to have control of a relationship; control of a situation; control of the message; or in this case, control of a community. I get it, realizing that you don’t have control can be unsettling. But in reality, not having control is the natural order of things and you’ll have a much better time of it once you realize that.

Let’s dive in. A controlling relationship is an easy start to the conversation, since most of us have either been in one or have witnessed one. We may have even been the offender; it’s very easy to accidentally fall into this role under certain circumstances. A relationship controller is quite often someone who’s terrified that the other(s) will leave or hurt them and so they tighten their grip more and more and more trying to prevent this. We all know the usual outcome; that grip becomes so tight that it forces an escape. The inability to let go of control leads to exactly the outcome that was most feared to begin with.

The same thing happens when one tries too hard to control a message. I don’t have to explain it to you. Google the Barbra Streisand effect for that.

As a seasoned community leader, I’m most interested in the context of community engagement. And in particular, technical open source communities centered around a product ecosystem — although this fundamentally applies to other community types as well. See, a lot of Product communities have a power imbalance at their very core. If the company can gatekeep merges, and packaging, and releases — then they have an outsized say in where the product goes. If they don’t want to invest in supporting Apple Silicon, it ain’t gonna happen even if community members volunteer to do the work.

Many companies mistake this imbalance as having control, even to the point of treating community members as if they were unpaid employees. I’ll give you a personal example of that. For most of our history, Puppet had an excellent community relationship because we remembered that we built ourselves off of their passion. As money got tight, some of the niceties got strained and some of the technical engagement started lagging. But we always treated them with respect and supported them as they grew and evolved the community. When they created Vox Pupuli, we celebrated and we never stopped celebrating it. Just before the pandemic did us in, a large part of what turned out to be Puppet’s final PuppetConf/Puppetize keynote centered Vox Pupuli as the independent community group that our success hinged on.

This changed rapidly after the Perforce acquisition. The community started being treated as liabilities and resources. At one point, the VP of Product at the time insisted on holding a community Zoom call the very next day or two to get feedback on some ideas he had. He said, “of course they’ll do it. They want to have input on what we sell!”

I’m sure they do. I collect feedback like that all the time. But community members who are freely giving their time for something they enjoy in a space where they feel welcomed and valued do not want to feel obligated to do so! That’s called a job and you collect a paycheck for it.

He didn’t understand when I tried to explain that he didn’t control them. They weren’t employees and he couldn’t expect them to prioritize his demands. He almost fired me when I refused.

Most companies in this position don’t understand how fragile and tenuous this power imbalance is. It only lasts so long as you own the roadmap and people still care enough to put up with your bullshit. As soon as the frustrations community feels about your behavior outweighs the work it is to just take on the roadmap themselves, then this power imbalance evaporates in an instant. And it’s generally irreversible because you’ve already tipped your hand as to how you’ll behave when you feel like you have the advantage. Your voice is no longer welcomed.

⚠️ A Product company never has control over their open source user community. They only have an illusion of it and by the time they realize this, it’s generally too late to recover.

To build a healthier community, they should be actively relinquishing control and cultivating influence instead. They will get very similar results, they just have to be more patient, honest, open, transparent,… You know, all the things that make a relationship work.

When you realize that you have zero control but as much influence as you are willing to develop, then you start behaving in ways that build a strong, loyal, and supportive community that will help see you through your missteps and always make sure that you have a seat at the table when decisions are being made.

You don’t lie to your community. You don’t always have to tell every single detail, and you can always couch things in softer terms or provide context. But you never lie.
You don’t make empty promises or excuses. You’re clear about what you can or can’t do.
You actively listen to their feedback and you care about it. In specific, you hear the pain that they have more than the words they use or the solutions they offer. You never “empty listen” and then throw it in the trash.
You take action on that feedback if warranted, but you’re always clear what should be expected.
You get really good at hearing what community wants and getting there before they have to ask for it. This gives you more influence in the growth patterns, just like cultivating a garden.
You participate in the day-to-day of the community and get to know what people value.
You are a role model, not a dictator.
You remind rather than enforce. In all the years I participated in and then managed the Puppet community, I rarely had to moderate users more than reminding them of the code of conduct.
You meet community where they are and where they want to be. You help them build a better table rather than insisting that they sit at yours.

In short, listen more than you proclaim, realize the value of your community members and never take them for granted, and help them build the space that they want — where they can feel welcome, accepted, and valued. Connect with people in a human way, rather than as a corporation using carefully crafted corporate doublespeak.

And let go of this anxiety-driven idea of control. You never had it anyways, and influence is far more valuable. Influence helps you build a lasting community and solid open source project in which you have a respected seat at the table.

Overlook InfraTech: Contributions of ‘Ghost Engineers’

2024-12-05T00:00:00+00:00

Last week was Thanksgiving for the USA and while I don’t personally celebrate the holiday or the violent colonization it represents, it does encourage me to reflect back on some of the things I’m most thankful for. Once again, you won’t be surprised to hear that it’s people. Coworkers, friends, community members, industry professionals that I learn from and am inspired by every day. People that I’m lucky enough to collaborate with, which probably includes many of you reading this. People in my communities are what I’m thankful for.

Collaboration is one of the things that I’ve been thinking about a lot over the last few months while getting this fun little venture off the ground. I think that most companies don’t prioritize collaboration as much as they should and I want to avoid that trap. And I’m definitely thinking about macro business decisions like why did Puppet, inc. invest so much time and resources into building an orchestration tool from scratch instead of integrating with one of the many existing options, even Ansible itself?

🔆 But even more, I’m thinking about micro level choices, because I think those are how you define yourself as a people and then that culture bubbles up into how your business runs, from top to bottom.

Many of you know that I’ve been involved in the roller derby world for a very long time. My partner has been a founding member of several teams and we are in the home of one of the premiere leagues in the world. One of the things that continues to draw me to the sport is their sense of community. The big dollars haven’t invaded yet and so they’re just there to have fun. They’ll beat each other up on the track and then share an afterparty. When a bout concludes, the audience will rush to circle the track because every single player will high-five every single fan who wants it. Then if you pay attention, there’s a ceremony in which the teams give gifts to each other and award several MVP awards to the other team. It’s worth pointing out that these awards don’t go to the player scoring the most points or other easily trackable stats. They almost always go to the players who are the best at holding their team together into a formidable force as observed by the people playing against them.

Recently, someone at Stanford who apparently knows very little about teamwork published a study that claimed to reveal that almost 10% of all software engineers were lazy and ineffective and didn’t contribute anything to the bottom line. Their rationale for this proclamation was they contributed few or no lines of code and the author deemed them “ghost engineers.” 🤨

A lot of people more qualified than I explained how LOC is maybe the least useful metric possible so I won’t go there. Instead, I want to look at it more holistically. This is a symptom of the bleed ‘em dry stack-ranking mentality that wants an easily measured metric so that toxic companies can reward those on top and punish those on the bottom in the misguided idea that it will improve performance and help the company hit revenue targets. Of course, trivially measured and manipulated metrics like this have nothing to do with the success of your company. If I have a choice between doing something to benefit the business or something that will get me a raise, what do you think I’m going to pick?

The other day, Mekka Okereke posted a sports metric that I’d never heard of and it’s super intriguing. We’ve all heard of the stats like points scored, number of rebounds or blocks or assists. But he talks about a new metric that makes me think about those roller derby MVP awards. It’s called the plus-minus and seems to be a simple comparison of how well your team does when you’re on the court vs. how it does when you’re not playing. 🤯

Huh. I can see parallels in tech…. He goes on to say that

Post by @mekkaokereke@hachyderm.io

View on Mastodon

This resonates so much with me. I’ve always worked towards being this person, and I’ve always really valued others with this mindset. It’s a shame that it’s so rare, but again, tech companies rarely incentivize it.

But that brings me to the actual point of this ramble. The more we micro-optimize and track things like lines of code, or commits, or tickets closed, or time on the clock, or even story points, the more we lose track of the bigger shared company success goal. And the more we incentivize people to game the system. It’s easy to write more lines of code or chop up work into a million tickets and commits. It’s much harder to enable actual value.

I don’t know the answer. Not yet. And maybe I never will; this is a challenge people have been grappling with for ages and in a backwards sort of way, it’s why we have the terrible metrics we do today. But I do know that the answer is based on building a culture of shared team success rather than on myopically focusing on individual metrics. Because these “ghost engineers” are the biggest contributors to our actual success and it’s about damn time they get some MVP awards of their own. And recognition and compensation to match.

Planet Puppet

Example 42: Ansible vs Puppet: Choose the Operating Model, Not the Syntax

Example 42: Puppet 7 to Puppet 8 Migration Guide

betadots: DevConf Tag 2

glibc-Workshop

Podman-Quadlets Workshop

betadots: DevConf: Tag 1

betadots: OpenVox rootless Alpine Containers

The PRs

How I got there

Rootless containers in detail 🥷🐳

Community powered Open Source ❤️

Why this matters

What’s next?

betadots: puppet-checkmk dusted off 🧹🦊

betadots: puppet-checkmk entstaubt 🧹🦊

Example 42: First Steps in the Swamp

Example 42: Reading the Swamp

Example 42: Hands in the Swamp

Puppet Blog: สล็อตวัวโชคลาภ UFABET ทางเข้าเล่นเว็บตรง PG Soft แตกง่าย 2026

ทำไมต้องเลือกเล่น สล็อตวัวโชคลาภ UFABET เว็บตรงไม่ผ่านเอเย่นต์

เจาะลึกกติกาการเล่น สล็อตวัวโชคลาภ UFABET อ้างอิงจากระบบจริง

รูปแบบเพลา 3-4-3 และเส้นไลน์เดิมพัน 10 แบบที่ควรรู้

สัญลักษณ์พิเศษ Wild และอัตราการจ่ายเงินรางวัลสูงสุด 2,000x

ฟีเจอร์เด็ดวัวแห่งโชคลาภตัวคูณ x10 ทำกำไรมหาศาล

เงื่อนไขการสุ่มเกิดฟีเจอร์หมุนซ้ำจนกว่าจะชนะรางวัล

วิธีรับโบนัสคูณ 10 เมื่อสัญลักษณ์เต็มหน้าจอ

ตารางสรุปข้อมูลทางเทคนิคของเกม สล็อตวัวโชคลาภ UFABET

คู่มือการใช้งานปุ่มควบคุมบนมือถือและคอมพิวเตอร์

สรุปความน่าเชื่อถือและเทคนิคการเล่นให้ได้เงินจริง

Overlook InfraTech: May The Source Be With You

Example 42: Pabawi Version One released

betadots: Puppet Enterprise - Neue Releases und Upgrade Zyklen

Latest

Latest-1

aktuelles LTS Releases

Releases und Support Zeitraum

Zusammenfassung

Puppet Blog: กาสิโน UFABET ศูนย์รวมเกมเดิมพันออนไลน์ครบวงจร มาตรฐานระดับโลก

สัมผัสประสบการณ์ กาสิโน ออนไลน์ที่เหนือระดับกับ UFABET

จุดเด่นที่ทำให้ กาสิโน ของเราเป็นอันดับ 1 ในใจนักเดิมพัน

ระบบความปลอดภัยและการเงินที่มั่นใจได้ 100%

FAQ: รวมสิ่งที่ควรรู้ก่อนเริ่มต้นเดิมพัน กาสิโน ออนไลน์

บทสรุป: ก้าวเข้าสู่โลกแห่งความบันเทิงที่ กาสิโน UFABET วันนี้

Laurent Domb Blog: Directing AI, Not Chasing It: Why Your SDLC and PDLC Must Evolve

The Paradox: AI Makes Us Frantic, Not Fast

Directing vs. Chasing: The Divide That Explains Everything

The Solutions Architect: Natural Director

The Software Developer: Most Vulnerable to Chasing

The Product Manager: Chasing in Disguise

Why the Traditional SDLC and PDLC Can’t Handle This

The Validation Crisis Underneath

The AI-Era SDLC

The AI-Era PDLC

The Unified Pipeline: Three Altitudes of Direction

Six Organizational Imperatives

The Bottom Line

betadots: 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 Blog: ไฮโล UFABET แทงไฮโลออนไลน์พื้นบ้าน อัตราจ่ายสูง จบไว ได้เงินจริง

สนุกกับ ไฮโล ออนไลน์ที่ UFABET แตกต่างจากที่อื่นอย่างไร?

วิธีการเล่น ไฮโล เบื้องต้นและการทำกำไรจากตัวเลข

ข้อดีของการเล่น ไฮโล ผ่านระบบคาสิโนสด

FAQ: รวมคำถามที่พบบ่อยสำหรับนักเดิมพัน ไฮโล

บทสรุป: สัมผัสความมันส์ระดับตำนานไปกับ ไฮโล UFABET

Puppet Blog: บาคาร่า UFABET เว็บตรงอันดับ 1 รวมค่ายดัง เล่นง่าย ถอนได้จริง

ทำไมต้องเล่น บาคาร่า กับ UFABET? ประสบการณ์ที่เหนือกว่าใคร

จุดเด่นของเกม บาคาร่า ออนไลน์: สนุก ลุ้นระทึก ทุกวินาที

เทคนิคการเล่น บาคาร่า เบื้องต้นสำหรับมือใหม่

FAQ: รวมคำถามที่พบบ่อยเกี่ยวกับ บาคาร่า ออนไลน์

บทสรุป: มั่นใจทุกการวางเดิมพัน บาคาร่า ไปกับ UFABET

Authentication: `RENOVATE_TOKEN`