Merge pull request #126 from miharp/fix/legacy-links-121

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

Author: tuxmea

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
 

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