Adapt for MariaDB

[marshalls]

It would be nice if you could adapt this to work with MariaDB - especially since CentOS/RedHat has dropped MySQL in favor of MariaDB.

[gravyboat]

Looks like we don't currently have a formula for MariaDB. If you want to modify this and create one let me know and I can create a MariaDB-formula repo.

[nmadhok]

MySQL can still be installed using the community repo.

[star-szr]

For what it's worth, I was able to use this formula to install MariaDB 10.1. I'm on Debian and I haven't made this generic for other distros but here's what I have so far:

https://gist.github.com/Cottser/bfcca66820717a466065

Note that the "unless" requisite is only available in 2014.7.0+ (Helium).

Also included but (should be) optional is ignoring the my.cnf that the formula tries to write. I opted to use /etc/mysql/conf.d instead.

[meatheadmike]

How did you install from the mysql community repo? It looks like package names are prefixed with mysql-community. So this formula still wont pick 'em up :(

[gravyboat]

@cottser I believe the above comment is aimed at you.

[star-szr]

@meatheadmike who are you asking? I didn't mention the MySQL community repo, the comment above me did though. We may need more info from you to be able to help.

[meatheadmike]

This comment was aimed at @nmadhok. I'm on cent 7, so the formula currently does not work for me. He seemed to indicate that this could work with the community repo. But because of the naming convention used it does not. Sorry for the confusion guys.

[nmadhok]

@meatheadmike you're right that this formula won't pick the package names. We need to set the defaults for RHEL/Cent OS 7 in map.jinja. Could you submit a pull request for that?

[frnco]

@cottser if you could please excuse my ignorance, I am completely new to SaltStack, but how should one proceed to use your sls files?

From what I gather, I could just drop them in my /srv/salt directory (As with Geoff's version seen in https://mariadb.com/blog/mariadb-devops-installing-mariadb-saltstack), but I want to also make sure the service is enabled. While editing your sls would probably work, I'm interested in the possibility of extending it (As you did with mysql), so I could have cleaner files. Is that desirable, or even possible? Or should I just edit it?

[star-szr]

@frnco you should use my sls files in conjunction with this formula, this formula already handles making sure the service is enabled. The files I provided are only useful when used in conjunction with this formula. Here's the documentation on setting up formulas: http://docs.saltstack.com/en/latest/topics/development/conventions/formulas.html

Once you have the formula in place you need to reference a copy of the mariadb.sls file from my gist from your topfile (top.sls) in your salt directory (in your case /srv/salt), and reference the pillar.sls (likely with a different name) from the topfile (top.sls) of your pillar directory, by default /srv/pillar.

So as a simple, bare-bones example, here's how the files would be set up:

/srv/salt/top.sls:

base:
  '*':
    - mysql
    - mysql.mariadb

/srv/salt/mysql/mariadb.sls - the contents of mariadb.sls from my gist.

/srv/pillar/top.sls:

base:
  '*':
    - mysql

/srv/pillar/mysql/init.sls - the contents of pillar.sls from my gist.

Hope that helps!

[ogabrielsantos]

As of RHEL 7 default database are MariaDB.

You can use the follow workaround inside your top.sls pillar file.

mysql:
  lookup:
  {% if grains['os'] == 'CentOS' and grains['osmajorrelease'][0] == '7' %}
    server: mariadb-server
    client: mariadb
  {% endif %}

[kristjankullerkann]

Can I overwrite configuration parameters also the same way as follows:

  lookup:
    server: mariadb-server
    client: mariadb
    service: mariadb
    python: MySQL-python
    server_config:
      sections:
        mysqld_safe:
          log_error: /var/log/mariadb/mariadb.log
          pid-file: /var/run/mariadb/mariadb.pid

Tried but dosn't seem to work. I'm new to salt :)

[vschum]

Try changing 'server_config' to 'config' and see if that works.

On Fri, Apr 29, 2016 at 3:42 AM, litewhatever notifications@github.com
wrote:

Can I overwrite configuration parameters also the same way as follows:

lookup:
server: mariadb-server
client: mariadb
service: mariadb
python: MySQL-python
server_config:
sections:
mysqld_safe:
log_error: /var/log/mariadb/mariadb.log
pid-file: /var/run/mariadb/mariadb.pid

Tried but dosn't seem to work. I'm new to salt :)

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#43 (comment)

• Vincent Schumaker

[kristjankullerkann]

@vschum nop, dosn't help. Actually I worked around it by defining if-endif as follows.

mysql:
  server:
    root_password: 'pass'
    {% if grains['os'] == 'CentOS' and grains['osmajorrelease'] == '7' %}
    mysqld_safe:
      log_error: /var/log/mariadb/mariadb.log
      pid_file: /var/run/mariadb/mariadb.pid
    {% endif %}

[Sylvain303]

OK. Does exists some formula specific for mariaDB?

Or this one could be used by modifying the pillar?

https://github.com/saltstack-formulas/mysql-formula/blob/master/pillar.example

  # Override any names defined in map.jinja
  lookup:
    server: mysql-server
    client: mysql-client
    service: mysql-service
    python: python-mysqldb

server could become:

    server: mariadb-server

etc.

Does it make sens or not?

[kristjankullerkann]

@Sylvain303, yes it should work this way but you must probably also modify mysql config to changes paths for log_error and pid_file (at least this is the case with CentOS 7).

[Sylvain303]

@litewhatever, thanks. I play with @cottser gits to have a look. I'm working with debian jessie so mariaDB is already available as a package.

So you think we should not open a mariaDB specific formula, right?

[kristjankullerkann]

Yes but the parameters should perhaps be overwritable with lookup tables.
Sorry, I'm still quite new to salt and don't no all the ins and outs :)

[Sylvain303]

Some information.

I used @cottser gits above. under debian jessie.
But, it disables debconf the result is a root password not totally set:

MariaDB [mysql]> select user, host, password from user;
+------------------+-------------------+-------------------------------------------+
| user             | host              | password                                  |
+------------------+-------------------+-------------------------------------------+
| root             | localhost         | *B90D2F29F2877A8B076FEACC38F71F0D09005CB1 |
| root             | db0.somdomain.com |                                           |
| root             | 127.0.0.1         |                                           |
| root             | ::1               |                                           |
| debian-sys-maint | localhost         | *ABBD1A409A6AB052BC6DC3A8D471636A0D2555EF |
+------------------+-------------------+-------------------------------------------+

debconf seems not correctly set for mariaDB from minion command line it can be accomplished by:

export DEBIAN_FRONTEND="noninteractive"

pass=pipo

debconf-set-selections <<< "mariadb-server-10.0 mysql-server/root_password password $pass"
debconf-set-selections <<< "mariadb-server-10.0 mysql-server/root_password_again password $pass"

apt-get install -y mariadb-server

The password stay in debconf cache after salt has ran…

Can be found with:

debconf-get-selections | grep maria

It can be handled by adding some properties in the pillar and hacking server.sls

password still not purged.

can be done by:

echo PURGE | debconf-communicate mariadb-server-10.0

[Sylvain303]

in progress suggestion here: https://github.com/opensource-expert/mysql-formula/tree/add-mariaDB-support

How to install, is documented in README.rst. Feedback are welcome
If you know to setup a kitchen-salt for testing it would be great to have.

[gravyboat]

@Sylvain303 Do you want me to make a mariaDB formula repo?

[Sylvain303]

@gravyboat, After working on it, I don't think it needs a separate formula, doesn't it?
As you may have seen in the proposed branch above, changes for debian jessie are quite minimals.

MariaDB is working like mysql, such that command line tools are mysql* for mariaDB. So why to split?

It does needs many more test, though. ;)

[roock]

I also think there is no need for a seperate git repo for maria db. Arch linux only supports mariadb and the formula does work quite nicely with it

[wwentland]

The branch linked by @Sylvain303 contains some commits that are not strictly related to MariaDB or whose function is not obvious to me.

opensource-expert@ca6d624
for example adds a script to remove mariadb, but I don't understand why this is not being handled with suitable pkg.removed/pkg.purged states. Besides, we generally do not support package removal in a formula.

While some of the code introduced in that branch might be useful, I don't necessarily think that we should make it part of this formula.

I also don't like the introduction of the debconf-package variable. Is it really necessary to set it for mariadb-server-10.0 ? Is the Debian packaging that different between MySQL and MariaDB?

If it is I would rather remove debconf-package and ask users to use mariadb-server-10.0 as mysql.server value in lieu of the metapackage.

I guess this would merit a bug report to Debian as the debconf interface should be roughly comparable for mysql-server (and the versioned package it pulls in) and mariadb-server.

I'm also against creating a mariadb-formula as the adaptations to this formula should be minimal.

[Sylvain303]

@BABILEN don't attach too much importance of tools/ folder. Unless it is useful for you. I would remove it, if I reach a PR state for this issue. It is useful for me, repeating the formula, again, and again… It is an helper, that should be outside the formula as both import_users.py scripts. I' didn't write it as a state, because I didn't spent time to learn it.

Coming back to the main topic, this the pillar, I wrote, splitting

mysql.lookup.server, into mysql.lookup.debconf_package + mysql.lookup.debconf

Mainly to make it working for me, for now.

mysql:
  # […]
  lookup:
    server: mariadb-server
    client: mariadb-client
    debconf_package: mariadb-server-10.0
    debconf: mysql-server
    service: mysql
    python: python-mysqldb

As you noticed debconf entry must be in the form: mariadb-server-10.0 mysql-server/root_password

We have a mix up between mysql-server as an key for configuring the package, and mariadb-server-10.0 the selector for the wanted debian package.

Could some value be moved to defaults.yaml?

And have an alternative choice, for debian?
There is already some mariadb for other OS.

Fedora:
  server: mariadb-server
[…]

We have in server.sls: (module.debconf.set code)

server.sls diff

[wwentland]

The debconf situation is mirrored by the mysql packages, but they might implement it differently. Either way I'd rather not introduce a debconf_package key as I see that as an implementation detail.

I guess the packaging situation should be investigated in detail and if MySQL and MariaDB implement the debconf keys differently it would probably be a better idea to ask users to simply install mariadb-server-10.0 rather than mariadb-server.

And, frankly, if there is such a significant incompatibility in the packaging, I'd also like to see this fixed in Debian.