Merge branch 'master' into docs/retire-ldap-node-classifier-278

tuxmea · web-flow · commit 0fc2b5900ff5 · 2026-07-02T08:58:08.000+02:00
diff --git a/_data/openvoxdb_release_contents/openvox_8x.yml b/_data/openvoxdb_release_contents/openvox_8x.yml
@@ -1,5 +1,11 @@
 ---
+- release: 8.14.1
+  jetty: 12.1.10
 - release: 8.14.0
+  jetty: 12.1.10
 - release: 8.13.0
+  jetty: 10.0.26
 - release: 8.12.1
+  jetty: 10.0.26
 - release: 8.12.0
+  jetty: 10.0.26
diff --git a/_data/server_release_contents/openvox_8x.yml b/_data/server_release_contents/openvox_8x.yml
@@ -1,4 +1,6 @@
 ---
+- release: 8.14.1
+  jruby: 9.4.12.1
 - release: 8.14.0
   jruby: 9.4.12.1
 - release: 8.13.0
diff --git a/docs/_ecosystem_8x/devkit/migrating.md b/docs/_ecosystem_8x/devkit/migrating.md
@@ -16,18 +16,22 @@ If you get an error about a command not being available, you probably just need
 
 {% include alert.html type="tip" content="There are a few exceptions to this pattern. For example, Jig is an installed package and VoxBox is a Docker container." %}
 
-| You used to type... | Now you type...  |
-|---------------------|------------------|
-| `pdk new module`    | `jig new module` |
-| `pdk new class`     | `jig new class`  |
-| `pdk build`         | `jig build`      |
-| `pdk release`       | `jig release`    |
-| `pdk convert`       | _not needed_     |
-| `pdk update`        | `jig update`     |
-| `pdk validate`      | `jig validate`   |
-| `pdk test unit`     | `jig test unit`  |
-
-`jig update`, `jig validate`, and `jig test unit` are thin wrappers around `bundle exec msync update`, `bundle exec rake validate lint`, and `bundle exec rake spec` respectively, so they still need the module's gems installed (`bundle install`).
-You can keep running the underlying `bundle exec` commands directly if you prefer.
+Jig also contains thin wrappers around the `bundle exec` commands, so in many cases you can use the CLI patterns you're used to typing.
+Because Jig does not attempt to hide the Bundler environment from you, it will still need the module's gems installed (`bundle install`) and ModuleSync configured properly.
+
+{% include alert.html type="tip" title="Choosing command forms" content="If you want quick and familiar commands to run locally, then use the Jig wrapper commands. If you're running tests and such in CI or if you need to pass custom options then invoke the tools directly." %}
+
+| You used to type... | Now you type...  | Or run tools directly...         |
+|---------------------|------------------|----------------------------------|
+| `pdk new module`    | `jig new module` |                                  |
+| `pdk new class`     | `jig new class`  |                                  |
+| `pdk build`         | `jig build`      |                                  |
+| `pdk release`       | `jig release`    |                                  |
+| `pdk convert`       | _not needed_     |                                  |
+| `pdk update`        | `jig update`*    | `bundle exec msync update`*      |
+| `pdk validate`      | `jig validate`   | `bundle exec rake validate lint` |
+| `pdk test unit`     | `jig test unit`  | `bundle exec rake spec`          |
+
+{% include alert.html type="note" title="*NOTE" content="`pdk update` operates in context of a single module. In contrast, the replacement ModuleSync commands (`jig update` and `bundle exec msync update`) should be run in the template repository to push updates to all your modules at once. [Read more](modulesync.html)." %}
 
 Browse through the individual subpages of this Developer Tooling section to learn more about each component.
diff --git a/docs/_openvox_8x/component_versions.md b/docs/_openvox_8x/component_versions.md
@@ -26,11 +26,10 @@ on its own 5.x line). There is no single "OpenVox platform version" that pins al
 of them at once, so each component is shown in its own table, keyed by that
 component's release.
 
-The bundled-component columns are **generated** from upstream release metadata (the
-per-release SBOMs published by [openvox-sbom-tools][sbom_tools] for the agent and
-OpenBolt, and component pins for the server), so they don't drift. Columns that
-aren't bundled or pinned anywhere (Java and PostgreSQL) are supported-version
-requirements maintained by hand; see the note under each table.
+The bundled-component columns are **generated** from the per-release SBOMs published
+by [openvox-sbom-tools][sbom_tools] for every component, so they don't drift. Columns
+that aren't bundled anywhere (Java and PostgreSQL) are supported-version requirements
+maintained by hand; see the note under each table.
 
 <!-- markdownlint-disable MD055 MD056 -->
 
@@ -48,8 +47,8 @@ changes; this page is only a pointer.
 
 ## Server components
 
-These ship with the `openvox-server` package. JRuby is the bundled version,
-resolved from the server's pinned `jruby-utils`/`jruby-deps`.
+These ship with the `openvox-server` package. JRuby is the bundled version, read
+from the server's per-release SBOM.
 
 | OpenVox Server release | JRuby | Java |
 | --- | --- | --- |
@@ -67,15 +66,19 @@ OpenVoxDB ships in the `openvoxdb` package on its own release line. The
 agents talk to OpenVoxDB) is released in lockstep at the **same version** as
 `openvoxdb`, so it is not listed separately.
 
-| OpenVoxDB release | PostgreSQL |
-| --- | --- |
-{% for r in site.data.openvoxdb_release_contents[nav_key] %}| {{ r.release }} | 11+ (14+ recommended) |
+Jetty is the bundled HTTP server, read from the OpenVoxDB SBOM.
+
+| OpenVoxDB release | Jetty | Java | PostgreSQL |
+| --- | --- | --- | --- |
+{% for r in site.data.openvoxdb_release_contents[nav_key] %}| {{ r.release }} | {{ r.jetty }} | 11, 17 | 11+ (14+ recommended) |
 {% endfor %}
 
-> **PostgreSQL is not bundled.** OpenVoxDB connects to a PostgreSQL server you
-> install separately (the `puppet-openvoxdb` module can install it for you). The
-> PostgreSQL column shows the supported minimum (PostgreSQL 11; version 14 or newer
-> recommended), not a per-release pin; see [Configuring PostgreSQL][openvoxdb_postgres].
+> **Java and PostgreSQL are not bundled.** OpenVoxDB runs on a JVM and connects to a
+> PostgreSQL server you install separately (the `puppet-openvoxdb` module can install
+> PostgreSQL for you). The Java column shows the currently supported major versions,
+> and the PostgreSQL column the supported minimum (PostgreSQL 11; version 14 or newer
+> recommended) — neither is a per-release pin. See
+> [Configuring PostgreSQL][openvoxdb_postgres].
 
 ## OpenBolt
 
diff --git a/docs/_openvox_8x/config_important_settings.markdown b/docs/_openvox_8x/config_important_settings.markdown
@@ -125,7 +125,7 @@ These settings should usually go in `[server]`. However, if you're using Puppet
 ### Basics
 
 * [`dns_alt_names`][dns_alt_names] --- A list of hostnames the server is allowed to use when acting as an OpenVox Server. The hostname your agents use in their `server` setting **must** be included in either this setting or the master's `certname` setting. Note that this setting is only used when initially generating the OpenVox Server's certificate --- if you need to change the DNS names, you must:
-    1. Turn off the Puppet server service (or your Rack server).
+    1. Turn off the Puppet server service.
     2. Run `sudo puppetserver ca clean --certname <SERVER'S CERTNAME>`.
     3. Run `sudo puppetserver ca generate --certname <SERVER'S CERTNAME> --subject-alt-names <ALT NAME 1>,<ALT NAME 2>,...`.
     4. Re-start the Puppet server service.
diff --git a/docs/_openvox_8x/config_print.markdown b/docs/_openvox_8x/config_print.markdown
@@ -78,7 +78,7 @@ To see the settings the OpenVox Server service would use:
 * Specify `--section server`.
 * Use the `--environment` option to specify the environment you want settings for, or let it default to `production`.
 * Remember to use `sudo`.
-* If your OpenVox Server is managed as a rack application (e.g. with Passenger), check the `config.ru` file to make sure it's using the [confdir][] and [vardir][] that you expect. If it's using non-standard ones, you will need to specify them on the command line with the `--confdir` and `--vardir` options; otherwise you might not see the correct values for settings.
+* If your OpenVox Server uses a non-standard [confdir][] or [vardir][], specify them on the command line with the `--confdir` and `--vardir` options; otherwise you might not see the correct values for settings.
 
 ### Examples
 
diff --git a/docs/_openvox_8x/dirs_codedir.markdown b/docs/_openvox_8x/dirs_codedir.markdown
@@ -20,8 +20,6 @@ When Puppet is running as either root, a Windows user with administrator privile
 
 The system codedir is what you usually want to use, since you will usually run Puppet's commands and services as root or `puppet`. (Note that admin commands like `puppet module` must be run with `sudo` to use the same codedir as OpenVox agent or OpenVox Server.)
 
-> **Note:** When OpenVox Server is running as a Rack application, the `config.ru` file must explicitly set `--codedir` to the system codedir. The example `config.ru` file provided with the Puppet source does this.
-
 ### Configuration
 
 The location of the codedir can be configured in puppet.conf with [the `codedir` setting][codedir], but note that Puppet Server doesn't use that setting; it has its own `jruby-puppet.master-code-dir` setting [in puppetserver.conf][puppetserver_conf]. If you're using a non-default codedir, _you must change both settings._
diff --git a/docs/_openvox_8x/dirs_confdir.markdown b/docs/_openvox_8x/dirs_confdir.markdown
@@ -21,8 +21,6 @@ The system confdir is what you usually want to use, since you will usually run P
 services as root or `puppet`. (Note that admin commands like `puppetserver ca` must be run with `sudo`
 to use the same confdir as OpenVox agent or OpenVox Server.)
 
-> **Note:** When OpenVox Server is running as a Rack application, the `config.ru` file must explicitly set `--confdir` to the system confdir. The example `config.ru` file provided with the Puppet source does this.
-
 ### Configuration
 
 Puppet's confdir can be specified on the command line with the `--confdir` option, but it can't be set
diff --git a/docs/_openvox_8x/dirs_vardir.markdown b/docs/_openvox_8x/dirs_vardir.markdown
@@ -24,8 +24,6 @@ The system cache directory is what you usually want to use, since you will usual
 and services as root or `puppet`. (Note that admin commands like `puppetserver ca` must be run with
 `sudo` to use the same directories as OpenVox agent or OpenVox Server.)
 
-> **Note:** When OpenVox Server is running as a Rack application, the `config.ru` file must explicitly set `--vardir` to the system cache directory. The example `config.ru` file provided with the Puppet source does this.
-
 ### Configuring the location of the cache directory
 
 You can specify Puppet's cache directory on the command line by using the `--vardir` option, but you can't set it in `puppet.conf`. If `--vardir` isn't specified when a Puppet application is started, it will always use the default cache directory location.
diff --git a/docs/_openvox_8x/static_catalogs.md b/docs/_openvox_8x/static_catalogs.md
@@ -117,7 +117,7 @@ The script's standard output becomes the file's `code_content`, provided the scr
 Starting in Puppet 4.4 and OpenVox Server 2.3.0, the global `static_catalogs` setting is enabled by default, whether you upgrade Puppet or perform a clean installation.
 However, the default configuration doesn't include the `code-id-command` and `code-content-command` scripts or settings needed to produce static catalogs, and even when configured to produce static catalogs OpenVox Server doesn't inline metadata for all types of file resources.
 
-Static catalogs are produced only by OpenVox Server. The Ruby OpenVox server never produces static catalogs, even when served by WEBrick or Passenger.
+Static catalogs are produced only by OpenVox Server.
 
 OpenVox Server also won't produce static catalogs for an agent under the following circumstances:
 
diff --git a/lib/puppet_references/release_tables.rb b/lib/puppet_references/release_tables.rb
@@ -12,9 +12,8 @@ module PuppetReferences
   # drive the table and resolves one row per stable release from authoritative,
   # structured metadata, so the tables are never hand-maintained. The shared
   # GitHub releases/contents plumbing lives here so the per-table classes stay
-  # small. Agent and OpenBolt rows come from openvox-sbom-tools SBOMs (see
-  # SbomReleaseTable); server and OpenVoxDB rows are still resolved from upstream
-  # pins until their SBOMs land.
+  # small. Every table now sources its bundled-component columns from
+  # openvox-sbom-tools SBOMs (see SbomReleaseTable).
   #
   # Authenticates with ENV GITHUB_TOKEN/GH_TOKEN, falling back to `gh auth token`
   # for local runs. A release whose components can't be resolved (e.g. a tag that
@@ -210,52 +209,45 @@ def columns
     end
   end
 
-  # openvox-server: bundled JRuby, resolved through the server's pinned
-  # jruby-utils -> jruby-deps "9.4.12.1-3" (the trailing "-N" packaging suffix is
-  # stripped). Java is a supported requirement, not a pin, so it is hand-maintained
-  # on the docs page rather than resolved here. Stays on the upstream-pin scraper
-  # until an openvox-server SBOM is published.
-  class ServerReleaseTable < ReleaseTable
-    SERVER_REPO = 'OpenVoxProject/openvox-server'
-    JRUBY_UTILS_REPO = 'OpenVoxProject/jruby-utils'
+  # openvox-server: bundled JRuby, read from the openvox-server SBOM's `jruby-base`
+  # component (the resolved JRuby version). This replaces the previous resolution
+  # through the server's pinned jruby-utils -> jruby-deps in project.clj, which
+  # required stripping a "-N" packaging suffix; `jruby-base` is already clean. Java
+  # is a supported requirement, not a pin, so it is hand-maintained on the docs
+  # page rather than resolved here.
+  class ServerReleaseTable < SbomReleaseTable
+    REPO = 'OpenVoxProject/openvox-server'
 
     def repo
-      SERVER_REPO
-    end
-
-    def row_for(tag, cache)
-      jruby_utils = pin_in_project_clj(SERVER_REPO, tag, 'jruby-utils')
-      { 'release' => tag, 'jruby' => (cache[jruby_utils] ||= jruby_from_utils(jruby_utils)) }
+      REPO
     end
 
-    private
-
-    def jruby_from_utils(jruby_utils_ver)
-      deps = pin_in_project_clj(JRUBY_UTILS_REPO, jruby_utils_ver, 'jruby-deps')
-      deps.sub(/-\d+\z/, '')
+    def sbom_package
+      'openvox-server'
     end
 
-    # Version of an org.openvoxproject/<name> dependency pinned in a repo's project.clj.
-    def pin_in_project_clj(repo, ref, name)
-      clj = raw(repo, 'project.clj', ref)
-      version = clj[%r{org\.openvoxproject/#{Regexp.escape(name)}\s+"([^"]+)"}, 1]
-      raise NotFound, "#{name} pin in #{repo}@#{ref}" unless version
-
-      version
+    def columns
+      { 'jruby' => 'jruby-base' }
     end
   end
 
-  # OpenVoxDB ships on its own independent version line; the table is just its
-  # stable release tags. PostgreSQL is a supported requirement (the openvoxdb
-  # module only declares a postgresql dependency range, not a bundled version),
-  # so it is hand-maintained on the docs page.
-  class OpenvoxdbReleaseTable < ReleaseTable
+  # OpenVoxDB ships on its own independent version line. It is a Clojure/JVM
+  # service (no bundled JRuby), so the one bundled component worth surfacing is the
+  # embedded Jetty HTTP server, read from its per-release SBOM. Java and PostgreSQL
+  # are supported requirements (the openvoxdb module only declares a postgresql
+  # dependency range, not a bundled version), so those columns stay hand-maintained
+  # on the docs page.
+  class OpenvoxdbReleaseTable < SbomReleaseTable
     def repo
       'OpenVoxProject/openvoxdb'
     end
 
-    def row_for(tag, _cache)
-      { 'release' => tag }
+    def sbom_package
+      'openvoxdb'
+    end
+
+    def columns
+      { 'jetty' => 'jetty-server' }
     end
   end
 end
