Merge pull request #9230 from Icinga/feature/installation-instructions

Update installation instructions for easier navigation on icinga.com
This commit is contained in:
Alexander Aleksandrovič Klimov 2022-02-21 16:38:42 +01:00 committed by GitHub
commit db321b9fcb
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
21 changed files with 883 additions and 827 deletions

File diff suppressed because it is too large Load Diff

View File

@ -0,0 +1,3 @@
# Install Icinga 2 on Debian
<!-- {% set debian = True %} -->
<!-- {% include "02-installation.md" %} -->

View File

@ -0,0 +1,3 @@
# Install Icinga 2 on Ubuntu
<!-- {% set ubuntu = True %} -->
<!-- {% include "02-installation.md" %} -->

View File

@ -0,0 +1,3 @@
# Install Icinga 2 on Raspbian
<!-- {% set raspbian = True %} -->
<!-- {% include "02-installation.md" %} -->

View File

@ -0,0 +1,2 @@
<!-- {% set fedora = True %} -->
<!-- {% include "02-installation.md" %} -->

View File

@ -0,0 +1,3 @@
# Install Icinga 2 on CentOS
<!-- {% set centos = True %} -->
<!-- {% include "02-installation.md" %} -->

View File

@ -0,0 +1,3 @@
# Install Icinga 2 on RHEL
<!-- {% set rhel = True %} -->
<!-- {% include "02-installation.md" %} -->

View File

@ -0,0 +1,3 @@
# Install Icinga 2 on openSUSE
<!-- {% set opensuse = True %} -->
<!-- {% include "02-installation.md" %} -->

View File

@ -0,0 +1,3 @@
# Install Icinga 2 on SLES
<!-- {% set sles = True %} -->
<!-- {% include "02-installation.md" %} -->

View File

@ -0,0 +1,3 @@
# Install Icinga 2 on Amazon Linux
<!-- {% set amazon_linux = True %} -->
<!-- {% include "02-installation.md" %} -->

View File

@ -0,0 +1,3 @@
# Install Icinga 2 on Windows
<!-- {% set windows = True %} -->
<!-- {% include "02-installation.md" %} -->

View File

@ -1938,7 +1938,7 @@ The check command parameters for ITL provided plugin check command definitions a
In order to practice passing command parameters you should [integrate your own plugin](03-monitoring-basics.md#command-plugin-integration).
The following example will use `check_mysql` provided by the [Monitoring Plugins installation](02-installation.md#setting-up-check-plugins).
The following example will use `check_mysql` provided by the [Monitoring Plugins](https://www.monitoring-plugins.org/).
Define the default check command custom variables, for example `mysql_user` and `mysql_password`
(freely definable naming schema) and optional their default threshold values. You can

View File

@ -196,7 +196,7 @@ The `constants.conf` configuration file can be used to define global constants.
By default, you need to make sure to set these constants:
* The `PluginDir` constant must be set to the path where the [Monitoring Project plugins](02-installation.md#setting-up-check-plugins) are installed.
* The `PluginDir` constant must be set to the path where the [Monitoring Project](https://www.monitoring-plugins.org/) plugins are installed.
This constant is used by a number of
[built-in check command definitions](10-icinga-template-library.md#icinga-template-library).
* The `NodeName` constant defines your local node name. Should be set to FQDN which is the default
@ -304,7 +304,7 @@ service apply rule defined in [services.conf](04-configuration.md#services-conf)
* define notification types (`mail`) and set the groups attribute. This
will be used by notification apply rules in [notifications.conf](04-configuration.md#notifications-conf).
If you've installed [Icinga Web 2](02-installation.md#setting-up-icingaweb2), you can
If you've installed [Icinga Web 2](https://icinga.com/docs/icinga-web-2/latest/doc/02-Installation/), you can
uncomment the http vhost attributes and reload Icinga 2. The apply
rules in [services.conf](04-configuration.md#services-conf) will automatically
generate a new service checking the `/icingaweb2` URI using the `http`
@ -515,8 +515,7 @@ Look into [notifications.conf](04-configuration.md#notifications-conf) how this
for applying notifications to hosts and services using their type and user
attributes.
Don't forget to install the [check plugins](02-installation.md#setting-up-check-plugins) required by
the hosts and services and their check commands.
Don't forget to install the check plugins required by the hosts and services and their check commands.
Further details on the monitoring configuration can be found in the
[monitoring basics](03-monitoring-basics.md#monitoring-basics) chapter.

View File

@ -44,8 +44,8 @@ simple examples.
In case you are planning a huge cluster setup with multiple levels and
lots of satellites and agents, read on -- we'll deal with these cases later on.
The installation on each system is the same: You need to install the
[Icinga 2 package](02-installation.md#setting-up-icinga2) and the required [plugins](02-installation.md#setting-up-check-plugins).
The installation on each system is the same: Follow the [installation instructions](02-installation.md)
for the Icinga 2 package and the required check plugins.
The required configuration steps are mostly happening
on the command line. You can also [automate the setup](06-distributed-monitoring.md#distributed-monitoring-automation).
@ -238,9 +238,8 @@ This section explains how to install a central single master node using
the `node wizard` command. If you prefer to do an automated installation, please
refer to the [automated setup](06-distributed-monitoring.md#distributed-monitoring-automation) section.
Install the [Icinga 2 package](02-installation.md#setting-up-icinga2) and setup
the required [plugins](02-installation.md#setting-up-check-plugins) if you haven't done
so already.
Follow the [installation instructions](02-installation.md) for the Icinga 2 package and the required
check plugins if you haven't done so already.
**Note**: Windows is not supported for a master node setup.
@ -304,7 +303,7 @@ Now restart your Icinga 2 daemon to finish the installation!
```
You can verify that the CA public and private keys are stored in the `/var/lib/icinga2/ca` directory.
Keep this path secure and include it in your [backups](02-installation.md#install-backup).
Keep this path secure and include it in your backups.
In case you lose the CA private key you have to generate a new CA for signing new agent/satellite
certificate requests. You then have to also re-create new signed certificates for all
@ -512,9 +511,8 @@ Icinga 2 on the master node must be running and accepting connections on port `5
Please ensure that you've run all the steps mentioned in the [agent/satellite section](06-distributed-monitoring.md#distributed-monitoring-setup-agent-satellite).
Install the [Icinga 2 package](02-installation.md#setting-up-icinga2) and setup
the required [plugins](02-installation.md#setting-up-check-plugins) if you haven't done
so already.
Follow the [installation instructions](02-installation.md) for the Icinga 2 package and the required
check plugins if you haven't done so already.
The next step is to run the `node wizard` CLI command.
@ -3187,7 +3185,7 @@ to pick the authoritative running one and copy the following content:
If you need already deployed config packages from the Director, or synced cluster zones,
you can also sync the entire `/var/lib/icinga2/api/packages` directory. This directory should also be
included in your [backup strategy](02-installation.md#install-backup).
included in your backup strategy.
Do **not** sync `/var/lib/icinga2/api/zones*` manually - this is an internal directory
and handled by the Icinga cluster config sync itself.

View File

@ -64,7 +64,7 @@ an arbitrary plugin command line. The output and exit code is
returned and used by the core.
The `check_by_ssh` plugin takes care of this. It is available in the
[Monitoring Plugins package](02-installation.md#setting-up-check-plugins).
[Monitoring Plugins](https://www.monitoring-plugins.org/) package.
For your convenience, the Icinga template library provides the [by_ssh](10-icinga-template-library.md#plugin-check-command-by-ssh)
CheckCommand already.
@ -171,7 +171,7 @@ A more advanced example with better arguments is shown in [this blogpost](https:
## SNMP <a id="agent-based-checks-snmp"></a>
The SNMP daemon runs on the remote system and answers SNMP queries by plugin scripts.
The [Monitoring Plugins package](02-installation.md#setting-up-check-plugins) provides
The [Monitoring Plugins](https://www.monitoring-plugins.org/) package provides
the `check_snmp` plugin binary, but there are plenty of [existing plugins](05-service-monitoring.md#service-monitoring-plugins)
for specific use cases already around, for example monitoring Cisco routers.
@ -483,5 +483,3 @@ Community examples:
* [Icinga 2 check_wmi_plus example by 18pct](https://18pct.com/icinga2-check_wmi_plus-example/)
* [Agent-less monitoring with WMI](https://www.devlink.de/linux/icinga2-nagios-agentless-monitoring-von-windows/)

View File

@ -63,7 +63,7 @@ Requirements:
* IcingaDB service requires Redis and MySQL/MariaDB server
* Icinga Web module
Consult the [Icinga DB section](02-installation.md#configuring-icinga-db) in the installation chapter for setup instructions.
Consult the [Icinga DB installation documentation](https://icinga.com/docs/icinga-db/latest/doc/02-Installation/) for setup instructions.
We will deprecate the IDO and shift towards the Icinga DB as main backend,
but we will not drop the IDO for now.
@ -77,8 +77,8 @@ The IDO (Icinga Data Output) feature for Icinga 2 takes care of exporting all
configuration and status information into a database. The IDO database is used
by Icinga Web 2 as data backend.
Details on the installation can be found in the [Configuring DB IDO](02-installation.md#configuring-db-ido-mysql)
chapter. Details on the configuration can be found in the
Details on the installation can be found in the "Prepare for Icinga Web 2" chapter
of the [Installation docs](02-installation.md). Details on the configuration can be found in the
[IdoMysqlConnection](09-object-types.md#objecttype-idomysqlconnection) and
[IdoPgsqlConnection](09-object-types.md#objecttype-idopgsqlconnection)
object configuration documentation.
@ -705,7 +705,7 @@ Functionality exists to modify the built in OpenTSDB metric names that the plugi
writes to. By default this is `icinga.host` and `icinga.service.<servicename>`.
These prefixes can be modified as necessary to any arbitary string. The prefix
configuration also supports Icinga macros, so if you rather use `<checkcommand>`
configuration also supports Icinga macros, so if you rather use `<checkcommand>`
or any other variable instead of `<servicename>` you may do so.
To configure OpenTSDB metric name prefixes, create or modify the `host_template` and/or
@ -847,16 +847,16 @@ what attributes are available with links to each object type.
> Ensure you do not name your custom attributes with a dot in the name.
> Dots located inside a macro tell the interpreter to expand a
> dictionary.
>
>
> Do not do this in your object configuration:
>
>
> `vars["my.attribute"]`
>
>
> as you will be unable to reference `my.attribute` because it is not a
> dictionary.
>
>
> Instead, use underscores or another character:
>
>
> `vars.my_attribute` or `vars["my_attribute"]`
@ -1069,7 +1069,7 @@ Livestatus.
>
> Only install the Livestatus feature if your web interface or addon requires
> you to do so.
> [Icinga Web 2](02-installation.md#setting-up-icingaweb2) does not need
> [Icinga Web 2](https://icinga.com/docs/icinga-web-2/latest/doc/02-Installation/) does not need
> Livestatus.
Details on the available tables and attributes with Icinga 2 can be found

View File

@ -856,7 +856,7 @@ $ ICINGA2_API_PASSWORD=icinga icinga2 console --connect 'https://root@localhost:
"icinga2-agent1.localdomain"
```
Whenever a notification command failed to execute, you can fetch the output as well.
Whenever a notification command failed to execute, you can fetch the output as well.
## Feature Troubleshooting <a id="troubleshooting-features"></a>
@ -1745,7 +1745,7 @@ object Endpoint "icinga-satellite2.localdomain" {
// That's no different to what is explained in the docs as basic zone trust hierarchy, and is intentionally managed outside in zones.conf there.
object Zone "master" {
endpoints = [ "icinga-master1.localdomain", "icinga-master2.localdomain" ]
endpoints = [ "icinga-master1.localdomain", "icinga-master2.localdomain" ]
}
object Zone "satellite" {
@ -1754,21 +1754,21 @@ object Zone "satellite" {
}
```
Prepare the above configuration on all affected nodes, satellites are likely uptodate already.
Prepare the above configuration on all affected nodes, satellites are likely uptodate already.
Then continue with the steps below.
> * backup your database, just to be on the safe side
> * create all non-external Zone/Endpoint-Objects on all related Icinga Master/Satellite-Nodes (manually in your local zones.conf)
> * while doing so please do NOT restart Icinga, no deployments
> * change the type in the Director DB:
>
>
> ```sql
> UPDATE icinga_zone SET object_type = 'external_object' WHERE object_type = 'object';
> UPDATE icinga_endpoint SET object_type = 'external_object' WHERE object_type = 'object';
> ```
>
>
> * render and deploy a new configuration in the Director. It will state that there are no changes. Ignore it, deploy anyways
>
>
> That's it. All nodes should automatically restart, triggered by the deployed configuration via cluster protocol.
@ -1788,7 +1788,7 @@ certificate's CN, the master will deny all events.
> **Tip**
>
> [Icinga Web 2](02-installation.md#setting-up-icingaweb2) provides a dashboard view
> [Icinga Web 2](https://icinga.com/docs/icinga-web-2/latest/doc/01-About/) provides a dashboard view
> for overdue check results.
Enable the [debug log](15-troubleshooting.md#troubleshooting-enable-debug-output) on the master

View File

@ -120,11 +120,12 @@ details, please continue reading in [this issue](https://github.com/Icinga/icing
Distribution | Repository providing Boost Dependencies
---------------------|-------------------------------------
RHEL/CentOS 7 | [EPEL repository](02-installation.md#package-repositories-rhel-epel)
CentOS 7 | [EPEL repository](02-installation.md#centos-repository)
RHEL 7 | [EPEL repository](02-installation.md#rhel-repository)
RHEL/CentOS 6 x64 | [packages.icinga.com](https://packages.icinga.com)
Fedora | Fedora Upstream
Debian 10 Buster | Debian Upstream
Debian 9 Stretch | [Backports repository](02-installation.md#package-repositories-debian-backports) **New since 2.11**
Debian 9 Stretch | [Backports repository](02-installation.md#debian-backports-repository) **New since 2.11**
Debian 8 Jessie | [packages.icinga.com](https://packages.icinga.com)
Ubuntu 18 Bionic | [packages.icinga.com](https://packages.icinga.com)
Ubuntu 16 Xenial | [packages.icinga.com](https://packages.icinga.com)

View File

@ -539,7 +539,7 @@ on GitHub and mention that you're testing the snapshot packages.
#### RHEL/CentOS <a id="development-tests-snapshot-packages-rhel"></a>
2.11+ requires the [EPEL repository](02-installation.md#package-repositories-rhel-epel) for Boost 1.66+.
2.11+ requires the EPEL repository for Boost 1.66+.
In addition to that, the `icinga-rpm-release` package already provides the `icinga-snapshot-builds`
repository but it is disabled by default.
@ -1436,7 +1436,7 @@ vim /usr/local/icinga2/etc/icinga2/conf.d/api-users.conf
Debian Buster doesn't need updated Boost packages from packages.icinga.com,
the distribution already provides 1.66+. For older versions such as Stretch,
include the release repository for packages.icinga.com as shown in the [setup instructions](02-installation.md#package-repositories-debian-ubuntu-raspbian).
include the release repository for packages.icinga.com as shown in the [setup instructions](02-installation.md).
```bash
docker run -ti debian:buster bash
@ -2696,4 +2696,3 @@ the duplicate import in your `~/.gdbinit` file.
```
RuntimeError: pretty-printer already registered: libstdc++-v6
```

Binary file not shown.

Before

Width:  |  Height:  |  Size: 50 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 32 KiB