OpenVox 9.0 is here 🎉 Edit

Published on Oct 2, 2026 by silug.

We have just shipped OpenVox 9.0.0! This is a platform catch-up, meaning that it updates all core dependencies to actively maintained versions. If you’ve been watching the recent flood of CVEs nervously, this release is just for you.

OpenVox 9 includes openvox-agent and openvoxdb 9.0.0 and openvox-server 9.0.1, along with openfact 6.2.1. (The first openvox-server release is 9.0.1 because the 9.0.0 version number was already taken by an artifact published to Clojars by mistake during the beta.) It also clears out a batch of long-deprecated code, as we proposed back in April. New features are planned for 10.x.

Release notes and documentation

The full release notes, including bug fixes and the changes in each pre-release, are here:

The OpenVox 9 documentation is here:

Getting OpenVox 9

OpenVox 9 packages are published to separate openvox9 repositories. To configure these repositories, install the openvox9-release package from:

Packages for macOS and Windows can be found at:

If you have been testing the betas or release candidates, a normal package upgrade will take you to the final release. Pre-releases used a tilde in their version (e.g. 9.0.0~rc4) so that they sort below the final release.

OpenVox 8 remains available on the openvox8 repositories. It will continue to receive high-priority and security fixes for at least six months. OpenVox 8 agents can keep running against OpenVox 9 servers while you upgrade your fleet. You don’t have to upgrade all at once.

Headline changes compared to OpenVox 8

  • openvox-agent now bundles Ruby 4.0 (up from Ruby 3.2) and OpenSSL 3.5 LTS.
  • openvox-server now uses JRuby 10.1, which is compatible with Ruby 4.0. This is an upgrade from JRuby 9.4, which was compatible with Ruby 3.1.
  • openvox-server and openvoxdb are officially supported and tested on Java 21 and 25, and support for Java 17 has been dropped. The packages run on Java 25 where the platform provides it, and on Java 21 otherwise. The FIPS packages run on Java 21 only, because the Bouncy Castle FIPS libraries are certified only up to Java 21.
  • openvoxdb is now tested against PostgreSQL 15, 16, and 18.
  • openvox-agent ships openfact 6, which removes the ldapname fact option and adds deprecation warnings ahead of removals in OpenVox 10.

Before you upgrade

This is a major release with breaking changes. Please read the release notes in full, but these are the ones most likely to affect you:

  • server no longer defaults to puppet. Agents must set server, server_list, or use SRV records (ca_server and report_server also work for their own services). An agent running as root with none of these set will fail with an error.
  • The reports setting now defaults to none instead of store. Set reports = store on your servers if you rely on reports being written to disk.
  • Filebucket reads are restricted. Agents can still back files up to a central filebucket, but reading bucket contents now requires a certificate with the pp_cli_auth extension. The rule lives in the packaged auth.conf: if yours is edited or managed by a module, the upgrade keeps your copy (the new one lands beside it as auth.conf.rpmnew or auth.conf.dpkg-dist) and the old rule stays in effect until you merge the change.
  • file { content => '<string that looks like a checksum>' } is now literal. Content that looks like a checksum is no longer used to fetch a file from the filebucket. Use static catalogs or an explicit source instead.
  • Hiera 3-era data bindings are gone. The data_binding_terminus and environment_data_provider settings and the Hiera 3 indirector terminus have been removed; Hiera 5 is the supported path.
  • Several deprecated interfaces have been removed: --configprint (use puppet config print), the pluginsync setting, the ignored fifth argument to regsubst(), the PAL evaluate_script_string/evaluate_script_manifest APIs, the pe_serverversion fact, and the vendored zone_core module.
  • Ruby 4’s net/http no longer adds a default Content-Type header. If you maintain a custom report processor or other code that POSTs data with net/http, set Content-Type explicitly.
  • Java 21 is now required. Upgrade server and database packages fully with apt, dnf, or zypper so that the new Java packages are pulled in. Afterwards, check update-alternatives --display java to make sure /usr/bin/java points at version 21 or newer. If the services start under Java 17, they will crash early with a ClassNotFoundException for java.util.SequencedCollection.

Known issues

Agent daemon can occasionally hang on “applying configuration”

A small number of users have seen the puppet agent daemon stop checking in, leaving a forked puppet agent: applying configuration process that never exits (openvox#485). It is rare: the reports so far come from small single-vCPU Linux VMs, where it happened every few days.

The cause is a rare race between Ruby’s background DNS lookup threads (which changed in Ruby 3.3 and 3.4) and the fork that starts each agent run. If the fork lands at the wrong moment, the child inherits a locked glibc resolver lock, and every name lookup in that child blocks. OpenVox 8 (Ruby 3.2) is not affected.

OpenVox 9.0.0 includes several changes that make this much less likely, and ensure the daemon recovers on its own if it does happen:

  • The agent no longer does name lookups in the daemon right before forking a run (openvox#683), which removes the trigger seen in the reports.
  • A run that outlives runtimeout is now killed, so the daemon carries on with the next run (openvox#642, openvox#643).
  • openfact bounds the fqdn lookup in its hostname resolvers (openfact#177).

If you still see this, setting RUBY_TCP_NO_FAST_FALLBACK=1 in a systemd override for the puppet service may reduce how often it happens:

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

Restarting the puppet service does not clean up a child process that is already stuck; it has to be killed with SIGKILL. If you hit this issue on 9.0.0, please add details to openvox#485.

FIPS packages ship older Bouncy Castle jars

The FIPS builds of openvox-server and openvoxdb ship an older set of Bouncy Castle FIPS jars. The latest Bouncy Castle FIPS 1.x release has a small issue that could cause problems in a very constrained, non-default configuration, so we are not updating to it. Instead, OpenVox 9.1 will move to the Bouncy Castle FIPS 2.x line, which is the one fully certified for FIPS on Java 21.

Thank you

OpenVox 9 would not exist without everyone who submitted pull requests, filed bugs, tested pre-releases, and joined the discussions about what should change. Thank you all!

Special thanks go to the people who carried a large share of the work this cycle, including, but not limited to:

  • Tim Meusel, for work on nearly every repository: runtime and dependency updates, CI, release PRs, and SBOMs.
  • Charlie Sharpsteen, for work across the server, database, runtime, and build tooling, and for the Great Docs Reset of 2026.
  • Michael Harp, for an enormous amount of documentation work, including the 9.x docs, and for tracking down the cause of the agent hang described above.
  • Nick Burgan, for building out the release infrastructure, smoke testing, and the Java and FIPS packaging work.
  • Haroon Rafique, for keeping the Clojure side of openvox-server and openvoxdb healthy, FIPS fixes, and the more secure default server setting.
  • Martin Alfke, for bringing large parts of the documentation up to date for OpenVox and OpenFact.
  • Robert Waffen, for rebuilding the container images and adding multi-platform builds.
  • Ben Ford, for the getting-started and quickstart guides, docs tooling, and catalog validation in the agent.
  • Jerome Charaoui, for Debian packaging and reproducibility fixes.
  • Josh Partlow, for arm64 support and other work on the acceptance tests.
  • Austin Blatt, for the Jetty 12 migration.
  • Chris Boot, for weeks of patient debugging data on openvox#485.
  • Miranda Streeter, for the container image startup speed improvements.

If you have questions about, or encounter issues with these releases, reach out in #openvox on Slack or #voxpupuli-openvox on IRC. See https://voxpupuli.org/connect/ for details.