Fix legacy /puppet/, /pe/, and /facter/ internal links in _openvox_8x

miharp · miharp · commit 2a1d9adf2890 · 2026-04-30T07:44:13.000-04:00
Rewrites /puppet/latest/report.html to /openvox/latest/report.html, removes links to deleted configuration.html and old puppet/3.8 docs, removes PE-only links and {{pe}} references with no OpenVox equivalent. Closes #121 Signed-off-by: Michael Harp <mike@mikeharp.com>
diff --git a/docs/_openvox_8x/lang_template_epp.md b/docs/_openvox_8x/lang_template_epp.md
@@ -4,9 +4,9 @@ title: "Language: Embedded Puppet (EPP) template syntax"
 ---
 
 [erb]: ./lang_template_erb.html
-[epp]: /puppet/latest/function.html#epp
+[epp]: /openvox/latest/function.html#epp
+[inline_epp]: /openvox/latest/function.html#inline_epp
 [ntp]: https://forge.puppetlabs.com/puppetlabs/ntp
-[inline_epp]: /puppet/latest/function.html#inlineepp
 [functions]: ./lang_functions.html
 [hash]: ./lang_data_hash.html
 [local scope]: ./lang_scope.html
@@ -16,7 +16,7 @@ title: "Language: Embedded Puppet (EPP) template syntax"
 [variable_names]: ./lang_variables.html#naming
 [typed]: ./lang_data_type.html
 
-Embedded Puppet (EPP) is a templating language based on the [Puppet language](./lang_summary.html). You can use EPP in Puppet 4 and higher, as well as Puppet 3.5 through 3.8 with the [future parser](/puppet/3.8/experiments_future.html) enabled.
+Embedded Puppet (EPP) is a templating language based on the [Puppet language](./lang_summary.html). You can use EPP in Puppet 4 and higher, as well as Puppet 3.5 through 3.8 with the future parser enabled.
 
 Puppet can evaluate EPP templates with the [`epp`][epp] and [`inline_epp`][inline_epp] functions.
 
@@ -187,7 +187,7 @@ A template works like a [defined type][]:
 * When you call the template (with the [`epp`][epp] or [`inline_epp`][inline_epp] functions), you can use parameters to set variables in its local scope.
 * Unlike erb templates, epp templates cannot directly access variables in the calling class without namespacing. Fully qualify variables or pass them in as parameters.
 
-This means templates can use short names to access global variables (like `$os` or `$trusted`) and their own local variables, but must use qualified names (like `$ntp::tinker`) to access variables from any class. (With one exception for `inline_epp`; [see below](#special-scope-rule-for-inlineepp).)
+This means templates can use short names to access global variables (like `$os` or `$trusted`) and their own local variables, but must use qualified names (like `$ntp::tinker`) to access variables from any class. (With one exception for `inline_epp`; [see below](#special-scope-rule-for-inline_epp).)
 
 ### Parameters
 
diff --git a/docs/_openvox_8x/metaparameter.md b/docs/_openvox_8x/metaparameter.md
@@ -302,6 +302,4 @@ Multiple tags can be specified as an array:
     }
 
 Tags are useful for things like applying a subset of a host's configuration
-with [the `tags` setting](/puppet/latest/configuration.html#tags)
-(e.g. `puppet agent --test --tags bootstrap`).
-
+with the `tags` setting (e.g. `puppet agent --test --tags bootstrap`).
diff --git a/docs/_openvox_8x/nodes_ldap.md b/docs/_openvox_8x/nodes_ldap.md
@@ -5,7 +5,6 @@ title: "The LDAP Node Classifier"
 
 [class parameters]: ./lang_classes.html#class-parameters-and-variables
 [hiera]: ./hiera_intro.html
-[rp]: {{pe}}/r_n_p_intro.html
 [custom hiera backend]: ./hiera_custom_backends.html
 [environment]: ./environments.html
 [node definitions]: ./lang_node_definitions.html
@@ -29,11 +28,11 @@ There are some benefits to storing node data in LDAP instead of using [node defi
 -   All attributes on the LDAP nodes are assigned as variables in the Puppet configuration, just like facts.
 -   It is straightforward for other applications to modify LDAP data to configure nodes (for example, as part of a deployment process), which is easier to support than generating Puppet code.
 
-**However.** This LDAP integration was written for a very different world, before Puppet had [class parameters][] or [data lookup with Hiera][hiera], and before modern best practices like [the roles and profiles method][RP] were developed. Dinosaurs walked the earth, and you configured your Puppet classes by setting top-scope variables in the node definition.
+**However.** This LDAP integration was written for a very different world, before Puppet had [class parameters][] or [data lookup with Hiera][hiera], and before modern best practices like the roles and profiles method were developed. Dinosaurs walked the earth, and you configured your Puppet classes by setting top-scope variables in the node definition.
 
 You can probably still use this effectively, but please consider the following:
 
-* With an antique interface like this, [the roles and profiles method][RP] is even more of a best practice than it is elsewhere. Since LDAP attributes can't configure class parameters, they're not suited for building full configurations out of component modules, so you should be hiding most of your complexity with wrapper classes, doing data lookup via Hiera, and only using LDAP to assign role classes.
+* With an antique interface like this, the roles and profiles method is even more of a best practice than it is elsewhere. Since LDAP attributes can't configure class parameters, they're not suited for building full configurations out of component modules, so you should be hiding most of your complexity with wrapper classes, doing data lookup via Hiera, and only using LDAP to assign role classes.
 * Depending on where that LDAP data is coming from, it might make more sense to go right to the source and write a [custom Hiera backend][] that can access your business's configuration data. In fact, writing an LDAP-based Hiera backend might make more sense than using this rigid 0.2x-era interface.
 
 ## Prerequisites
diff --git a/docs/_openvox_8x/reporting_about.md b/docs/_openvox_8x/reporting_about.md
@@ -3,9 +3,6 @@ layout: default
 title: "About reporting"
 ---
 
-[report]: /puppet/latest/configuration.html#report
-[reports]: /puppet/latest/configuration.html#reports
-[reportdir]: /puppet/latest/configuration.html#reportdir
 [puppet.conf]: ./config_file_main.html
 
 Puppet creates a report about its actions and your infrastructure each time it applies a catalog during a Puppet run. You can create and use report processors to generate insightful information or alerts from
@@ -26,18 +23,18 @@ That external service can then provide a way to view the processed report.
 
 ## Configuring reporting
 
-A Puppet agent sends reports by default. You can turn off reporting by changing the [`report`][report] setting in an agent's [`puppet.conf`][puppet.conf].
+A Puppet agent sends reports by default. You can turn off reporting by changing the `report` setting in an agent's [`puppet.conf`][puppet.conf].
 
-On Puppet master servers (and nodes running Puppet apply), you can configure enabled report processors as a comma-separated list in the [`reports`][reports] setting. The default `reports` value is 'store',
-which stores them in the configured [`reportdir`][reportdir]. You can also turn off reports entirely by setting `reports` to 'none'.
+On Puppet master servers (and nodes running Puppet apply), you can configure enabled report processors as a comma-separated list in the `reports` setting. The default `reports` value is 'store',
+which stores them in the configured `reportdir`. You can also turn off reports entirely by setting `reports` to 'none'.
 
 ## Practical reporting for beginners
 
-Puppet's reporting features are powerful, but there are simple ways to work with them. Puppet Enterprise includes [helpful reporting tools]({{pe}}/CM_reports.html) in the console. [PuppetDB](/openvoxdb/latest/),
+Puppet's reporting features are powerful, but there are simple ways to work with them. [PuppetDB](/openvoxdb/latest/),
 with [its report processor enabled](/openvoxdb/latest/connect_puppet_master.html#enabling-report-storage), can interface with third-party tools such as [Puppetboard](https://github.com/puppet-community/puppetboard)
 or [PuppetExplorer](https://github.com/spotify/puppetexplorer).
 
-Puppet has several basic built-in [report processors](/puppet/latest/report.html). For example, the `http` processor sends YAML dumps of reports via POST requests to a designated URL, while `log` saves received
+Puppet has several basic built-in [report processors](/openvox/latest/report.html). For example, the `http` processor sends YAML dumps of reports via POST requests to a designated URL, while `log` saves received
 logs to a local log file.
 
 Certain Puppet modules --- for instance, [`tagmail`](https://forge.puppetlabs.com/puppetlabs/tagmail) --- add additional report processors. Each module has its own requirements, such as Ruby gems, operating
diff --git a/docs/_openvox_8x/static_catalogs.md b/docs/_openvox_8x/static_catalogs.md
@@ -25,9 +25,6 @@ title: "Static catalogs"
 
 [Puppet Server]: /openvox-server/latest/
 [`puppetserver.conf`]: /openvox-server/latest/config_file_puppetserver.html
-[Application Orchestration]: {{pe}}/app_orchestration_overview.html
-[file sync]: {{pe}}/cmgmt_filesync.html
-[Code Manager]: {{pe}}/code_mgr.html
 [`code_content`]: /openvox-server/latest/
 Puppet 4.4 and Puppet Server 2.3 introduced a new feature for [catalog compilation][catalogs]: **static catalogs**.
 

Original file line number	Diff line number	Diff line change
`@@ -302,6 +302,4 @@ Multiple tags can be specified as an array:`
`302`	`302`	`}`
`303`	`303`
`304`	`304`	`Tags are useful for things like applying a subset of a host's configuration`
`305`		-with [the `tags` setting](/puppet/latest/configuration.html#tags)
`306`		-(e.g. `puppet agent --test --tags bootstrap`).
`307`		`-`
	`305`	+with the `tags` setting (e.g. `puppet agent --test --tags bootstrap`).