These notes are for upgrading from Zabbix 6.0.x to Zabbix 6.2.0. All notes are grouped into:
Critical- the most critical information related to the upgrade process and the changes in Zabbix functionality
Informational- all remaining information describing the changes in Zabbix functionality
It is possible to upgrade to Zabbix 6.2.0 from versions before Zabbix 6.0.0. See the upgrade procedure section for all relevant information about upgrading from previous Zabbix versions.
Incremental configuration cache synchronization has been added for hosts, host tags, items, item tags, item preprocessing, triggers, trigger tags and functions to lessen synchronization time and database load when configuration is being updated on an already running Zabbix server or Zabbix proxy. As a result of this change, deterministic triggers need to be created during upgrade.
On MySQL and MariaDB, this requires
GLOBAL log_bin_trust_function_creators = 1 to be set if binary logging is enabled and there is no superuser privileges and
log_bin_trust_function_creators = 1 is not set in MySQL configuration file. To set the variable using MySQL console, run:
Once the upgrade has been successfully completed,
log_bin_trust_function_creators can be disabled:
Triggers are also created for PostgreSQL and Oracle database.
The minimum required PHP version has been raised from 7.2.5 to 7.4.0.
The following internal items, deprecated since Zabbix 6.0, have now been removed:
History pollers have been removed from Zabbix proxy.
Internal items that used to require a database connection (such as
zabbix[proxy_history]) and were polled by history pollers on Zabbix server or Zabbix proxy have been reconfigured to be polled by regular pollers and use data from the configuration cache instead.
In Zabbix 5.0 password hashing algorithm has been changed from MD5 to the more secure bcrypt. However, in Zabbix versions 5.0 - 6.0, MD5 hashing was still used upon the first user login after an upgrade - to convert passwords with hashes not exceeding 32 bytes from MD5 to bcrypt. Now support of MD5 cryptography has been dropped completely.
If you're upgrading from Zabbix versions before 5.0, users with passwords hashed by MD5 won't be able to log in. In this case, a Super administrator can change passwords of the affected users. If a Super administrator also cannot log in, run the following SQL query to apply the default password to the user (replace 'Admin' with the required username):
After running this query, the user's password will be set to zabbix. Make sure to change the default password on the first login.
In addition to HashiCorp Vault, Zabbix now supports storage of secrets in CyberArk Vault. To distinguish between secret management platforms, a new parameter $DB['VAULT'] has been added to zabbix.conf.php.
If your Zabbix installation has been configured to work with HashiCorp Vault, after the upgrade you will need to manually update the configuration file. To continue using the HashiCorp integration, add to zabbix.conf.php the variable:
Additionally, the database credentials will no longer be cached by default. Instead, Zabbix will make a call to the vault API every time when establishing a database connection. To enable storing of retrieved credentials in a local cache, you now need to manually set the option
$DB['VAULT_CACHE'] = true.
For more info, see Storage of secrets.
HttpRequest in Zabbix 5.4, and had been deprecated since, has now been removed.
See the list of API changes in Zabbix 6.2.0.
Previously, newly added items were first checked at a random time within their update interval. Now new items, web scenarios and discovery rules, will be executed within 60 seconds of their creation, unless they have Scheduling or Flexible update interval with the Update interval parameter set to 0.
Host group functionality has been split into template groups, which may contain templates only and host groups, which may contain hosts only. During the upgrade all host groups that contained templates only will be automatically converted into template groups. Host and template groups will retain the same UUIDs.
If a host group contains both hosts and templates, such group will be split into two groups with the same name: a template group and a host group. If a group doesn't contain hosts, but is referenced somewhere in the hosts-related configuration (for example, used by a host prototype or in an action operation), an empty host group will be created.
After the upgrade, all users whose role allows access to Configuration -> Host groups menu section will get access to the new Configuration -> Template groups section. For user groups, existing permission sets will be automatically split into host and template group permissions.