Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
* Enable skipping zabbix_valid_server_versions check
This table is incomplete, and a hinderance for deployments to valid
combinations. Allow the user to bypass this by supplying
`-e enable_version_check=false`
* Put zabbix_repo_deb_url in defaults
Instead of having a partial url in vars/Debian.yml, and appending to
it with additional info via set_fact, if zabbix_repo_deb_url is not
defined. Just supply it as a default which can be overriden by user.
Notes on Raspbian
There are very few ways do differentiate Raspbian from Debian with
ansible_facts. The only candidate seems to be ansible_facts.lsb.id.
The lsb section does not get filled in unless some packages are
installed. But luckily those packages come installed on Raspbian
systems. And we just default it back to ansible_facts.distribution
if lsb.id is not present. So we're gonna simplify and drop some
tasks.
Tested with ansible-core 2.13.13 on;
2024-03-12-raspios-bullseye-armhf-lite
2024-03-15-raspios-bookworm-armhf-lite
If this for some unforseen reason wouldn't work on older or newer
versions of raspbian, there's always the option of just overriding
the zabbix_repo_deb_url.
* Single common task to install zabbix-proxy
Install the zabbix-proxy-{{ zabbix_proxy_database }} from a single
common task.
RedHat can pin the minor version, and has a toggle to disable repo.
Debian can't pin minor version. The other debian options
cache_valid_time, default_release and force seem irrelevant.
We use the common package module, which is just a wrapper around
apt/yum, and use this construction;
user_supplied_var | default(_calculated_var | default(omit))
to send additional parameters to the respective modules.
* Single common task to install zabbix-sql-scripts
We don't need additional tasks for installing zabbix-sql-scripts,
we can just tack them on to zabbix-proxy-{{ database }}, with the
when condition found only on the Debian side of things.
* Install MySQL dependencies from mysql task
It's cleaner, less conditional checking, and a single task for all
supported systems.
Remove PyMySQL installation via pip task and switch from mysqldb to
pymysql for all debian based systems. The only reason we're
installing any python/mysql dependencies at all is to use the
ansible community.mysql collection, which has a preference for
pymysql, and mysqldb as a backup [1].
Upgrade system-packages of pymysql with pip for a couple of
distributions. Upgrading system-packages with pip is generally a
bad idea, older versions of pymysql has issues with newer version
of mysql (>=8).
pymysql>=0.9.0,<0.10.0 fixes the issue with passwords missing
during login, but still has a problem setting
log_bin_trust_function_creators.
pymysql>=0.10.0,<0.11.0, fixes the remaining issue. We don't want
to stray to far off from the system defaults
Also, drop zabbix_python_prefix. It's all python3.
[1] https://github.com/ansible-collections/community.mysql/blob/main/plugins/module_utils/mysql.py#L21-L36
* Install PostgreSQL dependencies from postresql task
It's cleaner, less conditional checking, and a single task for all
supported systems. The list of packages also remains the same for
all supported systems within the os_family, so we can reduce the
lookup.
We're also trimming out the last of zabbix_python_prefix, and
always go for python3
The Debian systems had split installing the dependencies in two
tasks, one for the python dependency and one that gets triggered if
zabbix_proxy_install_database_client is true.
We're gonna reuse this variable, and bring it to RedHat systems,
and for mysql aswell in this commit.
And to bring it all back to one task, we use this construction;
- package:
name: "{{ _dependencies | select | list }}"
vars:
_dependencies:
- "{{ install_client | ternary('client-package', '') }}"
- some-python-dependency
This will create a list of two items, the python-dependency, and
possibly an empty string. We use `| select` to filter out the empty
strings, and `| list` while strictly not necessary, was
historically appended in case the preceeding result ended up being
a generator.
* Install SQLite3 dependencies from sqlite3 task
Less conditional checking, and should feel familiar as both mysql
and postgresql do this now.
* Simplify logic for dbhost_run_install (mysql)
It was difficult to see what this code was supposed to achieve. The
most important variable zabbix_proxy_dbhost_run_install was hidden
behind two conditions of delegated_dbhost. But here we try to bring
it back to view.
if zabbix_proxy_dbhost_run_install is true, we want the code to be
delegated_to the zabbix_proxy_dbhost, otherwise we want to run it
from the zabbix_proxy.
However, we have a funny situation where zabbix_proxy_dbhost is
by default localhost, which means we'd still be on the
zabbix_proxy. We store this calculation in delegated_dbhost.
if (dbhost == localhost) then zabbix_proxy else dbhost
The mysql tasks have an additional variable
zabbix_proxy_real_dbhost, which we try applying first and if not,
we default to whatever zabbix_proxy_dbhost_run_install wants.
* pgsql: Consolidate delegate and remote tasks
With a clear understanding of zabbix_proxy_dbhost_run_install, we
can now use it to determine whether or not we need to become the
postgres user, and rely upon the default(omit) construction for any
potentially provided or missing arguments to login_{user,pass,host}
* Refactor MySQL schema import
Similar to pgsql, we check for existing dbversion in a block, if
the query fails, we create the database in a rescue section. There
are a few things to note however.
The check and schema creation is not delegated. It happens from
zabbix_proxy. This is to verify that our dbuser can access the
dbname from zabbix_proxy and has all the permissions needed (after
creation) to alter tables between zabbix version upgrades.
For the schema creation we actually need some extra privileges, so
we read what they currently are, set them to what we need, import
our schema, and revert the extra privileges back to their original
state. The reverting happens in the `always:` section, so if any
other task should fail in schema creation (`rescue:` section) we
always revert the privileges before failing.
We also have to deal with varying paths to zabbix-proxy schema on
RedHat based systems.
e.g. /usr/share/doc/zabbix-proxy-pgsql-X.Y.Z
And you don't necessarily know which version you're installing when
you just want the latest. The code to retain support for older
versions is already in place, by leveraging the ls_output_schema
for the legacy path.
* Refactor PostgreSQL schema import
We take advantage of the community.postgres modules, and do a query
for 'mandatory' in 'dbversion'. If the query fails, we're going to
assume the database has not been populated yet, and rescue the task
by populating it. Thereby alleviating the need for .done files.
While zabbix-server has predictable paths to the schemas, the
zabbix-proxy schema paths are versioned on RedHat based systems.
e.g. /usr/share/doc/zabbix-proxy-pgsql-X.Y.Z
And you don't necessarily know which version you're installing when
you just want the latest. The code to retain support for older
versions is already in place, by leveraging the ls_output_schema
for the legacy path.
* Refactor SQLite3 schema import
Mostly reusing the code-style seen in the other database imports.
Simplifying the commands used for creation, while keeping support
for older style schemas (zabbix < 6). And the addition of setting a
secure mode (0600) to the database file.
* Simplify legacy tasks
* Prefix database task-files with initialize
It reflects more accurately what we're trying to achieve. Also
strip out zabbix_proxy_db_long, it serves no purpose anymore.
* Group similar directory tasks
* Drop zabbix 5.0 compatibility
This simplifies the code by removing zabbix-5.0 quirks/workarounds.
---------- Loading branch information
