Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Add note about workaround for broken custom vars #6572

Merged
merged 1 commit into from
Aug 24, 2018
Merged

Add note about workaround for broken custom vars #6572

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
16 changes: 16 additions & 0 deletions doc/16-upgrading-icinga-2.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -134,6 +134,22 @@ With the removal of RHEL 5 as supported platform, we can finally use real unique
This is reflected in generating names for e.g. API stage names. Previously it was a handcrafted
mix of local FQDN, timestamps and random numbers.

### Custom Vars not updating <a id="upgrading-to-2-9-custom-vars-not-updating"></a>

A rare issue preventing the custom vars of objects created prior to 2.9.0 being updated when changed may occur. To
remedy this the config checksums of the affected type need to be reset to trigger a full update. The following is an
example of how to do this for Hosts in mysql:

```
$ mysql -uroot -picinga icinga
MariaDB [icinga]> UPDATE icinga_hosts SET config_hash = NULL;
MariaDB [icinga]> exit
Bye
$ sudo systemctl restart icinga2
```

Custom vars should now be up to date.


## Upgrading to v2.8.2 <a id="upgrading-to-2-8-2"></a>

Expand Down