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

docs/_openvox_8x/lang_template_epp.md

@@ -4,10 +4,10 @@
 ---
 
 [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
 [node definition]: ./lang_node_definitions.html
@@ -16,7 +16,7 @@
 [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.
 
@@ -51,22 +51,22 @@
 <% } -%>
 ```
 
 An EPP template looks like a plain-text document interspersed with tags containing Puppet expressions. When evaluated, these tagged expressions can modify text in the template. You can use Puppet [variables][] in an EPP template to customize its output.
 
 ## Tags
 
 EPP has two tags for Puppet code, optional tags for parameters and comments, and a way to escape tag delimiters.
 
 * `<%= EXPRESSION %>` --- Inserts the value of a single expression.
     * With `-%>` --- Trims any trailing spaces and up to one following line break.
 * `<% EXPRESSION %>` --- Executes any expressions, but does not insert a value.
     * With `<%-` --- Trims the preceding indentation.
     * With `-%>` --- Trims any trailing spaces and up to one following line break.
 * `<% | PARAMETERS | %>` --- Declares the template's parameters.
     * With `<%-` --- Trims the preceding indentation.
     * With `-%>` --- Trims any trailing spaces and up to one following line break.
 * `<%# COMMENT %>` --- Removed from the final output.
     * With `-%>` --- Trims any trailing spaces and up to one following line break.
 * `<%%` or `%%>` --- A literal `<%` or `%>`, respectively.
 
 Text outside a tag becomes literal text, but it is subject to any tagged Puppet code surrounding it. For example, text surrounded by a tagged `if` statement only appears in the output if the condition is true.
@@ -75,7 +75,7 @@
 
 `<%= $fqdn %>`
 
 An expression-printing tag inserts the value of a single [Puppet expression](./lang_expressions.html) into the output. It starts with an opening tag delimiter and equals sign (`<%=`) and ends with a closing tag delimiter (`%>`). It must contain any single Puppet expression that resolves to a value, including plain variables, [function calls](./lang_functions.html), and arithmetic expressions. If the value isn't a string, Puppet automatically converts it to a string based on the [rules for value interpolation in double-quoted strings](./lang_data_string.html#conversion-of-interpolated-values).
 
 All facts are available in EPP templates. For example, to insert the value of the `fqdn` and `hostname` facts in an EPP template for an Apache config file, you could do something like:
 
@@ -133,7 +133,7 @@
 
 A parameter tag declares which parameters the template will accept. Each parameter can be [typed][] and can have a default value.
 
 The parameter tag is optional; if used, it **must** be the first content in a template. The parameter tag should always close with a right-trimmed delimiter (`-%>`) to avoid outputting a blank line. Literal text, line breaks, and non-comment tags cannot precede the template's parameter tag. (Comment tags that precede a parameter tag must use the right-trimming tag to trim trailing whitespace.)
 
 The parameter tag's pair of pipe characters (`|`) should contain a comma-separated list of parameters. Each parameter follows this format:
 
@@ -187,7 +187,7 @@
 * 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
 

docs/_openvox_8x/metaparameter.md

@@ -302,6 +302,5 @@ 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)
+with [the `tags` setting](/openvox/latest/configuration.html#tags)
 (e.g. `puppet agent --test --tags bootstrap`).
-

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

docs/_openvox_8x/reporting_about.md

@@ -3,9 +3,9 @@ layout: default
 title: "About reporting"
 ---
 
-[report]: /puppet/latest/configuration.html#report
-[reports]: /puppet/latest/configuration.html#reports
-[reportdir]: /puppet/latest/configuration.html#reportdir
+[report]: /openvox/latest/configuration.html#report
+[reports]: /openvox/latest/configuration.html#reports
+[reportdir]: /openvox/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
@@ -33,11 +33,11 @@ which stores them in the configured [`reportdir`][reportdir]. You can also turn
 
 ## 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

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**.