bertvv/ansible-role-mariadb

Install MariaDB on RHEL/CentOS 7 or Fedora.

Ansible role mariadb

An Ansible role for managing MariaDB in RedHat-based distributions. Specifically, the responsibilities of this role are to:

• Install MariaDB packages from the official MariaDB repositories
• Remove unsafe defaults:
  • set database root password (remark that once set, this role is unable to change the database root password)
  • remove anonymous users
  • remove test database
• Create users and databases
• Manage configuration files server.cnf and custom.cnf
• Upload SSL certificates and configure the server to use them

Refer to the change log for notable changes in each release.

Do you use/like this role? Please consider giving it a star. If you rate this role on Ansible Galaxy and find it lacking in some respect, please consider opening an Issue with actionable feedback or a PR so we can improve it. Thank you!

Requirements

No specific requirements

Role Variables

None of the variables below are required. When not defined by the user, the default values are used.

Basic configuration

Variable	Default	Comments
mariadb_bind_address	'127.0.0.1'	Set this to the IP address of the network interface to listen on, or '0.0.0.0' to listen on all interfaces.
mariadb_configure_swappiness	true	When true, this role will set the "swappiness" value (see mariadb_swappiness.
mariadb_custom_cnf	{}	Dictionary with custom configuration.
mariadb_databases	[]	List of dicts specifying the databases to be added. See below for details.
mariadb_mirror	yum.mariadb.org	Download mirror for the .rpm package (1)
mariadb_port	3306	The port number used to listen to client requests
mariadb_root_password	''	The MariaDB root password. (2)
mariadb_server_cnf	{}	Dictionary with server configuration.
mariadb_service	mariadb	Name of the service (should e.g. be 'mysql' on CentOS for MariaDB 5.5)
mariadb_swappiness	'0'	"Swappiness" value (string). System default is 60. A value of 0 means that swapping out processes is avoided.
mariadb_users	[]	List of dicts specifying the users to be added. See below for details.
mariadb_version	'10.5'	The version of MariaDB to be installed. Default is the current stable release.
mariadb_ssl_ca_crt	null	Path to the certificate authority's root certificate
mariadb_ssl_server_crt	null	Path to the server's SSL certificate
mariadb_ssl_server_key	null	Path to the server's SSL certificate key

Remarks

(1) Installing MariaDB from the official repository can be very slow (some users reported more than 10 minutes). The variable mariadb_mirror allows you to specify a custom download mirror closer to your geographical location that may speed up the installation process. E.g.:

# for RHEL/Fedora
mariadb_mirror: 'mariadb.mirror.nucleus.be/yum'
# for Debian
mariadb_mirror: 'mirror.mva-n.net/mariadb/repo'

(2) It is highly recommended to set the database root password! Leaving the password empty is a serious security risk. The role will issue a warning if the variable was not set.

Server configuration

You can specify the configuration in /etc/my.cnf.d/server.cnf (in RHEL/Fedora, /etc/mysql/conf.d/server.cnf in Debian), specifically in the [mariadb] section, by providing a dictionary of keys/values in the variable mariadb_server_cnf. Please refer to the MariaDB Server System Variables documentation for details on the possible settings.

For settings that don't get a = value in the config file, leave the value empty. All values should be given as strings, so numerical values should be quoted.

In the following example, slow-query-log's value is left empty:

mariadb_server_cnf:
  slow-query-log:
  slow-query-log-file: 'mariadb-slow.log'
  long-query-time: '5.0'

This would result in the following server.cnf:

[mariadb]
slow-query-log
slow-query-log-file = mariadb-slow.log
long-query-time = 5.0

Custom configuration

Settings for other sections than [mariadb], can be set with mariadb_custom_cnf. These settings will be written to /etc/mysql/my.cnf.d/custom.cnf (in RHEL/Fedora, /etc/mysql/conf.d/custom.cnf in Debian).

Just like mariadb_server_cnf, the variable mariadb_custom_cnf should be a dictionary. Keys are section names and values are dictionaries with key-value mappings for individual settings.

The following example enables the general query log:

mariadb_custom_cnf:
  mysqld:
    general-log:
    general-log-file: queries.log
    log-output: file

The resulting config file will look like this:

[mysqld]
general-log-file=queries.log
general-log
log-output=file

Adding databases

Databases are defined with a dict containing the fields name: (required), and init_script: (optional). The init script is a SQL file that is executed when the database is created to initialise tables and populate it with values.

mariadb_databases:
  - name: appdb1
  - name: appdb2
    init_script: files/init_appdb2.sql

Adding users

Users are defined with a dict containing fields name:, password:, priv:, and, optionally, host:, and append_privs. The password is in plain text and priv: specifies the privileges for this user as described in the Ansible documentation.

An example:

mariadb_users:
  - name: john
    password: letmein
    priv: '*.*:ALL,GRANT'
  - name: jack
    password: sekrit
    priv: 'jacksdb.*:ALL'
    append_privs: 'yes'
    host: '192.168.56.%'

Dependencies

No dependencies.

Example Playbook

See the test playbook

Testing

This role can be tested using Ansible Molecule. The Molecule configuration will:

• Run Yamllint and Ansible Lint
• Create a Docker container named db
• Run a syntax check
• Apply the role with a test playbook
• Run acceptance tests with BATS

This process is repeated for each supported Linux distribution.

Local Docker test environment

If you want to set up a local test environment, you can use this reproducible setup based on Vagrant+VirtualBox: https://github.com/bertvv/ansible-testenv. Steps to install the necessary tools manually:

1. Docker and BATS should be installed on your machine (assumed to run Linux). No Docker containers should be running when you start the test.
2. As recommended by Molecule, create a python virtual environment
3. Install the software tools python3 -m pip install molecule docker netaddr yamllint ansible-lint
4. Navigate to the root of the role directory and run molecule test

Molecule automatically deletes the containers after a test. If you would like to check out the containers yourself, run molecule converge followed by molecule login --host HOSTNAME.

The Docker containers are based on images created by Jeff Geerling, specifically for Ansible testing (look for images named geerlingguy/docker-DISTRO-ansible). You can use any of his images, but only the distributions mentioned in meta/main.yml are supported.

The default config will start a Centos 7 container (the primary supported platform at this time). Choose another distro by setting the MOLECULE_DISTRO variable with the command, e.g.:

MOLECULE_DISTRO=fedora32 molecule test

or

MOLECULE_DISTRO=fedora32 molecule converge

You can run the acceptance tests on both servers with molecule verify or manually with

SUT_IP=172.17.0.2 bats molecule/common/mariadb.bats

You need to initialise the variable SUT_IP, the system under test's IP address. The db container should have IP address 172.17.0.2

Local Vagrant test environment

Alternatively, you can run the Molecule tests with full-fledged VMs instead of Docker containers. Vagrant, VirtualBox, Ansible, Molecule and BATS need to be installed on the system where you run the tests.

molecule test -s vagrant

This will create VirtualBox VMs for the supported platforms, based on base boxes from the Bento project, apply the test playbook and run acceptance tests.

License

2 clause BSD

Contributors

• Adail Horst
• Barry Britt
• Bert Van Vreckem (Maintainer)
• Cédric Delgehier
• Dachi Natsvlishvili
• @herd-the-cats
• Louis Tournayre
• Nate Henderson
• @piuma
• @raznikk
• Ripon Banik
• Thomas Eylenbosch
• Tom Stechele
• Vincenzo Castiglia
• @nxet

ansible-role-mariadb's Issues

setting swappiness failes in an lxc container

fatal: [blog]: FAILED! => {"changed": false, "msg": "Failed to reload sysctl: sysctl: setting key "vm.swappiness": Read-only file system\n"}

service mariadb 10.3.x does not start

since MariaDB 10.3.1 the following config properties has been removed
mariadb_innodb_file_format and mariadb_innodb_file_format_check

Value not written to custom.cnf when 0

Hi,

When the custom.cnf file is generated, if a key-value mapping has a numerical value greater than 0 then {{ key }}={{ value }} is written to file, else only {{ key }} is written.

mariadb_custom_cnf:
mysqld:
server_id: '{{ groups[mariadb_servers].index(inventory_hostname) | int + 1 }}'
log_bin: 'mysqld-bin'
replicate-same-server-id: 0
replicate-do-db: 'testdb'

Generated custom.cnf file
[mysqld]
server_id=1
log_bin=mysqld-bin
replicate-same-server-id (expected : replicate-same-server-id=0, as per the MariaDB documentation)
replicate-do-db=testdb

Would it be possible to look into this "issue" for a future release?

Thank you in advance.

Kinds regards,

Fails when playbook is running with --check

When running ansible-playbook --check fails when this role is activated.

TASK [bertvv.mariadb : Set MariaDB root password for the first time (root@localhost)] *************************************************************************
fatal: [<hostname>]: FAILED! => {"msg": "The conditional check 'root_pwd_check.rc == 0' failed. The error was: error while evaluating conditional (root_pwd_check.rc == 0): 'dict object' has no attribute 'rc'\n\nThe error appears to be in '/home/ccowley/electricwebsites/ansible/roles/bertvv.mariadb/tasks/root-password.yml': line 21, column 3, but may\nbe elsewhere in the file depending on the exact syntax problem.\n\nThe offending line appears to be:\n\n\n- name: Set MariaDB root password for the first time (root@localhost)\n  ^ here\n"}

The task Check if root password is set is not setting root_pwd_check, so the condition to stop it pretending to set the root password is in the wrong format, so the test fails, even though it will run fine when the playbook is run for true. Obviously this makes it impossible to do a proper dry-run of the playbook

Set [mariadb] configurable to allow MariaDB multi-instance

Hello,
In the template file templates/etc_my.cnf.d_server.cnf.j2 the name [mariadb] is hard-coded.
Is it possible to make this name dynamic?
For example we would like to have [mariadb.inst1] in order to start it with systemctl start [email protected]
Thank you.

Cannot install role

I try to do ansible-galaxy install bertvv.mariadb, but unfortunately it output this

I tried to search for answers here but I find to solutions, can someone help me? Thanks

Setting up root Password

I am getting, when trying to pass root password in

# roles/mariadb/defaults/main.yml 
mariadb_root_password: 'secure'

TASK [Mariadb : Set MariaDB root password for the first time] ************************************************************************************
fatal: [271.AppDevelopment.server]: FAILED! => {"changed": false, "failed": true, "msg": "(1133, \"Can't find any matching row in the user table\")"}
        to retry, use: --limit @/Users/rvs/Repositories/Ansible/playbook.retry

Add virtuozzo linux support

Please add replace virtuozzo to centos in etc_yum.repos.d_mariadb.repo.j2

python3 and ansible cause error

When use ansible and python3:

TASK [bertvv.mariadb : Install custom config file]
fatal: [stage-catalog.megadepotllc.com]: FAILED! => changed=false 
   msg: 'AnsibleUndefinedVariable: ''dict object'' has no attribute ''iteritems'''

my ansible:

ansible 2.8.1
  config file = /home/user/project/server/ansible/ansible.cfg
  configured module search path = ['/home/user/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /usr/lib/python3.7/site-packages/ansible
  executable location = /usr/bin/ansible
  python version = 3.7.3 (default, May 11 2019, 00:45:16) [GCC 8.3.1 20190223 (Red Hat 8.3.1-2)]

ansible.cfg:

[defaults]
gathering = smart

callback_whitelist = timer, profile_tasks
stdout_callback = yaml
show_custom_stats = yes
retry_files_enabled = False

[ssh_connection]
pipelining = True
control_path = /tmp/ansible-ssh-%%h-%%p-%%r

#fact_caching = yaml
#fact_caching_connection = ../../runtime/ansible
#fact_caching_timeout = 86400

FIX:
bertvv.mariadb/templates/etc_my.cnf.d_custom.cnf.j2:
change mariadb_custom_cnf.iteritems() to mariadb_custom_cnf.items() and
section_contents.iteritems() to section_contents.items()

Repository download on RHEL systems

There's an issue with adding the official MariaDB repository in the installation section of the task list -- specifically it does not work on RHEL systems.

The fact {{ ansible_distribution|lower }} in tasks/install.yml on line 8 generates the string "redhat". This does not correlate with the yum mariadb repositories which expects the string "rhel".

A simple fix would be to replace the noted fact with the following:
{{ ansible_distribution|lower|regex_replace('redhat', 'rhel') }}

There is probably a better way of doing this, but this is the simplest I could think of. I don't have a suse install to test on, but I have tested on my own RHEL systems -- which seems to work just fine. I've attached my own modified install.yml file.

install.txt

"Set MariaDB root password for the first time" task fails

Summary

The Set MariaDB root password for the first time (root@localhost) task fails when a username and password is set for mysqladmin in the custom.cnf file.

Steps to reproduce

1. Add the following variable to the playbook:

mariadb_custom_cnf:
  mysqladmin:
    user: root
    password: <redacted>

NOTE: Make sure to update <redacted> with your root password.

2. Run the playbook:

ansible-playbook playbooks/provision-mariadb-dbs.yml

3. Run the playbook again to check for idempotentcy. (I believe the error happens on the first run, but it will definitely happen on the second run after the root password is set.)

What is the current bug behavior?

An error message displays on the run of the playbook.

What is the expected correct behavior?

The playbook should succeed on every run of the playbook, even if the root password for mysqladmin is set in a .cnf config file.

Relevant logs and/or screenshots

The Check if root password is set task erroneously succeeds. (A root password is set, but this command still succeeds.

mysqladmin -u root status

The following task, Set MariaDB root password for the first time (root@localhost) fails because a password as already been set:

msg": "unable to connect to database, check login_user and login_password are correct or /root/.my.cnf has the credentials. Exception message: (1045, \"Access denied for user 'root'@'localhost' (using password: NO)\")"

Possible fixes

Please update the following task to detect if a root password is set without using the mysqladmin command:

• Check if root password is set

# This command will succeed when the root password was set previously
- name: Check if root password is set
  shell: >
    mysql -u root
    -p'{{ mariadb_root_password }}'
    -h localhost
    -S {{ mariadb_socket }}
    -e "quit"
  changed_when: false
  ignore_errors: true
  register: root_pwd_check
  tags: mariadb

Also change the conditionals in these two lines:
line 28
line 43

to:

when: root_pwd_check.rc != 0

I will make a merge request for this change shortly.

root-password.yml - Not vault compatible

FAILED! => {"msg": "The conditional check 'mariadb_root_password | length == 0' failed. The error was: Unexpected templating type error occurred on ({% if mariadb_root_password | length == 0 %} True {% else %} False {% endif %}): object of type 'AnsibleVaultEncryptedUnicode' has no len()\n\n

Here is the fix:

- name: Check if a custom root password is specified
  debug:
    msg: >
      Warning!! the MariaDB root password was left empty. Please set a custom
      password with role variable mariadb_root_password to secure your database
      server!
#  when: mariadb_root_password | length == 0   ---It is not Vault compatible
  when: mariadb_root_password == ''

Add encoding and collation in create user table

To create a tale in a different encoding/collation than the default, I suppose currently one can create a table in the default encoding/collation and then modify it in a post-creation script, but it would be nice to be able to just add them in the vars section as for example:

    mariadb_databases:
      - name: my_db
        encoding: utf8mb4
        collation: utf8mb4_general_ci

It would just require adding a couple of lines to the Create user defined databases task:

- name: Create user defined databases
  mysql_db:
    name: "{{ item.name }}"
    encoding: "{{ item.encoding }}"
    collation: "{{ item.collation }}"
    login_user: root
    login_password: "{{ mariadb_root_password }}"
    login_unix_socket: "{{ mariadb_socket }}"
    state: present
  with_items: "{{ mariadb_databases }}"
  register: db_creation
  tags: mariadb

Better to use copy module instead for template

ansible-role-mariadb/tasks/databases.yml

Line 31 in a08fb33

template: # noqa 503

Example the cases with .sql.gz or .sql.bz2 extension you will some chars on terminal which will eventually crash terminal, however there are no problems when source is just plane .sql files.

https://docs.ansible.com/ansible/latest/collections/community/mysql/mysql_db_module.html

target path |   | Location, on the remote host, of the dump file to read from or write to.Uncompressed SQL files (.sql) as well as bzip2 (.bz2), gzip (.gz) and xz (Added in 2.0) compressed files are supported.

Build fails when no "distribution dependent variables" files are found

Hello,

I just wanted to report that the "Include distribution dependent variables" task fails when you don't have any configuration file matching the patterns of the rules.

I fixed it on Debian 10 by adding an empty Debian.yml in my Playbook folder.

I believe you could "ignore errors" on this.

Ty for the great work!

Update root pwd

Running v3.1 of the role with an old mariadb version, and a root pwd:

    - role: bertvv.mariadb
      become: yes 
      vars:
        mariadb_version: 10.1
        mariadb_root_password: ***

fails:

TASK [bertvv.mariadb : Check if a custom root password is specified] *************************************************************************************************************************
skipping: [gg-core-test-app-0]

TASK [bertvv.mariadb : Check if root password is unset] **************************************************************************************************************************************
fatal: [gg-core-test-app-0]: FAILED! => {"changed": false, "cmd": "mysql -u root -p'***' -h localhost -S /var/lib/mysql/mysql.sock -e \"quit\"\n", "delta": "0:00:00.017762", "end": "2020-11-05 11:01:53.457887", "msg": "non-zero return code", "rc": 1, "start": "2020-11-05 11:01:53.440125", "stderr": "ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: YES)", "stderr_lines": ["ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: YES)"], "stdout": "", "stdout_lines": []}
...ignoring

TASK [bertvv.mariadb : Check if the specified root password is already set] ******************************************************************************************************************
fatal: [gg-core-test-app-0]: FAILED! => {"censored": "the output has been hidden due to the fact that 'no_log: true' was specified for this result", "changed": false}

(and also logs the new root pwd, which isn't ideal)

It seems to have been caused by this change, which has inverted the behaviour of the task at L14. I tried removing L17, which got me a bit further. And I then had to add a login_user to the mysql_user tasks below. But I just ground to a halt on this task, and decided I should probably accept that I had no idea what I was doing.

I'd be happy to provide a PR, but I don't think I really understand the problem/solution well enough.

Control handler's service restarts

We often release changes that do not require service restarts which impact production. Would require a control variable and logic to the handler.

Feature request

Hi bertvv, can you make default variables "not mandatory" ?
It'll be more flexible if one can omit params if deprecated/removed in new mariadb releases or if one want to use this playbook with previous mariadb version (e.g. mariadb 5.5) not supporting some default variables.

You can do something like this in templates/etc_my.cnf.d_server.cnf.j2

{% if mariadb_innodb_buffer_pool_load_at_startup %}innodb_buffer_pool_load_at_startup = {{ mariadb_innodb_buffer_pool_load_at_startup }} {% endif %}

{% if mariadb_table_open_cache %}table_open_cache = {{ mariadb_table_open_cache }}{% endif %}

{% if mariadb_table_open_cache_instances %}table_open_cache_instances = {{ mariadb_table_open_cache_instances }}{% endif %}

So any param can be completely omitted in server.cnf simply adding lines in a playbook like these:

mariadb_innodb_buffer_pool_load_at_startup:
mariadb_table_open_cache:
mariadb_table_open_cache_instances:

Fedora maridb package names

Should maridb package names at vars/Fedora.yml be lowercase.

mariadb_packages:
  - mariadb-common
  - mariadb-server
  - python3-PyMySQL
 

yum repository

Hi,

its possible to make gpgkey in template yum repository with one variable for on-premise without internet?

gpgkey = https://yum.mariadb.org/RPM-GPG-KEY-MariaDB => gpgkey = https://{{ mariadb_mirror_gpgkey}}

Thx

Need to run mariadb-install-db for newer versions of MariaDB on RPM systems

The role tries to start the MariaDB server before it is properly initialized.

When running the role for 10.11, it would crash out at the "starting service" line because none of the "mysql" authentication/authorization tables existed yet.

After running mariadb-install-db --user=XXXX --group=XXXX --datadir=/PATH/TO/DATA by hand on the target machine, the rest of the role ran perfectly.

I suspect previous iterations of the yum install process might have run this by default?

I'm running the role against a RHEL 8 machine to install MariaDB 10.11 (the current long-term support version).

Added support for Debian doesn't work for Ubuntu

          Thank you for taking the time to submit this PR. Support for Debian was added with #45, which should work for Ubuntu as well?

Originally posted by @bertvv in #43 (comment)

@bertvv Just wanted to note here that the added Debian support does not apply to Ubuntu as well. It is acting specifically on the ansible_distribution variable, which would be Ubuntu in this case.

This could be solved by using the ansible_os_family var instead, which in the case of Ubuntu, will return Debian.

I don't know how this would affect scenarios on other distros, but if I end up using this role, I'll try to submit a PR.

Thank you for your efforts!

Database initialization can leak database content

The database init scripts are copied to /tmp on the target host with no permission mode set. This means that (depending on the umask) the sql files might have mode 644 and hence are readable for everyone. Since these files can contain the entire production database that probably includes sensitive data, it might be wise to restrict read access to root or the Ansible user.

So I propose:

- name: Copy database init scripts
  copy:
    src: "{{ item.script }}"
    dest: "/tmp/{{ item.script|basename }}"
    mode: 0600
  with_items: "{{ mariadb_init_scripts }}"
tags: mariadb

Beside that, if the initial databases are big, they can consume a lot of space available in /tmp. So maybe it is a good idea to delete them after the initialization completed. E.g.:

- name: Remove database init scripts
  file:
    path: "/tmp/{{ item.script|basename }}"
    state: absent
  with_items: "{{ mariadb_init_scripts }}"
tags: mariadb

I decided to open an issue instead of proposing a PR because there is another issue regarding the database initialization where you said you need to restructure it anyway.

Fatal error usermod: user mysql is currently used by process

I used this ansible role few years ago.
But today I updated this galaxy component and run for another project on same server.
I ended with :

TASK [bertvv.mariadb : Create daemon user with specified uid] *************************************************************************************************************************************************************************************************************************************************************************************************
fatal: [81.2.216.251]: FAILED! => {"changed": false, "msg": "usermod: user mysql is currently used by process 5741\n", "name": "mysql", "rc": 8}

It is obvious that there will be running proces and also existing user ...

What should I do?

Enhancement : Store template file names in variables

Hello,

In order to be able to use customized versions of the cnf templates, would it be possible to store each file name in a variable so they can be overloaded in a playbook?

Thank you in advance.

Kind regards,

missing password parameters in commands

in file bertvv.mariadb/tasks/root-password.yml in some sections is missing set of password parameter. I fixed it like this

- name: Check for previously set unix_socket in plugin column
  command: >
    mysql -N -s -S {{ mariadb_socket }} -u root -p{{ mariadb_root_password }} -e
    "SELECT plugin from mysql.user WHERE user = 'root'"
  register: plugin_root_result
  changed_when: plugin_root_result.stdout is search('unix_socket')
  when: root_pwd_check.rc == 0
  tags: mariadb

with -p{{ mariadb_root_password }} ...
It is also missing in Remove unix_socket plugin if previously set ...

Configure swappiness fails on some hosts

I have seen a problem with some hosts where the task to configure swappiness will fail due to permissions in the vm.
FAILED! => {"changed": false, "msg": "Failed to reload sysctl: net.ipv6.conf.all.disable_ipv6 = 1\nnet.ipv6.conf.default.disable_ipv6 = 1\nsysctl: permission denied on key 'vm.swappiness'\n"}
Would you be willing to add a way to bypass this step?

How do the calls to mysql_user work?

Hopefully an easy question - this role works for me absolutely perfectly but how do the calls to mysql_user actually work?

I presume it refers to the community.mysql.mysql_user module but I don't recall installing that and I don't see anywhere that this role sets it as a dependency.

So while this role works fine, I actually want to create my own role that requires the use of the mysql_user module but the apparent mystery of how it works in this role is confusing me.

Thanks.

Database initialisation is not idempotent

Using mariadb_init_scripts will call the SQL every time; thereby re-initialising the database (as per the SQL) every time.

This is not the expected thing, and the documentation should clearly highlight this behaviour. I would have expected the script to only execute if the database was missing.

I think a 'when' clause is needed in the following:

- name: Initialise databases
  mysql_db:
    name: "{{ item.database }}"
    state: import
    target: "/tmp/{{ item.script|basename }}"
  with_items: "{{ mariadb_init_scripts }}"
  tags: mariadb

(RHEL7.3 mariadb from package; Ansible 2.2.1.0)

multiple init scripts?

I have a database that should be initialized with multiple sql files.

This does not work, but is there some other way to do this?

      - name: mynewdb
        init_script: "{{ item }}"
      with_items:
        - /tmp/mynewdb-database/schema/tables.sql
        - /tmp/mynewdb-database/schema/routines.sql
        - /tmp/mynewdb-database/schema/data.sql
        - /tmp/mynewdb-database/schema/lookups.sql

Thanks.

Allow mariadb_init_scripts variable to work with templates

At present, this expects a list of non-Jinja2 files but it would be useful to be able to initialise databases using templated SQL scripts.

Move 'mariadb_service' from vars/ to defaults/.

Hi,
I like your role as it helps setting up MariaDB very easily on RedHad distributions. There is but one big issue with MariaDB 5.5 (which can be easily installed with this role).
On CentOS the service for MariaDB 5.5 is called mysql not mariadb.
Unfortunately the mariadb_service is located with the vars/ directory which makes it unchangeable/unconfigurable. This causes the role to fail for MariaDB <10.
I'd like to suggest moving this variable into the defaults/ directory so one has the chance to overwrite this variable.

This would be the fast solution. The better solution would be to check on the mariadb_version variable and change the mariadb_service variable to mysql if the version is lower then 10 on a CentOS distribution.

Running the role in CentOS 8 fails

CentOS 8 has made some changes that break this role. I've run into 3 problems so far:

1. For some reason, MariaDB doesn't install when the CentOS AppStream repo is enabled - yum can't seem to work around name conflicts. This can be solved by disabling the AppStream repo in the yum task, but that leads to problem 2....

2. Certain dependencies live in the AppStream repo and won't be found when the repo is disabled.

3. The MySQL-python package is now called python3-PyMySQL.

I've worked around this issue in my fork of the role with the following:

1. I created a CentOS.yml variable file that will be read in when running under CentOS.

2. I've added 2 new variables to this file, mariadb_disable_repos that defines repositories that need to be disabled when the yum task to install the DB runs, and mariadb_prerequisite_packages that defines a list of packages that need to be installed first, before we try to install the database itself. I've put boost-program-options and python3-PyMySQL in that list

3. I added a yum task to install.yml to install the prerequisite packages, if any are defined, and changed the existing yum task to disable repos in the mariadb_disable_repos string. If it isn't defined, I use an empty string here, which appears to work fine.

This implementation should work fine in RHEL and Fedora, as well as CentOS 8. I haven't done a pull request because my changes would break CentOS 7, but it might be a good place to start to get this working.