DP-58: Fix internal HTTP links

DP-58: Fix internal HTTP links - updated internal HTTP links that should have been HTTPS.
DP-57: Add meta descriptions to each page in the deployment guide - added meta descriptions for each page in the deployment guide for better SEO. Did not add meta tag for pages that do not have H1, as these will be excluded in a future Jira.

docs/modules/deployment/pages/minion/introduction.adoc

@@ -1,6 +1,6 @@
 
 = Minion
-:description: Learn about the OpenNMS Minion: benefits, how it works, with architecture diagram with three Minions.
+:description: Learn about the OpenNMS Minion: benefits, how it works. Includes architecture diagram with three Minions.
 
 A Minion is an instance of the Karaf OSGi runtime that enables {page-component-title} to monitor devices and services in locations that it otherwise cannot reach.
 Minions communicate with these remote devices while {page-component-title} performs coordination and task delegation.

docs/modules/deployment/pages/opentracing/core.adoc

@@ -1,3 +1,4 @@
+
 Enable tracing with Jaeger on Core instance by installing the `opennms-core-tracing-jaeger` feature and creating a configuration file with the Jaeger specific settings.
 
 NOTE: Configurations has to be made in the `etc` directory relative to the {page-component-title} Core home directory.

docs/modules/deployment/pages/opentracing/jaeger-tracing.adoc

@@ -1,13 +1,15 @@
-= Setting up Jaeger Tracing
+= Set up Jaeger Tracing
+
+:description: How to set up Jaeger tracing (OpenTracing) on an OpenNMS Core instance, Minion, or Sentinel.
 
 OpenTracing enables distributed tracing which makes it possible to monitor RPCs or transactions across process boundaries.
-You can leverage this functionality to help track and diagnose communication problems that may arise in distributed deployments of _{page-component-title}_ components; for example, Core instance, Minion, and/or Sentinel.
+You can leverage this functionality to help track and diagnose communication problems that may arise in distributed deployments of {page-component-title} components; for example, Core instance, Minion, and Sentinel.
 OpenTracing is supported on RPC calls between {page-component-title} Core instance for Sink API calls (including flows) between Minion and Sentinel.
 By default the tracing instrumentation {page-component-title} is disabled (a no-op tracer is used.)
 
 The project Jaeger is an open source, end-to-end distributed tracing software.
 It lets you monitor and troubleshoot transactions in distributed software components when {page-component-title} is deployed with Minion and Sentinel.
-_{page-component-title}_ components support link:https://www.jaegertracing.io/[Jaeger] which implements the OpenTracing API.
+{page-component-title} components support link:https://www.jaegertracing.io/[Jaeger] which implements the OpenTracing API.
 
 [{tabs}]
 ====

docs/modules/deployment/pages/sentinel/introduction.adoc

@@ -1,4 +1,12 @@
 = Sentinel
+:description: Scale your network monitoring with OpenNMS Sentinel and support streaming telemetry with OpenNMS Newts on RHEL, CentOS, Debian, and Ubuntu.
+
+[[objectives]]
+== Objectives
+
+* Setting up a {page-component-title} Sentinel running on one of the following <<minion/system-requirements.adoc#operating-systems-Core, Operating Systems>>
+* Secure access with encrypted passwords to the Karaf shell
+* Sentinel can be configured with the Karaf Shell from th
 
 Sentinel provides scalability for data processing of flows and streaming telemetry received by one or more Minions.
 It also supports thresholding for streaming telemetry if you are using OpenNMS xref:deployment:time-series-storage/newts/introduction.adoc#ga-opennms-operation-newts[Newts].

docs/modules/deployment/pages/sentinel/runtime/install.adoc

@@ -1,5 +1,6 @@
 [[install-sentinel]]
-= Installing Sentinel Runtime
+= Install Sentinel Runtime
+:description: Set up OpenNMS Sentinel (for scaling and streaming telemetry) on RHEL, CentOS, Debian, and Ubuntu.
 
 [[objectives]]
 == Objectives

docs/modules/deployment/pages/time-series-storage/newts/cassandra-jmx.adoc

@@ -1,6 +1,7 @@
 
 [[cassandra-monitor]]
 = Cassandra Monitoring
+:description: Metrics OpenNMS collects from a Cassandra cluster: client connections, thread pools, JVM metrics, dropped messages, and more.
 
 This section describes some of the metrics that {page-component-title} collects from a Cassandra cluster.
 JMX must be enabled on the Cassandra nodes and made accessible from {page-component-title} in order to collect these metrics (see https://docs.datastax.com/en/cassandra/3.0/cassandra/configuration/secureJmxAuthentication.html[Enabling JMX Authentication and Authorization] in the Cassandra documentation).

docs/modules/deployment/pages/time-series-storage/newts/cassandra-newts-jmx.adoc

@@ -1,6 +1,7 @@
 
 [[newts-monitor]]
 = Newts Monitoring
+:description: Metrics OpenNMS collects to monitor Newts on a Cassandra node: memtables data, latency, pending operations, disk space usage, and more.
 
 This section describes the metrics that {page-component-title} collects to monitor the Newts keyspace from `org.apache.cassandra.metrics.Keyspace` on a Cassandra node.
 

docs/modules/deployment/pages/time-series-storage/newts/configuration.adoc

@@ -1,6 +1,7 @@
 
 [[newts-reference]]
 = Configuration Reference
+:description: Configuration properties for OpenNMS Newts, a time-series data store based on Apache Cassandra, for horizontal scaling.
 
 Use the following properties, found in `$\{OPENNMS_HOME}/etc/opennms.properties`, to configure Newts.
 

docs/modules/deployment/pages/time-series-storage/newts/introduction.adoc

@@ -1,6 +1,7 @@
 
 [[ga-opennms-operation-newts]]
 = Newts
+:description: Introduction to OpenNMS Newts, a time-series data store based on Apache Cassandra, for horizontal scaling.
 
 link:http://newts.io/[Newts] is a time series data schema for link:http://cassandra.apache.org/[Apache Cassandra].
 It enables link:https://en.wikipedia.org/wiki/Scalability#Horizontal[horizontal scaling] for your time series database and is an alternative to link:https://github.com/OpenNMS/jrobin[JRobin] and link:http://oss.oetiker.ch/rrdtool/[RRDtool].

docs/modules/deployment/pages/time-series-storage/newts/newts-repository-converter.adoc

@@ -1,7 +1,8 @@
 
 = RRD/JRB to Newts Migration Utility
+:description: Learn how to migrate existing RRDtool or JRobin-based data to an OpenNMS Newts time series database schema.
 
-Use this utility to migrate existing RRDTool- or JRobin-based data to a Newts cluster.
+Use this utility to migrate existing RRDtool- or JRobin-based data to a Newts cluster.
 The migration process traverses the `$\{OPENNMS_HOME}/share/rrd` directory and its subdirectories, reads the data and properties files, and persists this data to Newts.
 
 == Migration

docs/modules/deployment/pages/time-series-storage/newts/newts.adoc

@@ -1,6 +1,7 @@
 
 [[newts-configure]]
 = Configure {page-component-title} to Use Newts
+:description: How to set up OpenNMS Newts, a time-series data store based on Apache Cassandra, for horizontal scaling.
 
 This section describes how to configure your {page-component-title} instance to use Newts.
 

docs/modules/deployment/pages/time-series-storage/newts/resourcecli.adoc

@@ -1,5 +1,6 @@
 
 = Resource Management Tool
+:description: How to use the OpenNMS resource management tool to delete the collected data from a Horizon or Meridian instance: RRDtool, JRobin, and Newts.
 
 The resource management tool, resourcecli, simplifies the process of listing or manually deleting a {page-component-title} instance's collected data (resources).
 With RRDTool- or JRobin-based storage, this process is easy: you simply traverse the `$\{OPENNMS_HOME}/share/rrd` directory and its subdirectories.

docs/modules/deployment/pages/time-series-storage/timeseries/configuration.adoc

@@ -1,5 +1,6 @@
 
 = Enable Time Series Integration Layer
+:description: How to configure OpenNMS Horizon or Meridian to use the time series integration layer to support other time series databases.
 
 Set the following property in `$\{OPENNMS_HOME}/etc/opennms.properties.d/timeseries.properties` to configure {page-component-title} to use the Time Series Integration Layer:
 

docs/modules/deployment/pages/time-series-storage/timeseries/cortex.adoc

@@ -1,5 +1,6 @@
 
 = Cortex Time Series Plugin
+:description: Configuration and deployment for the OpenNMS Cortex Time Series plugin via Karaf shel or CFG file.
 
 The Cortex Time Series plugin enables {page-component-title} to persist time series performance and latency data to Cortex.
 The plugin uses the xref:time-series-storage/timeseries/ts-integration-layer.adoc[time series storage integration layer] to convert metrics to a Prometheus model and delegate writes and reads to https://cortexmetrics.io/[Cortex].

docs/modules/deployment/pages/time-series-storage/timeseries/hosted-tss.adoc

@@ -1,6 +1,7 @@
 
 ifeval::["{page-component-title}" == "Meridian"]
 = OpenNMS Time Series DB
+:description: How to deploy the OpenNMS Time Series DB for a scalable time series database to store and persist performance metrics Meridian collects.
 
 The OpenNMS Time Series DB is a cloud-hosted service that provides a scalable time series database to store and persist performance metrics that {page-component-title} collects from monitored devices.
 

docs/modules/deployment/pages/time-series-storage/timeseries/rrdtool.adoc

@@ -1,9 +1,10 @@
 = RRDtool
+:description: Install and configure RRDtool for OpenNMS on RHEL, Centos, and Debian.
 
 Many open source applications use link:http://oss.oetiker.ch/rrdtool[RRDtool], which is the de-facto open standard for time series data.
 This section describes how to install RRDtool and how to configure your {page-component-title} Core instance to use it.
 
-WARNING: This guide does not cover data migration from JRobin to RRDTool.
+WARNING: This guide does not cover data migration from JRobin to RRDtool.
 
 Configurations must in the `etc` directory relative to the {page-component-title} Core home directory.
 Depending on your operating system, the home directory is `/usr/share/opennms` for Debian/Ubuntu or `/opt/opennms` for CentOS/RHEL.
@@ -37,12 +38,12 @@ rrd.binary=/usr/bin/rrdtool<5>
 
 <1> Set JNI RRD strategy class instead of JRobin.
 <2> Use the internal JRRD library.
-<3> Use the JRRD library to interface with RRDTool.
-<4> This is optional; use RRDTool to render graphs.
+<3> Use the JRRD library to interface with RRDtool.
+<4> This is optional; use RRDtool to render graphs.
 If unset, keep Backshift as default.
-<5> Path to the RRDTool binary file.
+<5> Path to the RRDtool binary file.
 
-TIP: If your RRDTool binary is not in `/usr/bin/rrdtool`, adjust the path in the following files: +
+TIP: If your RRDtool binary is not in `/usr/bin/rrdtool`, adjust the path in the following files: +
      `response-adhoc-graph.properties`, +
      `response-graph.properties`, +
      `snmp-adhoc-graph.properties`, +
@@ -60,7 +61,7 @@ sudo systemctl restart opennms
 find /opt/opennms/share/rrd -iname "*.rrd"
 ----
 
-NOTE: The first data collection creates RRDTool files with extension `.rrd`.
+NOTE: The first data collection creates RRDtool files with extension `.rrd`.
       JRobin files with extension `.jrb` are not updated.
       JRobin files are not deleted automatically.
       You must delete them manually.
@@ -93,12 +94,12 @@ rrd.binary=/usr/bin/rrdtool<5>
 
 <1> Set JNI RRD strategy class instead of JRobin.
 <2> Use the internal JRRD library.
-<3> Use the JRRD library to interface with RRDTool.
-<4> This is optional; use RRDTool to render graphs.
+<3> Use the JRRD library to interface with RRDtool.
+<4> This is optional; use RRDtool to render graphs.
 If unset, keep Backshift as default.
-<5> Path to the RRDTool binary file.
+<5> Path to the RRDtool binary file.
 
-TIP: If your RRDTool binary is not in `/usr/bin/rrdtool`, adjust the path in the following files: +
+TIP: If your RRDtool binary is not in `/usr/bin/rrdtool`, adjust the path in the following files: +
      `response-adhoc-graph.properties`, +
      `response-graph.properties`, +
      `snmp-adhoc-graph.properties`, +
@@ -116,7 +117,7 @@ sudo systemctl restart opennms
 find /opt/opennms/share/rrd -iname "*.rrd"
 ----
 
-NOTE: The first data collection creates RRDTool files with extension `.rrd`.
+NOTE: The first data collection creates RRDtool files with extension `.rrd`.
       JRobin files with extension `.jrb` are not updated.
       JRobin files are not deleted automatically.
       You must delete them manually.
@@ -148,12 +149,12 @@ rrd.binary=/usr/bin/rrdtool<5>
 
 <1> Set JNI RRD strategy class instead of JRobin.
 <2> Use the internal JRRD library.
-<3> Use the JRRD library to interface with RRDTool.
-<4> This is optional; use RRDTool to render graphs.
+<3> Use the JRRD library to interface with RRDtool.
+<4> This is optional; use RRDtool to render graphs.
 If unset, keep Backshift as default
-<5> Path to the RRDTool binary file.
+<5> Path to the RRDtool binary file.
 
-TIP: If your RRDTool binary is not in `/usr/bin/rrdtool`, adjust the path in the following files: +
+TIP: If your RRDtool binary is not in `/usr/bin/rrdtool`, adjust the path in the following files: +
      `response-adhoc-graph.properties`, +
      `response-graph.properties`, +
      `snmp-adhoc-graph.properties`, +
@@ -171,7 +172,7 @@ sudo systemctl restart opennms
 find /usr/share/opennms/share/rrd -iname "*.rrd"
 ----
 
-NOTE: The first data collection creates RRDTool files with extension `.rrd`.
+NOTE: The first data collection creates RRDtool files with extension `.rrd`.
       JRobin files with extension `.jrb` are not updated.
       JRobin files are not deleted automatically.
       You must delete them manually.

docs/modules/deployment/pages/time-series-storage/timeseries/time-series-storage.adoc

@@ -1,6 +1,7 @@
 
 [[time-series-storage]]
 = Time Series Database
+:description: Overview of OpenNMS time series database options: JRobin, RRDtool, Newts, ONMS Time Series DB (Meridian only). Plugins and parallel series writes.
 
 {page-component-title} stores performance data in a time series database (JRobin by default).
 For different scenarios you may want to use a different time series database.
@@ -13,13 +14,13 @@ The following implementations are installed by default:
 | Time Series Database  | Description
 
 | JRobin
-| JRobin is a clone of RRDTool written in Java and is the default time series database when you install {page-component-title}.
-It does not fully cover the latest RRDTool feature set.
+| JRobin is a clone of RRDtool written in Java and is the default time series database when you install {page-component-title}.
+It does not fully cover the latest RRDtool feature set.
 Data is stored on the local file system of the {page-component-title} node.
 Depending on I/O capabilities, it works well for small- to medium-size installations.
 
-| RRDTool
-| RRDTool is actively maintained and the de-facto standard for time series data.
+| RRDtool
+| RRDtool is actively maintained and the de-facto standard for time series data.
 Data is stored on the local file system of the {page-component-title} node.
 Depending on I/O capabilities it works well for small- to medium-size installations.
 
@@ -39,7 +40,7 @@ For more information, see xref:time-series-storage/timeseries/hosted-tss.adoc[].
 endif::[]
 |===
 
-This chapter describes how to configure {page-component-title} to use RRDTool, Newts, and the OpenNMS Time Series DB.
+This chapter describes how to configure {page-component-title} to use RRDtool, Newts, and the OpenNMS Time Series DB.
 
 == Time series database plugins
 

docs/modules/deployment/pages/time-series-storage/timeseries/ts-integration-layer.adoc

@@ -1,6 +1,7 @@
 
 [[ts-integration-layer]]
 = Time Series Integration Layer
+:description: Overview of OpenNMS Horizon or Meridian using the Time Series Integration Layer to support other time series databases (experimental): In Memory, InfluxDB, TimescaleDB, Cortex.
 
 This section describes how to configure {page-component-title} to use the Time Series Integration Layer.
 

docs/modules/deployment/pages/upgrade/backup/introduction.adoc

@@ -1,5 +1,6 @@
 [[backup]]
 = Back up OpenNMS {page-component-title}
+:description: How to backup OpenNMS Horizon or Meridian components.
 
 This section describes a basic backup process for a default OpenNMS {page-component-title} xref:deployment:core/getting-started.adoc#getting-started-core[installation].
 OpenNMS {page-component-title} binaries, logs, RRD archives, configurations, and the database are backed up during this process.

docs/modules/deployment/pages/upgrade/basic.adoc

@@ -1,6 +1,7 @@
 
 [[upgrade-basic]]
 = Basic Upgrade Steps
+:description: Basic steps to upgrade OpenNMS Horizon or Meridian, including PostgreSQL upgrade and configuration.
 
 This procedure describes how to do a basic {page-component-title} upgrade.
 You may need to complete additional steps to upgrade in a more complex setup (for example, if you run more than one {page-component-title} instance, have more complex database migration requirements, or depending on the age of current version).

docs/modules/deployment/pages/upgrade/diff.adoc

@@ -1,5 +1,6 @@
 [[run_diff]]
 = Identify Changed Configuration Files
+:description: How to identify changed configuration files during an OpenNMS Horizon or Meridian upgrade.
 
 During an upgrade, {page-component-title} overwrites configuration files, so any customization you may have done will be lost.
 You need to back up your customized configuration files so that you can merge them into your upgraded system.

docs/modules/deployment/pages/upgrade/git-diff.adoc

@@ -1,5 +1,6 @@
 [[git-diff]]
 = Manage Configuration Changes with Git
+:description: How to use Git to manage OpenNMS configuration file changes to assist with Horizon or Meridian upgrades.
 
 This content was originally written on the OpenNMS Discourse forum (see https://opennms.discourse.group/t/managing-configuration-changes-with-git/2327[Managing Configuration Changes with Git]).
 

docs/modules/deployment/pages/upgrade/git-upgrade.adoc

@@ -1,5 +1,6 @@
 [[git-upgrade]]
 = Upgrade {page-component-title} with Git
+:description: How to use Git to upgrade OpenNMS Horizon or Meridian.
 
 This content was originally written on the OpenNMS Discourse forum (see https://opennms.discourse.group/t/managing-configuration-changes-with-git/2327[Managing Configuration Changes with Git]).
 Follow the directions here to upgrade with Git if you xref:deployment:upgrade/git-diff.adoc#git-diff[use Git to manage configuration changes].

docs/modules/deployment/pages/upgrade/introduction.adoc

@@ -1,6 +1,7 @@
 
 [[upgrade]]
 = Upgrade {page-component-title}
+:description: Overview of OpenNMS Horizon or Meridian upgrade including before you begin and assessing events table size.
 
 This section outlines the basic steps that you should follow to upgrade to a newer version of {page-component-title}.
 You may need to complete additional steps to upgrade in a more complex setup (for example, if you run more than one OpenNMS instance, have more complex database migration requirements, and/or depending on the age of current version).

docs/modules/deployment/pages/upgrade/restore/introduction.adoc

@@ -1,5 +1,6 @@
 [[restore]]
 = Restore OpenNMS {page-component-title}
+:description: How to restore OpenNMS Horizon or Meridian components, including installing a PostgreSQL database and OpenJDK.
 
 This section describes a basic restore process for a default OpenNMS {page-component-title} xref:deployment:core/getting-started.adoc#getting-started-core[installation].
 OpenNMS {page-component-title} binaries, logs, RRD archives, configurations and the database will be restored.