OpenVoxProject · tuxmea · May 4, 2026 · May 2, 2026 · May 4, 2026 · tuxmea
@@ -51,7 +51,7 @@ validation failures.) Puppet Server uses this to authorize requests; only reques
 
 Mandatory. Must be the [Subject DN][] of the agent's certificate, if a certificate was presented. Puppet Server uses this to authorize requests.
 
-[subject dn]: https://docs.puppet.com/background/ssl/cert_anatomy.html#the-subject-dn-cn-certname-etc
+[subject dn]: /docs/background/ssl/cert_anatomy.html#the-subject-dn-cn-certname-etc
 
 ### `X-Client-Cert`
 
@@ -66,5 +66,5 @@ characters must be encoded as `%20` and not `+` characters.
 > **Note:** Apache's `mod_proxy` converts line breaks in PEM documents to spaces for some reason, and Puppet Server can't decode the result. We're tracking this issue as
 > [SERVER-217](https://tickets.puppetlabs.com/browse/SERVER-217).
 
-[pem format]: https://docs.puppet.com/background/ssl/cert_anatomy.html#pem-file
+[pem format]: /docs/background/ssl/cert_anatomy.html#pem-file
 [trusted]: https://puppet.com/docs/puppet/latest/lang_facts_and_builtin_vars.html#trusted-facts
@@ -19,7 +19,7 @@
 You can configure systems with OpenVox either in a client-server architecture, using the **OpenVox agent** and **OpenVox server** applications, or in a stand-alone architecture, using the **OpenVox apply** application.

 {:.concept}
 ## Catalogs

 A catalog is a document that describes the desired system state for one specific computer. It lists all of the resources that need to be managed, as well as any dependencies between those resources.

@@ -31,7 +31,7 @@
 To compile a catalog, OpenVox uses several sources of information. For more info, see the pages on [basics of the OpenVox language][lang_basics] and [catalog compilation][catalog_compilation].

 {:.concept}
 ## The agent-server architecture

 When set up as an agent-server architecture, an OpenVox server controls the configuration information, and each managed agent node requests its own configuration catalog from the server.

@@ -39,7 +39,7 @@

 Periodically, each OpenVox agent sends facts to the OpenVox server, and requests a catalog. The server compiles and returns that node's catalog, using several sources of information it has access to.

 Once it receives a catalog, OpenVox agent applies it to the node by checking each [resource][] the catalog describes. If it finds any resources that are not in their desired state, it makes the changes necessary to correct them. Or, in no-op mode, it reports on what changes would have been done.

 After applying the catalog, the agent sends a report to the OpenVox server.

@@ -50,7 +50,7 @@
 * [OpenVox Server][]

 {:.section}
 ### Communications and security

 OpenVox agent nodes and OpenVox servers communicate by HTTPS with client SSL verification.

@@ -58,38 +58,38 @@

 Client-verified HTTPS means each server or agent must have an identifying SSL certificate. They each examine their counterpart's certificate to decide whether to allow an exchange of information.

 OpenVox includes a built-in certificate authority for managing certificates. Agents can automatically request certificates through the server's HTTP API. You can use the **puppet ssl** command on an agent to inspect local certificates. The **puppetserver ca** command on the server manages new and existing certificates. Agents can then download the signed certificates.

 For more information, see:

 * [A walkthrough of OpenVox's HTTPS communications][https_walkthrough]
 * [The OpenVox server's HTTP API][server_http]
 * [The OpenVox server's auth.conf file][auth.conf]
-* [Background reference on SSL and HTTPS.](/background/ssl/)
+* [Background reference on SSL and HTTPS.](/docs/background/ssl/)
 
 {:.concept}
 ## The stand-alone architecture

 Alternatively, OpenVox can run in a stand-alone architecture, where each managed node has its own complete copy of your configuration info and compiles its own catalog.

 In this architecture, managed nodes run the **OpenVox apply** application, usually as a scheduled task or cron job. You can also run it on demand for initial configuration of a server or for smaller configuration tasks.

 Like the OpenVox server application, OpenVox apply needs access to several sources of configuration data, which it uses to compile a catalog for the node it is managing.

 After OpenVox apply compiles the catalog, it immediately applies it by checking each [resource][] the catalog describes. If it finds any resources that are not in their desired state, it makes the changes necessary to correct them. Or, in no-op mode, it reports on what changes would have been needed.

 After applying the catalog, OpenVox apply stores a report on disk. You can configure it to send reports to a central service.

 For more information, see the documentation for [the OpenVox apply application][apply].

 {:.concept}
 ## Differences between agent-server and stand-alone

 In general, OpenVox apply can do the same things as the combination of OpenVox agent and OpenVox server, but there are several trade-offs around security and the ease of certain tasks.

 If you don't have a preference, you should select the agent-server architecture. If you have questions, considering these trade-offs helps you make your decision.

 * **Principle of least privilege.** In agent-server OpenVox, each agent only gets its own configuration, and is unable to see how other nodes are configured. With OpenVox apply, it's impractical to do this, so every node has access to complete knowledge about how your site is configured. Depending on how you're configuring your systems, this can potentially raise the risks of horizontal privilege escalation.
 * **Ease of centralized reporting and inventory.** Agents send reports to the OpenVox server by default, and the server can be configured with any number of [report handlers][] to pass these on to other services. You can also connect the master to [OpenVox-DB][], a powerful tool for querying inventory and activity data. OpenVox apply nodes handle their own information, so if you're using OpenVox-DB or sending reports to another service, _each_ node needs to be configured and authorized to connect to it.
 * **Ease of updating configurations.** Only OpenVox servers have the Puppet modules, main manifests, and other data necessary for compiling catalogs. This means that when you need to update your systems' configurations, you only need to update content on one (or a few) OpenVox servers. In a decentralized `puppet apply` deployment, you'll need to sync new configuration code and data to every node.
 * **CPU and memory usage on managed machines.** Since OpenVox agent doesn't compile its own catalogs, it uses fewer resources on the machines it manages, leaving them with more capacity for their designated tasks.

@@ -7,7 +7,7 @@ title: "Configuration: Short list of important settings"
 [trusted_and_facts]: ./lang_facts_and_builtin_vars.html
 [config_reference]: ./configuration.html
 [environments]: ./environments_about.html
-[multi_master]: /guides/scaling_multiple_masters.html
+[multi_master]: /openvox-server/latest/scaling_puppet_server.html
 [enc]: ./nodes_external.html
 [meta_noop]: ./metaparameter.html#noop
 [meta_schedule]: ./metaparameter.html#schedule

@@ -6,7 +6,7 @@ title: Custom Types
 [package_type]: /puppet/latest/type.html#package
 [module]: /puppet/latest/modules_fundamentals.html
 [custom_functions]: /puppet/latest/lang_write_functions_in_puppet.html
-[custom_facts]: /facter/latest/custom_facts.html
+[custom_facts]: /openfact/latest/custom_facts.html
 [pluginsync]: /puppet/latest/configuration.html#pluginsync
 [symbol]: http://www.ruby-doc.org/core/Symbol.html
 [ruby_block]: http://www.robertsosinski.com/2008/12/21/understanding-ruby-blocks-procs-and-lambdas/

@@ -42,5 +42,5 @@ Each feature's page will attempt to give some context about the status of that f
 
 If you are testing Puppet's experimental features: Thank you! Please tell us more about your experience, so we can keep making Puppet better.
 
-* The best places to talk about experimental features are the [puppet-users](https://groups.google.com/group/puppet-users) and [puppet-dev](https://groups.google.com/group/puppet-dev) mailing lists. This tells us what's working and what isn't, while also helping others learn from your experience. For more information about the Puppet mailing lists, please see [the community guidelines for mailing lists](/community/community_guidelines.html#mailing-list-guidelines).
-* For more immediate conversations, you can use the #puppet and #puppet-dev channels on irc.freenode.net. For more information about these channels, please see [the community guidelines for IRC](/community/community_guidelines.html#ircslack).
+* The best places to talk about experimental features are the [puppet-users](https://groups.google.com/group/puppet-users) and [puppet-dev](https://groups.google.com/group/puppet-dev) mailing lists. This tells us what's working and what isn't, while also helping others learn from your experience. For more information about the Puppet mailing lists, please see [the community guidelines for mailing lists](https://voxpupuli.org/connect).
+* For more immediate conversations, you can use the #puppet and #puppet-dev channels on irc.freenode.net. For more information about these channels, please see [the community guidelines for IRC](https://voxpupuli.org/connect).
@@ -34,7 +34,7 @@ title: "Language: Classes"
 [declare]: #declaring-classes
 [setting_parameters]: #include-like-vs-resource-like
 [override]: #using-resource-like-declarations
-[ldap_nodes]: /guides/ldap_nodes.html
+[ldap_nodes]: ./nodes_ldap.html
 [hiera]: /openvox/latest/hiera_intro.html
 [external_data]: /openvox/latest/hiera_automatic.html
 [array_search]: /openvox/latest/hiera_merging.html

@@ -5,7 +5,7 @@ layout: default
 
 [func_ref]: ./function.html
 [forge]: https://forge.puppetlabs.com
-[custom]: /guides/custom_functions.html
+[custom]: ./lang_write_functions_in_puppet.html
 [stdlib]: https://forge.puppetlabs.com/puppetlabs/stdlib
 [resource]: ./lang_resources.html
 [custom_facts]: /openfact/latest/custom_facts.html

@@ -22,7 +22,7 @@ title: "Language: Basics"
 [variables]: ./lang_variables.html
 [ordering]: ./lang_relationships.html#ordering
 [notification]: ./lang_relationships.html#refreshing-and-notification
-[declared]: /references/glossary.html#declare
+[declared]: ./lang_classes.html
 [string_newline]: ./lang_data_string.html#line-breaks
 [node]: ./lang_node_definitions.html
 [hiera]: /openvox/latest/hiera_intro.html

@@ -5,7 +5,7 @@ title: "Language: Using templates"
 
 [interpolate]: ./lang_data_string.html#interpolation
 [heredoc]: ./lang_data_string.html#heredocs
-[augeas]: /guides/augeas.html
+[augeas]: ./resources_augeas.html
 [concat]: https://forge.puppetlabs.com/puppetlabs/concat
 [file_line]: https://forge.puppetlabs.com/puppetlabs/stdlib
 [functions]: ./lang_functions.html

@@ -22,7 +22,7 @@ title: "Installing modules"
 
 [approved]: https://forge.puppet.com/approved
 [supported]: https://forge.puppet.com/supported
-[score]: /forge/assessingmodulequality.html
+[score]: https://forge.puppet.com
 [environment]: ./environments_about.html
 [pdk]: {{pdk}}/pdk.html
 

@@ -58,7 +58,7 @@ You can edit the [parameters](./lang_classes.html#defining-classes) of a class i
 > That's it! You have set the Apache web server's root directory to `/var/www` instead of its default `/var/www/html`. If you refresh `http://myagentnodeIP:80/` in your web browser, it shows the list of files in `/var/www`. If you click `html`, the browser will again show the contents of `/var/www/html/index.html`.
 >
 > **Note:**
-> If you have Puppet Enterprise, you can do the steps in this guide through the PE web UI, [the console]({{pe}}/console_accessing.html).
+> If you have Puppet Enterprise, you can do the steps in this guide through the PE web UI, [the console]({{pe}}https://www.puppet.com/docs/pe/latest/console_accessing.html).
 
 
 ----------

@@ -32,7 +32,7 @@ Some modules can be large, complex, and require a significant amount of trial an
 >
 >**Note:** Puppet also creates another module directory: `/opt/puppetlabs/puppet/modules`. Don't modify or add anything in this directory, including modules of your own.
 >
->There are plenty of resources about modules and the creation of modules that you can reference. Check out [Module Fundamentals](./modules_fundamentals.html), the [Beginner's Guide to Modules](/guides/module_guides/bgtm.html), and the [Puppet Forge](https://forge.puppetlabs.com/).
+>There are plenty of resources about modules and the creation of modules that you can reference. Check out [Module Fundamentals](./modules_fundamentals.html), the [Beginner's Guide to Modules](./bgtm.html), and the [Puppet Forge](https://forge.puppetlabs.com/).
 
 Modules are directory trees. For this task, you'll create the following files:
 

@@ -61,7 +61,7 @@ Some modules can be large, complex, and require a significant amount of trial an
 >
 >**Note:** Puppet also creates another module directory: `/opt/puppetlabs/puppet/modules`. Don't modify or add anything in this directory, including modules of your own.
 >
->There are plenty of resources about modules and the creation of modules that you can reference. Check out [Module Fundamentals](./modules_fundamentals.html), the [Beginner's Guide to Modules](/guides/module_guides/bgtm.html), and the [Puppet Forge](https://forge.puppetlabs.com/).
+>There are plenty of resources about modules and the creation of modules that you can reference. Check out [Module Fundamentals](./modules_fundamentals.html), the [Beginner's Guide to Modules](./bgtm.html), and the [Puppet Forge](https://forge.puppetlabs.com/).
 
 Modules are directory trees. For this task, you'll create the following files:
 

@@ -32,7 +32,7 @@ Modules are directory trees. For this task, you'll create the following structur
 Every manifest (.pp file) in a module contains a single class. File names map to class names in a predictable way, described in the [Autoloader Behavior documentation](./lang_namespaces.html#autoloader-behavior). The `init.pp` file is a special case that contains a class named after the module, `helloworld`. Other manifest files contain classes called `<MODULE NAME>::<FILE NAME>`, or in this case, `helloworld::motd`.
 
 * For more on how modules work, see [Module Fundamentals](./modules_fundamentals.html) in the Puppet documentation.
-* For more on best practices, methods, and approaches to writing modules, see the [Beginners Guide to Modules](/guides/module_guides/bgtm.html).
+* For more on best practices, methods, and approaches to writing modules, see the [Beginners Guide to Modules](./bgtm.html).
 
 **To write the `helloworld` class**:
 
@@ -106,7 +106,7 @@ From the command line of your agent, run `cat /etc/motd`. The result should show
 
 ## Other resources
 
->There are plenty of resources about modules and the creation of modules that you can reference. Check out [Module Fundamentals](./modules_fundamentals.html), the [Beginner's Guide to Modules](/guides/module_guides/bgtm.html), and the [Puppet Forge](https://forge.puppetlabs.com/).
+>There are plenty of resources about modules and the creation of modules that you can reference. Check out [Module Fundamentals](./modules_fundamentals.html), the [Beginner's Guide to Modules](./bgtm.html), and the [Puppet Forge](https://forge.puppetlabs.com/).
 >
 > Check out the remainder of the [Quick Start Guide series](./quick_start.html) for additional module writing exercises.
 

@@ -52,7 +52,7 @@ Some modules can be large, complex, and require a significant amount of trial an
 >
 >**Note:** Puppet also creates another module directory: `/opt/puppetlabs/puppet/modules`. Don't modify or add anything in this directory, including modules of your own.
 >
->There are plenty of resources about modules and the creation of modules that you can reference. Check out [Module Fundamentals](./modules_fundamentals.html), the [Beginner's Guide to Modules](/guides/module_guides/bgtm.html), and the [Puppet Forge](https://forge.puppetlabs.com/).
+>There are plenty of resources about modules and the creation of modules that you can reference. Check out [Module Fundamentals](./modules_fundamentals.html), the [Beginner's Guide to Modules](./bgtm.html), and the [Puppet Forge](https://forge.puppetlabs.com/).
 
 Modules are directory trees. For this task, you'll create the following files:
 

@@ -24,7 +24,7 @@ Although many Forge modules are exact solutions that fit your site, many are *al
 >
 >**Note:** Puppet also creates another module directory: `/opt/puppetlabs/puppet/modules`. Don't modify or add anything in this directory, including modules of your own.
 >
->There are plenty of resources about modules and the creation of modules that you can reference. Check out [Module Fundamentals](./modules_fundamentals.html), the [Beginner's Guide to Modules](/guides/module_guides/bgtm.html), and the [Puppet Forge](https://forge.puppetlabs.com/).
+>There are plenty of resources about modules and the creation of modules that you can reference. Check out [Module Fundamentals](./modules_fundamentals.html), the [Beginner's Guide to Modules](./bgtm.html), and the [Puppet Forge](https://forge.puppetlabs.com/).
 
 
 
@@ -41,7 +41,7 @@ Every manifest (.pp file) in a module contains a single class. File names map to
 Many modules, including Apache, contain directories other than `manifests` and `templates`. For simplicity's sake, we do not cover them in this introductory guide.
 
 * For more on how modules work, see [Module Fundamentals](./modules_fundamentals.html) in the Puppet documentation.
-* For more on best practices, methods, and approaches to writing modules, see the [Beginners Guide to Modules](/guides/module_guides/bgtm.html).
+* For more on best practices, methods, and approaches to writing modules, see the [Beginners Guide to Modules](./bgtm.html).
 
 ### Writing a Puppet module
 

@@ -14,7 +14,6 @@ title: "Puppet's commands"
 [master_man]: ./man/master.html
 [apply]: ./services_apply.html
 [apply_man]: ./man/apply.html
-[cert_man]: ./man/cert.html
 [puppet forge]: https://forge.puppetlabs.com
 [module fundamentals]: ./modules_fundamentals.html
 [installing modules]: ./modules_installing.html
@@ -28,8 +27,7 @@ title: "Puppet's commands"
 [config_man]: ./man/config.html
 [parser_man]: ./man/parser.html
 [help_man]: ./man/help.html
-[man_man]: ./man/man.html
-[all_manpages]: ./man/
+[all_manpages]: ./man/overview.html
 [about_server]: /openvox-server/latest/services_master_puppetserver.html
 [server_vs_passenger]: /openvox-server/latest/puppetserver_vs_passenger.html
 [subcommands]: /openvox-server/latest/subcommands.html
@@ -65,7 +63,6 @@ For more information, see:
 * [Puppet Server][about_server]
 * [Puppet Server vs. Apache/Passenger master][server_vs_passenger]
 * [Puppet Server Subcommands][subcommands]
-* [Puppet Master's Man Page][master_man]
 
 ### Puppet apply
 
@@ -79,14 +76,6 @@ For more information, see:
 
 ## Administrative tools
 
-### Puppet cert
-
-Puppet cert helps manage Puppet's built-in certificate authority (CA). It runs on the same server as the Puppet master application. You can use it to sign and revoke agent certificates.
-
-For more information, see:
-
-* [Puppet Cert's Man Page][cert_man]
-
 ### Puppet module
 
 Puppet module is a multi-purpose tool for working with Puppet modules. It can install and upgrade new modules from the [Puppet Forge][], help generate new modules, and package modules for public release.
@@ -135,7 +124,6 @@ Puppet help and Puppet man can display online help for Puppet's other subcommand
 For more information, see:
 
 * [Puppet Help's Man Page][help_man]
-* [Puppet Man's Man Page][man_man]
 
 ## Full list of subcommands
 

@@ -13,7 +13,6 @@ title: "Running Puppet's commands on Windows"
 [puppet resource]: ./man/resource.html
 [puppet config]: ./man/config.html
 [puppet help]: ./man/help.html
-[puppet man]: ./man/man.html
 [puppet lookup]: ./man/lookup.html
 
 Puppet was originally designed to run on \*nix systems, so its commands generally act the way \*nix admins expect.
@@ -33,7 +32,6 @@ The following commands are designed for use on Windows:
 - [puppet config][]
 - [puppet lookup][]
 - [puppet help][]
-- [puppet man][]
 
 ## Running Puppet's commands
 

@@ -19,7 +19,7 @@ title: "Subsystems: Catalog compilation"
 [plain_node]: ./indirection.html#plain-terminus
 [exec_node]: ./indirection.html#exec-terminus
 [ldap_node]: ./indirection.html#ldap-terminus
-[ldap_guide]: /guides/ldap_nodes.html
+[ldap_guide]: ./nodes_ldap.html
 [trusted_on]: ./config_important_settings.html#getting-new-features-early
 [facts_builtin]: ./lang_facts_and_builtin_vars.html
 [node definitions]: ./lang_node_definitions.html

@@ -11,7 +11,7 @@ title: "Background Reference: X.509 Certificate Anatomy"
 [ssldir]: /puppet/latest/reference/dirs_ssldir.html
 [certname]: /puppet/latest/reference/configuration.html#certname
 [lang_node]: /puppet/latest/reference/lang_node_definitions.html
-[enc]: /guides/external_nodes.html
+[enc]: /openvox/latest/nodes_external.html
 [index]: ./index.html
 [ca_name]: /puppet/latest/reference/configuration.html#caname
 [wiki_x509]: http://en.wikipedia.org/wiki/X.509

@@ -116,7 +116,7 @@ In Puppet's default configuration, a CA will be automatically created the first
 The Puppet CA consists of the following components:
 
 * Several HTTPS services provided by the puppet master, which accept incoming CSRs and serve the CA cert, the CRL, and signed certificates.
-    * Note that in sites with more than one puppet master server, only one should act as the CA. This is covered in [the guide to configuring multiple masters](/guides/scaling_multiple_masters.html#centralize-the-certificate-authority).
+    * Note that in sites with more than one puppet master server, only one should act as the CA. This is covered in [the guide to configuring multiple masters](/openvox-server/latest/scaling_puppet_server.html).
 * The CA's on-disk files, which include the CA certificate, the CA private key, any stored CSRs, an inventory of previously signed certificates (as well as copies of them), and the CRL.
 * Command-line tools for viewing pending CSRs and signing, examining, and revoking certificates.
 * Additional HTTPS services that allow certificates to be signed and revoked. (Since these can be dangerous, they are configured to be inaccessible by default.)

@@ -6,7 +6,6 @@ title: "Background Reference: What is HTTPS?"
 
 [index]: ./index.html
 [tls_ssl]: ./tls_ssl.html
-[passenger]: /guides/passenger.html
 [certificate_anatomy]: ./cert_anatomy.html
 
 > This article is [part of a series][index]. The previous article covered the basics of [the TLS/SSL protocol][tls_ssl].
@@ -51,7 +50,7 @@ In practice, though, other levels of an application will usually want access to
 
 Thus, most SSL implementations have some means to publish connection and certificate data, so it can be used by higher layers of the protocol stack.
 
-An example of this is Apache's `mod_ssl` module. If it's [configured with the `StdEnvVars` option](http://httpd.apache.org/docs/2.2/mod/mod_ssl.html#envvars), it will publish extensive SSL and certificate information as environment variables with predictable names. These variables can then be used by Apache itself, or by any application being spawned and managed by another Apache module (e.g. `mod_cgi`, `mod_passenger`, or `mod_php`). (This is how the puppet master accesses client certificate information when [running under Passenger][passenger].)
+An example of this is Apache's `mod_ssl` module. If it's [configured with the `StdEnvVars` option](http://httpd.apache.org/docs/2.2/mod/mod_ssl.html#envvars), it will publish extensive SSL and certificate information as environment variables with predictable names. These variables can then be used by Apache itself, or by any application being spawned and managed by another Apache module (e.g. `mod_cgi`, `mod_passenger`, or `mod_php`).
 
 SSL Termination and Proxying
 -----