fix(roles/mariadb_server): user creation does not support modern authentication plugins (e.g. ed25519)

[markuslf]

Problem

The mariadb_server role cannot provision users that use modern MariaDB authentication plugins such as ed25519. As a workaround, admins have to run statements like the following manually after the role finishes:

ALTER USER 'icingaweb2_user'@'localhost' IDENTIFIED VIA ed25519 USING PASSWORD('<replace-with-strong-password>');

This defeats the purpose of managing users declaratively via Ansible.

Root Cause

• roles/mariadb_server/tasks/main.yml:736-747 calls community.mysql.mysql_user for mariadb_server__users__* and passes password: together with an optional plugin:, but never plugin_auth_string / plugin_hash_string. For plugins like ed25519 this combination does not produce a usable login (the plaintext password: is not interpreted as the ed25519 secret).
• roles/mariadb_server/tasks/create-dba.yml:4-13 (admin user) and roles/mariadb_server/tasks/main.yml:634-643 (dump user) do not expose a plugin parameter at all and are therefore pinned to the server's default plugin (in practice mysql_native_password).
• The default config templates (templates/etc/my.cnf.d/*-z00-linuxfabrik.cnf.j2 and vars/*.yml) only pre-load server_audit and file_key_management via plugin_load_add; server_ed25519 is never loaded, so users defined with plugin: ed25519 would fail server-side anyway unless the admin sets mariadb_server__cnf_plugin_load_add__* by hand.
• README.md:381-384 documents plugin: only as a generic string with no working ed25519 example.

Expected Behavior

The role should be able to create MariaDB users that authenticate via modern plugins (in particular ed25519) without any manual ALTER USER follow-up.

Proposed Changes

• roles/mariadb_server/tasks/main.yml:

  • extend the user task with plugin_auth_string / plugin_hash_string so that community.mysql.mysql_user can install ed25519 credentials correctly
  • apply the same authentication options consistently to mariadb_server__admin_user (create-dba.yml) and mariadb_server__dump_user, so they too can be provisioned with a non-legacy plugin

• plugin loading:

  • make sure that server_ed25519 is loaded on the server side when any user requests plugin: ed25519, either by extending the default plugin_load_add in templates/etc/my.cnf.d/*-z00-linuxfabrik.cnf.j2 / vars/*.yml, or by clearly documenting the requirement on the inventory side

• roles/mariadb_server/README.md:

  • document the new fields and provide a working example for an ed25519 user (admin, dump, regular)
  • note implications for legacy clients that do not support ed25519

Acceptance Criteria

• A user defined in mariadb_server__users__* (and analogously mariadb_server__admin_user / mariadb_server__dump_user) with plugin: ed25519 is created such that SELECT user, host, plugin FROM mysql.global_priv; shows ed25519 and login with the configured password works, without any manual ALTER USER.
• Existing inventories that do not set plugin: keep working (no breaking change).
• README documents the new behavior with at least one full example.

References

• MariaDB KB: Authentication Plugin - ed25519
• community.mysql.mysql_user module: plugin, plugin_auth_string, plugin_hash_string

[NavidSassan]

What is our use-case for this?

[markuslf]

In MariaDB, mysql_native_password is not yet deprecated (in MySQL it is). Tools like MySQLTuner-perl as well as the updated mysql-user-security plugin already report users wired to the old SHA-1 plugin from the MySQL 4 era, so we want to be able to provision service accounts with ed25519 declaratively from the inventory instead of patching them up by hand afterwards.

https://mariadb.com/docs/server/reference/plugins/authentication-plugins/authentication-plugin-ed25519