2017-09-07 17:01:25 +02:00
# Upgrading Icinga 2 <a id="upgrading-icinga-2"></a>
2015-01-23 14:15:57 +01:00
Upgrading Icinga 2 is usually quite straightforward. Ordinarily the only manual steps involved
are scheme updates for the IDO database.
2017-09-07 17:01:25 +02:00
## Upgrading to v2.8 <a id="upgrading-to-2-8"></a>
2017-09-22 13:06:40 +02:00
### Changed Certificate Paths <a id="upgrading-to-2-8-certificate-paths"></a>
2017-09-07 17:01:25 +02:00
The default certificate path was changed from `/etc/icinga2/pki` to
`/var/lib/icinga2/certs` .
2017-10-16 15:32:57 +02:00
Old Path | New Path
---------------------------------------------------|---------------------------------------------------
`/etc/icinga2/pki/icinga2-client1.localdomain.crt` | `/var/lib/icinga2/certs/icinga2-client1.localdomain.crt`
`/etc/icinga2/pki/icinga2-client1.localdomain.key` | `/var/lib/icinga2/certs/icinga2-client1.localdomain.key`
`/etc/icinga2/pki/ca.crt` | `/var/lib/icinga2/certs/ca.crt`
2017-09-07 17:01:25 +02:00
This applies to Windows clients in the same way: `%ProgramData%\etc\icinga2\pki`
2017-10-16 15:32:57 +02:00
was moved to `%ProgramData%\var\lib\icinga2\certs` .
Old Path | New Path
----------------------------------------------------------------|----------------------------------------------------------------
`%ProgramData%\etc\icinga2\pki\icinga2-client1.localdomain.crt` | `%ProgramData%\var\lib\icinga2\certs\icinga2-client1.localdomain.crt`
`%ProgramData%\etc\icinga2\pki\icinga2-client1.localdomain.key` | `%ProgramData%\var\lib\icinga2\certs\icinga2-client1.localdomain.key`
`%ProgramData%\etc\icinga2\pki\ca.crt` | `%ProgramData%\var\lib\icinga2\certs\ca.crt`
> **Note**
>
> The default expected path for client certificates is `/var/lib/icinga2/certs/ + NodeName + {.crt,.key}`.
> The `NodeName` constant is usually the FQDN and certificate common name (CN). Check the [conventions](06-distributed-monitoring.md#distributed-monitoring-conventions)
> section inside the Distributed Monitoring chapter.
2017-09-07 17:01:25 +02:00
The [setup CLI commands ](06-distributed-monitoring.md#distributed-monitoring-setup-master ) and the
default [ApiListener configuration ](06-distributed-monitoring.md#distributed-monitoring-apilistener )
have been adjusted to these paths too.
2017-10-16 15:32:57 +02:00
The [ApiListener ](09-object-types.md#objecttype-apilistener ) object attributes `cert_path` , `key_path`
and `ca_path` have been deprecated and removed from the example configuration.
#### Migration Path <a id="upgrading-to-2-8-certificate-paths-migration-path"></a>
> **Note**
>
> Icinga 2 automatically migrates the certificates to the new default location if they
> are configured and detected in `/etc/icinga2/pki`.
During startup, the migration kicks in and ensures to copy the certificates to the new
location. This will also happen if someone updates the certificate files in `/etc/icinga2/pki`
to ensure that the new certificate location always has the latest files.
This has been implemented in the Icinga 2 binary to ensure it works on both Linux/Unix
and the Windows platform.
If you are not using the built-in CLI commands and setup wizards to deploy the client certificates,
please ensure to update your deployment tools/scripts. This mainly affects
* Puppet modules
* Ansible playbooks
* Chef cookbooks
* Salt recipes
* Custom scripts, e.g. Windows Powershell or self-made implementations
In order to support a smooth migration between versions older than 2.8 and future releases,
the built-in certificate migration path is planned to exist as long as the deprecated
`ApiListener` object attributes exist.
You are safe to use the existing configuration paths inside the `api` feature. If you plan your migration,
look at the following example taken from the Director Linux deployment script for clients.
* Ensure that the default certificate path is changed from `/etc/icinga2/pki` to `/var/lib/icinga2/certs` .
```
-ICINGA2_SSL_DIR="${ICINGA2_CONF_DIR}/pki"
+ICINGA2_SSL_DIR="${ICINGA2_STATE_DIR}/lib/icinga2/certs"
```
* Remove the ApiListener configuration attributes.
```
object ApiListener "api" {
- cert_path = SysconfDir + "/icinga2/pki/${ICINGA2_NODENAME}.crt"
- key_path = SysconfDir + "/icinga2/pki/${ICINGA2_NODENAME}.key"
- ca_path = SysconfDir + "/icinga2/pki/ca.crt"
accept_commands = true
accept_config = true
}
```
Test the script with a fresh client installation before putting it into production.
> **Tip**
>
> Please support module and script developers in their migration. If you find
> any project which would require these changes, create an issue or a patchset in a PR
> and help them out. Thanks in advance!
2017-09-22 13:06:40 +02:00
### Removed Bottom Up Client Mode <a id="upgrading-to-2-8-removed-bottom-up-client-mode"></a>
This client mode was deprecated in 2.6 and was removed in 2.8.
The node CLI command does not provide `list` or `update-config` anymore.
2017-10-16 15:32:57 +02:00
> **Note**
>
> The old migration guide can be found on [GitHub](https://github.com/Icinga/icinga2/blob/v2.7.0/doc/06-distributed-monitoring.md#bottom-up-migration-to-top-down-).
2017-09-22 13:06:40 +02:00
The clients don't need to have a local `conf.d` directory included.
Icinga 2 continues to run with the generated and imported configuration.
You are advised to [migrate ](https://github.com/Icinga/icinga2/issues/4798 )
any existing configuration to the "top down" mode with the help of the
Icinga Director or config management tools such as Puppet, Ansible, etc.
2017-10-16 15:32:57 +02:00
2017-09-22 13:06:40 +02:00
### Removed Classic UI Config Package <a id="upgrading-to-2-8-removed-classicui-config-package"></a>
2017-09-22 12:28:26 +02:00
The config meta package `classicui-config` and the configuration files
2017-09-22 12:48:18 +02:00
have been removed. You need to manually configure
this legacy interface. Create a backup of the configuration
before upgrading.
2017-09-22 12:28:26 +02:00
2017-09-20 15:33:42 +02:00
## Upgrading to v2.7 <a id="upgrading-to-2-7"></a>
v2.7.0 provided new notification scripts and commands. Please ensure to
update your configuration accordingly. An advisory has been published [here ](https://www.icinga.com/2017/08/23/advisory-for-icinga-2-v2-7-update-and-mail-notification-scripts/ ).
In case are having troubles with OpenSSL 1.1.0 and the
public CA certificates, please read [this advisory ](https://www.icinga.com/2017/08/30/advisory-for-ssl-problems-with-leading-zeros-on-openssl-1-1-0/ )
and check the [troubleshooting chapter ](15-troubleshooting.md#troubleshooting ).
2017-09-22 09:31:05 +02:00
If Icinga 2 fails to start with an empty reference to `$ICINGA2_CACHE_DIR`
ensure to set it inside `/etc/sysconfig/icinga2` (RHEL) or `/etc/default/icinga2` (Debian).
RPM packages will put a file called `/etc/sysconfig/icinga2.rpmnew`
if you have modified the original file.
Example on CentOS 7:
```
vim /etc/sysconfig/icinga2
ICINGA2_CACHE_DIR=/var/cache/icinga2
systemctl restart icinga2
```
2017-07-12 20:46:12 +02:00
## Upgrading the MySQL database <a id="upgrading-mysql-db"></a>
2015-01-23 14:15:57 +01:00
2016-05-23 14:14:59 +02:00
If you're upgrading an existing Icinga 2 instance, you should check the
2015-01-23 14:15:57 +01:00
`/usr/share/icinga2-ido-mysql/schema/upgrade` directory for an incremental schema upgrade file.
> **Note**
>
2016-05-23 14:14:59 +02:00
> If there isn't an upgrade file for your current version available, there's nothing to do.
2015-01-23 14:15:57 +01:00
2015-11-20 15:57:16 +01:00
Apply all database schema upgrade files incrementally.
2015-01-23 14:15:57 +01:00
# mysql -u root -p icinga < /usr/share/icinga2-ido-mysql/schema/upgrade/< version > .sql
The Icinga 2 DB IDO module will check for the required database schema version on startup
and generate an error message if not satisfied.
2015-02-12 13:16:30 +01:00
**Example:** You are upgrading Icinga 2 from version `2.0.2` to `2.3.0` . Look into
2015-01-23 14:15:57 +01:00
the *upgrade* directory:
$ ls /usr/share/icinga2-ido-mysql/schema/upgrade/
2015-02-12 13:16:30 +01:00
2.0.2.sql 2.1.0.sql 2.2.0.sql 2.3.0.sql
2015-01-23 14:15:57 +01:00
2015-02-12 13:16:30 +01:00
There are two new upgrade files called `2.1.0.sql` , `2.2.0.sql` and `2.3.0.sql`
2015-11-20 15:57:16 +01:00
which must be applied incrementally to your IDO database.
2015-01-23 14:15:57 +01:00
2017-07-12 20:46:12 +02:00
## Upgrading the PostgreSQL database <a id="upgrading-postgresql-db"></a>
2015-01-23 14:15:57 +01:00
2016-05-23 14:14:59 +02:00
If you're updating an existing Icinga 2 instance, you should check the
2015-01-23 14:15:57 +01:00
`/usr/share/icinga2-ido-pgsql/schema/upgrade` directory for an incremental schema upgrade file.
> **Note**
>
2016-05-23 14:14:59 +02:00
> If there isn't an upgrade file for your current version available, there's nothing to do.
2015-01-23 14:15:57 +01:00
2015-11-20 15:57:16 +01:00
Apply all database schema upgrade files incrementally.
2015-01-23 14:15:57 +01:00
# export PGPASSWORD=icinga
# psql -U icinga -d icinga < /usr/share/icinga2-ido-pgsql/schema/upgrade/< version > .sql
The Icinga 2 DB IDO module will check for the required database schema version on startup
and generate an error message if not satisfied.
2015-02-12 13:16:30 +01:00
**Example:** You are upgrading Icinga 2 from version `2.0.2` to `2.3.0` . Look into
2015-01-23 14:15:57 +01:00
the *upgrade* directory:
$ ls /usr/share/icinga2-ido-pgsql/schema/upgrade/
2015-02-12 13:16:30 +01:00
2.0.2.sql 2.1.0.sql 2.2.0.sql 2.3.0.sql
2015-01-23 14:15:57 +01:00
2015-02-12 13:16:30 +01:00
There are two new upgrade files called `2.1.0.sql` , `2.2.0.sql` and `2.3.0.sql`
2015-11-20 15:57:16 +01:00
which must be applied incrementally to your IDO database.