IntenseWebs/grafana
3
0
Fork 0
mirror of https://github.com/grafana/grafana.git synced 2025-02-14 01:23:32 -06:00
Code Issues Packages Projects Releases Wiki Activity

docs: add upgrade notes for v6.0

Browse Source
This commit is contained in:
Marcus Efraimsson 2019-02-13 19:53:55 +01:00
parent 592f57d0ba
commit 1bd9573f8e
No known key found for this signature in database
GPG Key ID: EBFE0FB04612DD4A
1 changed files with 29 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

29
docs/sources/installation/upgrading.md
View File

@ -117,3 +117,32 @@ One of the database migrations included in this release will update all annotati
We've got one report where using systemd, PostgreSQL and a large amount of annotations (table size 1645mb) took 8-20 minutes for the database migration to complete. However, the grafana-server process was killed after 90 seconds by systemd. Any database migration queries in progress when systemd kills the grafana-server process continues to execute in database until finished.
If you're using systemd and have a large amount of annotations consider temporary adjusting the systemd `TimeoutStartSec` setting to something high like `30m` before upgrading.
## Upgrading to v6.0
If you have text panels with script tags they will no longer work due to a new setting that per default disallow unsanitzied HTML.
Read more [here](/installation/configuration/#disable-sanitize-html) about this new setting.
### Authentication and security
If your using Grafana's builtin, LDAP (without Auth Proxy) or OAuth authentication all users will be required to login upon the next visit after the upgrade.
If you have `cookie_secure` set to `true` in the `session` section you probably want to change the `cookie_secure` to `true` in the `security` section as well. Ending up with a configuration like this:
```ini
[session]
cookie_secure = true
[security]
cookie_secure = true
```
The `login_remember_days`, `cookie_username` and `cookie_remember_name` settings in the `security` section are no longer being used so they're safe to remove.
If you have `login_remember_days` configured to 0 (zero) you should change your configuration to this to accomplish similar behavior, i.e. a logged in user will maximum be logged in for 1 day until being forced to login again:
```ini
[auth]
login_maximum_inactive_lifetime_days = 1
login_maximum_lifetime_days = 1
```