Skip to content

Update several openvox-server files #213

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
corporate-gadfly merged 4 commits into from
May 17, 2026
Merged

Update several openvox-server files #213

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
907ae97
Update several openvox-server files
tuxmea May 17, 2026
9fb5ea3
Update docs/_openvox-server_8x/deprecated_features.markdown
tuxmea May 17, 2026
e6a0388
Update docs/_openvox-server_8x/deprecated_features.markdown
tuxmea May 17, 2026
7461524
Apply suggestion from @corporate-gadfly
corporate-gadfly May 17, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
16 changes: 9 additions & 7 deletions docs/_openvox-server_8x/crl_refresh.markdown
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,19 +1,21 @@
---
layout: default
title: "Puppet Server: Automatic CRL refresh"
canonical: "/puppetserver/latest/crl_refresh.html"
title: "OpenVox Server: Automatic CRL refresh"
---

Starting in version 5.1.0, Puppet Server can automatically reload an updated CRL into the running SSL context, so that the revocation of an agent's certificate no longer requires a restart of the service to take effect. Prior versions required an explicit restart or reload of this service to reload the CRL, resulting in some small amount of downtime to effect the revocation of a certificate. Revocation is now transparent and requires no service downtime.
OpenVox Server can automatically reload an updated CRL into the running SSL context, so that the revocation of an agent's certificate no longer requires a restart of the service to take effect.
Revocation is now transparent and requires no service downtime.

If you are upgrading and have modified your ca.cfg, adding the following line manually may be required. See [Service Bootstraping](./configuration.html#service-bootstrapping) for information on how to update your Puppet Server's services bootstrap configuration.
If you are upgrading and have modified your ca.cfg, adding the following line manually may be required.

Check failure on line 9 in docs/_openvox-server_8x/crl_refresh.markdown

View workflow job for this annotation

GitHub Actions / markdown-lint

Trailing spaces 

docs/_openvox-server_8x/crl_refresh.markdown:9:104 MD009/no-trailing-spaces Trailing spaces [Expected: 0 or 2; Actual: 1] https://github.com/DavidAnson/markdownlint/blob/v0.40.0/doc/md009.md
See [Service Bootstraping](./configuration.html#service-bootstrapping) for information on how to update your OpenVox Server's services bootstrap configuration.

`puppetlabs.trapperkeeper.services.watcher.filesystem-watch-service/filesystem-watch-service`

### Implementation
## Implementation

Automatic CRL refresh leverages the the [trapperkeeper file system watcher](https://github.com/puppetlabs/trapperkeeper-filesystem-watcher) to watch for changes to the CRL file, and loads the updated CRL on change.
Automatic CRL refresh leverages the the [trapperkeeper file system watcher](https://github.com/openvoxproject/trapperkeeper-filesystem-watcher) to watch for changes to the CRL file, and loads the updated
CRL on change.

### Contributors

Thanks to Jeremy Barlow, who laid the groundwork for this feature in Puppet Server.
Thanks to Jeremy Barlow, who laid the groundwork for this feature in OpenVox Server.
55 changes: 27 additions & 28 deletions docs/_openvox-server_8x/deprecated_features.markdown
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,17 +1,16 @@
---
layout: default
title: "Puppet Server: Deprecated Features"
canonical: "/puppetserver/latest/deprecated_features.html"
title: "OpenVox Server: Deprecated Features"
---

The following features / configuration settings are deprecated and will be removed in a future major release of Puppet Server.
The following features / configuration settings are deprecated and will be removed in a future major release of OpenVox Server.

## `certificate-status` settings

### Now

If the `certificate-authority.certificate-status.authorization-required` setting is `false`, all requests that are successfully validated by SSL (if applicable for the port settings on the server) are permitted
to use the [Certificate Status](https://github.com/puppetlabs/puppet/blob/master/api/docs/http_certificate_status.md) HTTP API endpoints. This includes requests which do not provide an SSL client certificate.
to use the [Certificate Status](https://github.com/openvoxproject/openvox/blob/master/api/docs/http_certificate_status.md) HTTP API endpoints. This includes requests which do not provide an SSL client certificate.

If the `certificate-authority.certificate-status.authorization-required` setting is `true` or not specified and the `puppet-admin.client-whitelist` setting has one or more entries, only the requests whose
Common Name in the SSL client certificate subject matches one of the `client-whitelist` entries are permitted to use the certificate status HTTP API endpoints.
Expand All @@ -21,7 +20,7 @@ For any other configuration, requests are only permitted to access the certifica

### In a Future Major Release

The `certificate-status` settings will be ignored completely by Puppet Server. Requests made to the `certificate-status` HTTP API will only be allowed per the `trapperkeeper-authorization` "auth.conf"
The `certificate-status` settings will be ignored completely by OpenVox Server. Requests made to the `certificate-status` HTTP API will only be allowed per the `trapperkeeper-authorization` "auth.conf"
configuration.

### Detecting and Updating
Expand All @@ -30,7 +29,7 @@ Look at the `certificate-status` settings in your configuration. If `authorizati
the certificate status HTTP API instead of `trapperkeeper-authorization`.

If `authorization-required` is set to `true` or is not specified and if the `client-whitelist` was empty, you could just remove the `certificate-authority` section from your configuration. The only behavior
that would change in Puppet Server from doing this would be that a warning message would no longer be written to the "puppetserver.log" file at startup.
that would change in OpenVox Server from doing this would be that a warning message would no longer be written to the "puppetserver.log" file at startup.

If `authorization-required` is set to `false`, you would need to create a corresponding rule in the `trapperkeeper-authorization` file which would allow unauthenticated client access to the certificate status
API.
Expand Down Expand Up @@ -114,8 +113,8 @@ After adding the desired rules to the `trapperkeeper-authorization` "auth.conf"

### Context

In previous Puppet Server releases, there was no unified mechanism for controlling access to the various endpoints that Puppet Server hosts. Puppet Server used core Puppet "auth.conf" to authorize requests
handled by the master service and custom client whitelists for the CA and Admin endpoints. The custom client whitelists do not provide granular enough control to meet some use cases.
In previous OpenVox Server releases, there was no unified mechanism for controlling access to the various endpoints that OpenVox Server hosts. OpenVox Server used core OpenVox "auth.conf" to authorize requests
handled by the primary service and custom client whitelists for the CA and Admin endpoints. The custom client whitelists do not provide granular enough control to meet some use cases.

`trapperkeeper-authorization` unifies authorization configuration across all of these endpoints into a single file and provides more granular control.

Expand All @@ -134,15 +133,15 @@ For any other configuration, requests are only permitted to access the `puppet-a

### In a Future Major Release

The `puppet-admin` settings will be ignored completely by Puppet Server. Requests made to the `puppet-admin` HTTP API will only be allowed per the `trapperkeeper-authorization` "auth.conf" configuration.
The `puppet-admin` settings will be ignored completely by OpenVox Server. Requests made to the `puppet-admin` HTTP API will only be allowed per the `trapperkeeper-authorization` "auth.conf" configuration.

### Detecting and Updating

Look at the `puppet-admin` settings in your configuration. If `authorization-required` is set to `false` or `client-whitelist` has one or more entries, these settings would be used to authorize access to the
`puppet-admin` HTTP API instead of `trapperkeeper-authorization`.

If `authorization-required` is set to `true` or is not specified and if the `client-whitelist` was empty, you could just remove the `puppet-admin` section from your configuration and restart your puppetserver
service in order for Puppet Server to start using the `trapperkeeper-authorization` "auth.conf" file. The only behavior that would change in Puppet Server from doing this would be that a warning message would
service in order for OpenVox Server to start using the `trapperkeeper-authorization` "auth.conf" file. The only behavior that would change in OpenVox Server from doing this would be that a warning message would
no longer be written to the puppetserver.log file.

If `authorization-required` is set to `false`, you would need to create corresponding rules in the `trapperkeeper-authorization` file which would allow unauthenticated client access to the "puppet-admin" API
Expand Down Expand Up @@ -225,77 +224,77 @@ After adding the desired rules to the `trapperkeeper-authorization` "auth.conf"

### Context

In previous Puppet Server releases, there was no unified mechanism for controlling access to the various endpoints that Puppet Server hosts. Puppet Server used core Puppet "auth.conf" to authorize requests
In previous OpenVox Server releases, there was no unified mechanism for controlling access to the various endpoints that OpenVox Server hosts. OpenVox Server used core OpenVox "auth.conf" to authorize requests
handled by the master service and custom client whitelists for the CA and Admin endpoints. The custom client whitelists do not provide granular enough control to meet some use cases.

`trapperkeeper-authorization` unifies authorization configuration across all of these endpoints into a single file and provides more granular control.

## Puppet's "resource_types" API endpoint
## OpenVox's "resource_types" API endpoint

### Now

The `resource_type` and `resource_types` HTTP APIs were removed in Puppet Server 5.0.
The `resource_type` and `resource_types` HTTP APIs were removed in OpenVox Server 5.0.

### Previously

The [`resource_type` and `resource_types` Puppet HTTP API endpoints](https://puppet.com/docs/puppet/4.6/http_api/http_resource_type.html) return information about classes, defined types, and node definitions.
The [`resource_type` and `resource_types` OpenVox HTTP API endpoints](/openvox/latest/http_api/http_resource_type.html) return information about classes, defined types, and node definitions.

The [`environment_classes` HTTP API in Puppet Server](./puppet-api/v3/environment_classes.html) serves as a replacement for the Puppet resource type API for classes.
The [`environment_classes` HTTP API in OpenVox Server](./puppet-api/v3/environment_classes.html) serves as a replacement for the OpenVox resource type API for classes.

### Detecting and Updating

If your application calls the `resource_type` or `resource_types` HTTP API endpoints for information about classes, point those calls to the `environment_classes` endpoint. The `environment_classes` endpoint
has different features and returns different values than `resource_type`; see the [changes in the environment classes API](./puppet-api/v3/environment_classes.html) for details.

The `environment_classes` endpoint ignores Puppet's Ruby-based authorization methods and configuration in favor of Puppet Server's Trapperkeeper authorization. For more information, see the
The `environment_classes` endpoint ignores OpenVox's Ruby-based authorization methods and configuration in favor of OpenVox Server's Trapperkeeper authorization. For more information, see the
["Authorization" section](./puppet-api/v3/environment_classes.html) of the environment classes API documentation.

### Context

Users often rely on the `resource_types` endpoint for lists of classes and associated parameters in an environment. For such requests, the `resource_types` endpoint is inefficient and can trigger problematic
events, such as [manifests being parsed during a catalog request](https://tickets.puppetlabs.com/browse/SERVER-1200).
events, such as manifests being parsed during a catalog request.

To fulfill these requests more efficiently and safely, Puppet Server 2.3.0 introduced the narrowly defined `environment_classes` endpoint.
To fulfill these requests more efficiently and safely, OpenVox Server 2.3.0 introduced the narrowly defined `environment_classes` endpoint.

## Puppet's node cache terminus
## OpenVox's node cache terminus

### Now

Puppet 5.0 (and by extension, Puppet Server 5.0) no longer writes node YAML files to its cache by default.
OpenVox 5.0 (and by extension, OpenVox Server 5.0) no longer writes node YAML files to its cache by default.

### Previously

Puppet wrote YAML to its node cache.
OpenVox wrote YAML to its node cache.

### Detecting and Updating

To retain the Puppet 4.x behavior, add the [`puppet.conf`](./configuration.html) setting `node_cache_terminus = write_only_yaml`. The `write_only_yaml` option is deprecated.
To retain the OpenVox 4.x behavior, add the [`puppet.conf`](./configuration.html) setting `node_cache_terminus = write_only_yaml`. The `write_only_yaml` option is deprecated.

### Context

This cache was used in workflows where external tooling needs a list of nodes. PuppetDB is the preferred source of node information.
This cache was used in workflows where external tooling needs a list of nodes. OpenVoxDB is the preferred source of node information.

## JRuby's "compat-version" setting

### Now

Puppet Server 5.0 removes the `jruby-puppet.compat-version` setting in [`puppetserver.conf`](./config_file_puppetserver.html), and exits the `puppetserver` service with an error if you start the service with
OpenVox Server 5.0 removes the `jruby-puppet.compat-version` setting in [`puppetserver.conf`](./config_file_puppetserver.html), and exits the `puppetserver` service with an error if you start the service with
that setting.

### Previously

Puppet Server 2.7.x allowed you to set `compat-version` to `1.9` or `2.0` to choose a preferred Ruby interpreter version.
OpenVox Server 2.7.x allowed you to set `compat-version` to `1.9` or `2.0` to choose a preferred Ruby interpreter version.

### Detecting and Updating

Launching the `puppetserver` service with this setting enabled will cause it to exit with an error message. The error includes information on [switching from JRuby 1.7.x to JRuby 9k](./configuration.html).

For Ruby language 2.x support in Puppet Server, configure Puppet Server to use JRuby 9k instead of JRuby 1.7.27. See the "Configuring the JRuby Version" section of
For Ruby language 2.x support in OpenVox Server, configure OpenVox Server to use JRuby 9k instead of JRuby 1.7.27. See the "Configuring the JRuby Version" section of
[Puppet Server Configuration](./configuration.html) for details.

### Context

Puppet Server 5.0 updated JRuby v1.7 to v1.7.27, which in turn updated the `jruby-openssl` gem to v0.9.19 and `bouncycastle` libraries to v1.55. JRuby 1.7.27 breaks setting `jruby-puppet.compat-version` to
OpenVox Server 5.0 updated JRuby v1.7 to v1.7.27, which in turn updated the `jruby-openssl` gem to v0.9.19 and `bouncycastle` libraries to v1.55. JRuby 1.7.27 breaks setting `jruby-puppet.compat-version` to
`2.0`.

Server 5.0 also added optional, experimental support for JRuby 9k, which includes Ruby 2.x language support.
OpenVox Server 5.0 also added optional, experimental support for JRuby 9k, which includes Ruby 2.x language support.
21 changes: 10 additions & 11 deletions docs/_openvox-server_8x/dev_debugging.markdown
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,10 +1,9 @@
---
layout: default
title: "Puppet Server: Debugging"
canonical: "/puppetserver/latest/dev_debugging.html"
title: "OpenVox Server: Debugging"
---

Because Puppet Server executes both Clojure and Ruby code, approaches to debugging differ depending on which part of the application you're interested in.
Because OpenVox Server executes both Clojure and Ruby code, approaches to debugging differ depending on which part of the application you're interested in.

## Debugging Clojure Code

Expand All @@ -20,10 +19,10 @@ debugging features that are available in Java; breakpoints, evaluating expressio

## Debugging Ruby Code

Debugging the Ruby code running in Puppet Server can be a bit trickier, because Java and Clojure debugging tools will only take you into the JRuby interpreter source code, not into the Ruby code that it is
Debugging the Ruby code running in OpenVox Server can be a bit trickier, because Java and Clojure debugging tools will only take you into the JRuby interpreter source code, not into the Ruby code that it is
processing. So, if you wish to debug the Ruby code directly, you'll need to install gems and take advantage of their capabilities (not unlike how you would debug Ruby code in the MRI interpreter).

For more info on installing gems for Puppet Server, see [Puppet Server and Gems](./gems.html).
For more info on installing gems for OpenVox Server, see [OpenVox Server and Gems](./gems.html).

## Ruby REPL incompatible with Lein REPL

Expand All @@ -41,7 +40,7 @@ sense.
### Installation

There are many gems available that provide various ways of debugging Ruby code depending on what version of Ruby and which Ruby interpreter you're running. One of the most common gems is `ruby-debug`, and there
is a JRuby-compatible version available. To install it for use in Puppet Server, run:
is a JRuby-compatible version available. To install it for use in OpenVox Server, run:

sudo puppetserver gem install ruby-debug

Expand All @@ -51,7 +50,7 @@ Or, if you're running puppetserver from source:

### Usage

After installing the gem, you can trigger the debugger by adding a line like this to any of the Ruby code that is run in Puppet Server (including the Puppet Ruby code):
After installing the gem, you can trigger the debugger by adding a line like this to any of the Ruby code that is run in OpenVox Server (including the OpenVox Ruby code):

require 'ruby-debug'; debugger

Expand Down Expand Up @@ -86,11 +85,11 @@ adding it to this documentation!

## Limitations

We are aware that some favorite gems/tools/features for ruby debugging don't currently work with JRuby/Puppet Server. (For example, some things like color syntax highlighting in Pry.) It's important to us to
make sure that the Ruby developer experience is not degraded for developers working via Puppet Server rather than webrick, so, if you run into issues like this, please file an issue on our
[Bug Tracker](https://tickets.puppet.com/browse/SERVER), and we will see if it's possible to add support for things that we're missing. In many cases it might be a matter of simply submitting a patch to JRuby,
We are aware that some favorite gems/tools/features for ruby debugging don't currently work with JRuby/OpenVox Server. (For example, some things like color syntax highlighting in Pry.)
It's important to us to make sure that the Ruby developer experience is not degraded for developers working via OpenVox Server, so, if you run into issues like this, please file an issue on our
[Bug Tracker](https://github.com/openvoxproject), and we will see if it's possible to add support for things that we're missing. In many cases it might be a matter of simply submitting a patch to JRuby,
or submitting a JRuby-compatibility patch for an existing gem, and we're interested in trying to help with those sorts of things whenever possible.

# Tracing Code Events

Puppet Server can utilize JRuby's standard facilities for tracing events during code execution. For more information on these techniques, see the [Tracing Code Events](./dev_trace_func.html) page.
OpenVox Server can utilize JRuby's standard facilities for tracing events during code execution. For more information on these techniques, see the [Tracing Code Events](./dev_trace_func.html) page.
Loading
Loading