Coder Social home page Coder Social logo

puppetlabs-mysql's Introduction

mysql

Table of Contents

  1. Module Description - What the module does and why it is useful
  2. Setup - The basics of getting started with mysql
  3. Usage - Configuration options and additional functionality
  4. Reference - An under-the-hood peek at what the module is doing and how
  5. Limitations - OS compatibility, etc.
  6. License
  7. Development - Guide for contributing to the module

Module Description

The mysql module installs, configures, and manages the MySQL service.

This module manages both the installation and configuration of MySQL, as well as extending Puppet to allow management of MySQL resources, such as databases, users, and grants.

Setup

Beginning with mysql

To install a server with the default options:

include mysql::server.

To customize options, such as the root password or /etc/my.cnf settings, you must also pass in an override hash:

class { 'mysql::server':
  root_password           => 'strongpassword',
  remove_default_accounts => true,
  restart                 => true,
  override_options        => $override_options,
}

Nota bene: Configuration changes will only be applied to the running MySQL server if you pass true as restart to mysql::server.

See Customize Server Options below for examples of the hash structure for $override_options.

Usage

All interaction for the server is done via mysql::server. To install the client, use mysql::client. To install bindings, use mysql::bindings.

Customize server options

To define server options, structure a hash structure of overrides in mysql::server. This hash resembles a hash in the my.cnf file:

$override_options = {
  'section' => {
    'item' => 'thing',
  },
}

For options that you would traditionally represent in this format:

[section]
thing = X

Entries can be created as thing => true, thing => value, or thing => "" in the hash. Alternatively, you can pass an array as thing => ['value', 'value2'] or list each thing => value separately on individual lines.

You can pass a variable in the hash without setting a value for it; the variable would then use MySQL's default settings. To exclude an option from the my.cnf file --- for example, when using override_options to revert to a default value --- pass thing => undef.

If an option needs multiple instances, pass an array. For example,

$override_options = {
  'mysqld' => {
    'replicate-do-db' => ['base1', 'base2'],
  },
}

produces

[mysqld]
replicate-do-db = base1
replicate-do-db = base2

To implement version specific parameters, specify the version, such as [mysqld-5.5]. This allows one config for different versions of MySQL.

If you don’t want to use the default configuration, you can also supply your options to the $options parameter instead of $override_options. Please note that $options and $override_options are mutually exclusive, you can only use one of them.

By default, the puppet won't reload/restart mysqld when you change an existing configuration. If you want to do that, you can set mysql::server::reload_on_config_change to true.

Create a database

To create a database with a user and some assigned privileges:

mysql::db { 'mydb':
  user     => 'myuser',
  password => 'mypass',
  host     => 'localhost',
  grant    => ['SELECT', 'UPDATE'],
}

To use a different resource name with exported resources:

 @@mysql::db { "mydb_${fqdn}":
  user     => 'myuser',
  password => 'mypass',
  dbname   => 'mydb',
  host     => ${fqdn},
  grant    => ['SELECT', 'UPDATE'],
  tag      => $domain,
}

Then you can collect it on the remote DB server:

Mysql::Db <<| tag == $domain |>>

If you set the sql parameter to a file when creating a database, the file is imported into the new database.

For large sql files, increase the import_timeout parameter, which defaults to 300 seconds.

If you have installed the mysql client in a non standard bin/sbin path you can set this with mysql_exec_path .

mysql::db { 'mydb':
  user            => 'myuser',
  password        => 'mypass',
  host            => 'localhost',
  grant           => ['SELECT', 'UPDATE'],
  sql             => ['/path/to/sqlfile.gz'],
  import_cat_cmd  => 'zcat',
  import_timeout  => 900,
  mysql_exec_path => '/opt/rh/rh-myql57/root/bin',
}

Customize configuration

To add custom MySQL configuration, place additional files into includedir. This allows you to override settings or add additional ones, which is helpful if you don't use override_options in mysql::server. The includedir location is by default set to /etc/mysql/conf.d.

Managing Root Passwords

If you want the password managed by puppet for 127.0.0.1 and ::1 as an end user you would need to explicitly manage them with additional manifest entries. For example:

mysql_user { '[[email protected]]':
  ensure        => present,
  password_hash => mysql::password($mysql::server::root_password),
}

mysql_user { 'root@::1':
  ensure        => present,
  password_hash => mysql::password($mysql::server::root_password),
}

Note: This module is not designed to carry out additional DNS and aliasing.

Work with an existing server

To instantiate databases and users on an existing MySQL server, you need a .my.cnf file in root's home directory. This file must specify the remote server address and credentials. For example:

[client]
user=root
host=localhost
password=secret

This module uses the mysqld_version fact to discover the server version being used. By default, this is set to the output of mysqld -V. If you're working with a remote MySQL server, you may need to set a custom fact for mysqld_version to ensure correct behaviour.

When working with a remote server, do not use the mysql::server class in your Puppet manifests.

Specify passwords

In addition to passing passwords as plain text, you can input them as hashes. For example:

mysql::db { 'mydb':
  user     => 'myuser',
  password => '*6C8989366EAF75BB670AD8EA7A7FC1176A95CEF4',
  host     => 'localhost',
  grant    => ['SELECT', 'UPDATE'],
}

If required, the password can also be an empty string to allow connections without an password.

Create login paths

This feature works only for the MySQL Community Edition >= 5.6.6.

A login path is a set of options (host, user, password, port and socket) that specify which MySQL server to connect to and which account to authenticate as. The authentication credentials and the other options are stored in an encrypted login file named .mylogin.cnf typically under the users home directory.

More information about MySQL login paths: https://dev.mysql.com/doc/refman/8.0/en/mysql-config-editor.html.

Some example for login paths:

mysql_login_path { 'client':
  owner    => root,
  host     => 'localhost',
  user     => 'root',
  password => Sensitive('secure'),
  socket   => '/var/run/mysqld/mysqld.sock',
  ensure   => present,
}

mysql_login_path { 'remote_db':
  owner    => root,
  host     => '10.0.0.1',
  user     => 'network',
  password => Sensitive('secure'),
  port     => 3306,
  ensure   => present,
}

See examples/mysql_login_path.pp for further examples.

Install Percona server on CentOS

This example shows how to do a minimal installation of a Percona server on a CentOS system. This sets up the Percona server, client, and bindings (including Perl and Python bindings). You can customize this usage and update the version as needed.

This usage has been tested on Puppet 4.4, 5.5 and 6.3.0 / CentOS 7 / Percona Server 5.7.

Note: The installation of the yum repository is not part of this package and is here only to show a full example of how you can install.

yumrepo { 'percona':
  descr    => 'CentOS $releasever - Percona',
  baseurl  => 'http://repo.percona.com/percona/yum/release/$releasever/RPMS/$basearch',
  gpgkey   => 'https://repo.percona.com/yum/PERCONA-PACKAGING-KEY',
  enabled  => 1,
  gpgcheck => 1,
}

class { 'mysql::server':
  package_name     => 'Percona-Server-server-57',
  service_name     => 'mysql',
  config_file      => '/etc/my.cnf',
  includedir       => '/etc/my.cnf.d',
  root_password    => 'PutYourOwnPwdHere',
  override_options => {
    mysqld => {
      log-error => '/var/log/mysqld.log',
      pid-file  => '/var/run/mysqld/mysqld.pid',
    },
    mysqld_safe => {
      log-error => '/var/log/mysqld.log',
    },
  },
}

# Note: Installing Percona-Server-server-57 also installs Percona-Server-client-57.
# This shows how to install the Percona MySQL client on its own
class { 'mysql::client':
  package_name => 'Percona-Server-client-57',
}

# These packages are normally installed along with Percona-Server-server-57
# If you needed to install the bindings, however, you could do so with this code
class { 'mysql::bindings':
  client_dev_package_name => 'Percona-Server-shared-57',
  client_dev              => true,
  daemon_dev_package_name => 'Percona-Server-devel-57',
  daemon_dev              => true,
  perl_enable             => true,
  perl_package_name       => 'perl-DBD-MySQL',
  python_enable           => true,
  python_package_name     => 'MySQL-python',
}

# Dependencies definition
Yumrepo['percona']->
Class['mysql::server']

Yumrepo['percona']->
Class['mysql::client']

Yumrepo['percona']->
Class['mysql::bindings']

Install MariaDB on Ubuntu

Optional: Install the MariaDB official repo

In this example, we'll use the latest stable (currently 10.3) from the official MariaDB repository, not the one from the distro repository. You could instead use the package from the Ubuntu repository. Make sure you use the repository corresponding to the version you want.

Note: sfo1.mirrors.digitalocean.com is one of many mirrors available. You can use any official mirror.

include apt

apt::source { 'mariadb':
  location => 'http://sfo1.mirrors.digitalocean.com/mariadb/repo/10.3/ubuntu',
  release  => $::facts['os']['codename'],
  repos    => 'main',
  key      => {
    id     => '177F4010FE56CA3336300305F1656F24C74CD1D8',
    server => 'hkp://keyserver.ubuntu.com:80',
  },
  include => {
    src   => false,
    deb   => true,
  },
}

Install the MariaDB server

This example shows MariaDB server installation on Ubuntu Xenial. Adjust the version and the parameters of my.cnf as needed. All parameters of the my.cnf can be defined using the override_options parameter.

The folders /var/log/mysql and /var/run/mysqld are created automatically, but if you are using other custom folders, they should exist as prerequisites for this code.

All the values set here are an example of a working minimal configuration.

Specify the version of the package you want with the package_ensure parameter.

class { 'mysql::server':
  package_name     => 'mariadb-server',
  package_ensure   => '1:10.3.21+maria~xenial',
  service_name     => 'mysqld',
  root_password    => 'AVeryStrongPasswordUShouldEncrypt!',
  override_options => {
    mysqld => {
      'log-error' => '/var/log/mysql/mariadb.log',
      'pid-file'  => '/var/run/mysqld/mysqld.pid',
    },
    mysqld_safe => {
      'log-error' => '/var/log/mysql/mariadb.log',
    },
  },
}

# Dependency management. Only use that part if you are installing the repository
# as shown in the Preliminary step of this example.
Apt::Source['mariadb'] ~>
Class['apt::update'] ->
Class['mysql::server']

Install the MariaDB client

This example shows how to install the MariaDB client and all of the bindings at once. You can do this installation separately from the server installation.

Specify the version of the package you want with the package_ensure parameter.

class { 'mysql::client':
  package_name    => 'mariadb-client',
  package_ensure  => '1:10.3.21+maria~xenial',
  bindings_enable => true,
}

# Dependency management. Only use that part if you are installing the repository as shown in the Preliminary step of this example.
Apt::Source['mariadb'] ~>
Class['apt::update'] ->
Class['mysql::client']

Install MySQL Community server on CentOS

You can install MySQL Community Server on CentOS using the mysql module and Hiera. This example was tested with the following versions:

  • MySQL Community Server 5.6
  • Centos 7.3
  • Puppet 3.8.7 using Hiera
  • puppetlabs-mysql module v3.9.0

In Puppet:

include mysql::server

create_resources(yumrepo, hiera('yumrepo', {}))

Yumrepo['repo.mysql.com'] -> Anchor['mysql::server::start']
Yumrepo['repo.mysql.com'] -> Package['mysql_client']

create_resources(mysql::db, hiera('mysql::server::db', {}))

In Hiera:

---

# Centos 7.3
yumrepo:
  'repo.mysql.com':
    baseurl: "http://repo.mysql.com/yum/mysql-5.6-community/el/%{::operatingsystemmajrelease}/$basearch/"
    descr: 'repo.mysql.com'
    enabled: 1
    gpgcheck: true
    gpgkey: 'http://repo.mysql.com/RPM-GPG-KEY-mysql'

mysql::client::package_name: "mysql-community-client" # required for proper MySQL installation
mysql::server::package_name: "mysql-community-server" # required for proper MySQL installation
mysql::server::package_ensure: 'installed' # do not specify version here, unfortunately yum fails with error that package is already installed
mysql::server::root_password: "change_me_i_am_insecure"
mysql::server::manage_config_file: true
mysql::server::service_name: 'mysqld' # required for puppet module
mysql::server::override_options:
  'mysqld':
    'bind-address': '127.0.0.1'
    'log-error': '/var/log/mysqld.log' # required for proper MySQL installation
  'mysqld_safe':
    'log-error': '/var/log/mysqld.log'  # required for proper MySQL installation

# create database + account with access, passwords are not encrypted
mysql::server::db:
  "dev":
    user: "dev"
    password: "devpass"
    host: "127.0.0.1"
    grant:
      - "ALL"

Install Plugins

Plugins can be installed by using the mysql_plugin defined type. See examples/mysql_plugin.pp for futher examples.

Use Percona XtraBackup

This example shows how to configure MySQL backups with Percona XtraBackup. This sets up a weekly cronjob to perform a full backup and additional daily cronjobs for incremental backups. Each backup will create a new directory. A cleanup job will automatically remove backups that are older than 15 days.

yumrepo { 'percona':
  descr    => 'CentOS $releasever - Percona',
  baseurl  => 'http://repo.percona.com/release/$releasever/RPMS/$basearch',
  gpgkey   => 'https://www.percona.com/downloads/RPM-GPG-KEY-percona https://repo.percona.com/yum/PERCONA-PACKAGING-KEY',
  enabled  => 1,
  gpgcheck => 1,
}

class { 'mysql::server::backup':
  backupuser        => 'myuser',
  backuppassword    => 'mypassword',
  backupdir         => '/tmp/backups',
  provider          => 'xtrabackup',
  backuprotate      => 15,
  execpath          => '/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin',
  time              => ['23', '15'],
}

If the daily or weekly backup was successful, then the empty file /tmp/mysqlbackup_success is created, which makes it easy to monitor the status of the database backup.

After two weeks the backup directory should look similar to the example below.

/tmp/backups/2019-11-10_full
/tmp/backups/2019-11-11_23-15-01
/tmp/backups/2019-11-13_23-15-01
/tmp/backups/2019-11-13_23-15-02
/tmp/backups/2019-11-14_23-15-01
/tmp/backups/2019-11-15_23-15-02
/tmp/backups/2019-11-16_23-15-01
/tmp/backups/2019-11-17_full
/tmp/backups/2019-11-18_23-15-01
/tmp/backups/2019-11-19_23-15-01
/tmp/backups/2019-11-20_23-15-02
/tmp/backups/2019-11-21_23-15-01
/tmp/backups/2019-11-22_23-15-02
/tmp/backups/2019-11-23_23-15-01

A drawback of using incremental backups is the need to keep at least 7 days of backups, otherwise the full backups is removed early and consecutive incremental backups will fail. Furthermore an incremental backups becomes obsolete once the required full backup was removed.

The next example uses XtraBackup with incremental backups disabled. In this case the daily cronjob will always perform a full backup.

class { 'mysql::server::backup':
  backupuser          => 'myuser',
  backuppassword      => 'mypassword',
  backupdir           => '/tmp/backups',
  provider            => 'xtrabackup',
  incremental_backups => false,
  backuprotate        => 5,
  execpath            => '/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin',
  time                => ['23', '15'],
}

The next example shows how to use mariabackup (a fork of xtrabackup) as a backup provider. Note that on most Linux/BSD distributions, this will require setting backupmethod_package => 'mariadb-backup' in the mysql::server::backup declaration in order to override the default xtrabackup package (percona-xtrabackup).

class { 'mysql::server':
  package_name            => 'mariadb-server',
  package_ensure          => '1:10.3.21+maria~xenial',
  service_name            => 'mysqld',
  root_password           => 'AVeryStrongPasswordUShouldEncrypt!',
}

class { 'mysql::server::backup':
  backupuser              => 'mariabackup',
  backuppassword          => 'AVeryStrongPasswordUShouldEncrypt!',
  provider                => 'xtrabackup',
  backupmethod            => 'mariabackup',
  backupmethod_package    => 'mariadb-backup',
  backupdir               => '/tmp/backups',
  backuprotate            => 15,
  execpath                => '/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin',
  time                    => ['23', '15'],
}

Reference

Classes

Public classes

Private classes

  • mysql::server::install: Installs packages.
  • mysql::server::installdb: Implements setup of mysqld data directory (e.g. /var/lib/mysql)
  • mysql::server::config: Configures MYSQL.
  • mysql::server::service: Manages service.
  • mysql::server::account_security: Deletes default MySQL accounts.
  • mysql::server::root_password: Sets MySQL root password.
  • mysql::server::providers: Creates users, grants, and databases.
  • mysql::bindings::client_dev: Installs MySQL client development package.
  • mysql::bindings::daemon_dev: Installs MySQL daemon development package.
  • mysql::bindings::java: Installs Java bindings.
  • mysql::bindings::perl: Installs Perl bindings.
  • mysql::bindings::php: Installs PHP bindings.
  • mysql::bindings::python: Installs Python bindings.
  • mysql::bindings::ruby: Installs Ruby bindings.
  • mysql::client::install: Installs MySQL client.
  • mysql::backup::mysqldump: Implements mysqldump backups.
  • mysql::backup::mysqlbackup: Implements backups with Oracle MySQL Enterprise Backup.
  • mysql::backup::xtrabackup: Implements backups with XtraBackup from Percona or Mariabackup.

Parameters

mysql::server

create_root_user

Whether root user should be created.

Valid values are true, false.

Defaults to true.

This is useful for a cluster setup with Galera. The root user has to be created only once. You can set this parameter true on one node and set it to false on the remaining nodes.

create_root_my_cnf

Whether to create /root/.my.cnf.

Valid values are true, false.

Defaults to true.

create_root_my_cnf allows creation of /root/.my.cnf independently of create_root_user. You can use this for a cluster setup with Galera where you want /root/.my.cnf to exist on all nodes.

root_password

The MySQL root password. Puppet attempts to set the root password and update /root/.my.cnf with it.

This is required if create_root_user or create_root_my_cnf are true. If root_password is 'UNSET', then create_root_user and create_root_my_cnf are assumed to be false --- that is, the MySQL root user and /root/.my.cnf are not created.

Password changes are supported; however, the old password must be set in /root/.my.cnf. Effectively, Puppet uses the old password, configured in /root/my.cnf, to set the new password in MySQL, and then updates /root/.my.cnf with the new password.

old_root_password

This parameter no longer does anything. It exists only for backwards compatibility. See the root_password parameter above for details on changing the root password.

create_root_login_file

Whether to create /root/.mylogin.cnf when using mysql 5.6.6+.

Valid values are true, false.

Defaults to false.

create_root_login_file will put a copy of your existing .mylogin.cnf in the /root/.mylogin.cnf location.

When set to 'true', this option also requires the login_file option.

The login_file option is required when set to true.

login_file

Whether to put the /root/.mylogin.cnf in place.

You need to create the .mylogin.cnf file with mysql_config_editor, this tool comes with mysql 5.6.6+.

The created .mylogin.cnf needs to be put under files in your module, see example below on how to use this.

When the /root/.mylogin.cnf exists the environment variable MYSQL_TEST_LOGIN_FILE will be set.

This is required if create_root_user and create_root_login_file are true. If root_password is 'UNSET', then create_root_user and create_root_login_file are assumed to be false --- that is, the MySQL root user and /root/.mylogin.cnf are not created.

class { 'mysql::server':
  root_password          => 'password',
  create_root_my_cnf     => false,
  create_root_login_file => true,
  login_file             => 'puppet:///modules/${module_name}/mylogin.cnf',
}
override_options

Specifies override options to pass into MySQL. Structured like a hash in the my.cnf file:

class { 'mysql::server':
  root_password => 'password'
}

mysql_plugin { 'auth_pam':
  ensure => present,
  soname => 'auth_pam.so',
}

Tasks

The MySQL module has an example task that allows a user to execute arbitary SQL against a database. Please refer to to the PE documentation or Bolt documentation on how to execute a task.

Limitations

This module lacks compatibility with the ARM architecture, for an extensive list of supported operating systems, see metadata.json

Note: The mysqlbackup.sh does not work and is not supported on MySQL 5.7 and greater.

License

This codebase is licensed under the Apache2.0 licensing, however due to the nature of the codebase the open source dependencies may also use a combination of AGPL, BSD-2, BSD-3, GPL2.0, LGPL, MIT and MPL Licensing.

Development

We are experimenting with a new tool for running acceptance tests. Its name is puppet_litmus this replaces beaker as the test runner. To run the acceptance tests follow the instructions from the Litmus documentation.

Puppet modules on the Puppet Forge are open projects, and community contributions are essential for keeping them great. We can't access the huge number of platforms and myriad of hardware, software, and deployment configurations that Puppet is intended to serve.

We want to keep it as easy as possible to contribute changes so that our modules work in your environment. There are a few guidelines that we need contributors to follow so that we can have a chance of keeping on top of things.

Check out our the complete module contribution guide.

Authors

This module is based on work by David Schmitt. Thank you to all of our contributors.

puppetlabs-mysql's People

Contributors

abraham1901 avatar apenney avatar bastelfreak avatar bmjen avatar bodepd avatar chelnak avatar cmurphy avatar cyberious avatar daianamezdrea avatar david22swan avatar davids avatar eimlav avatar eputnam avatar hail9000 avatar hunner avatar igalic avatar jonnytdevops avatar jordanbreen28 avatar kbarber avatar lionce avatar lukasaud avatar malikparvez avatar michaeltlombardi avatar nanliu avatar pmcmaw avatar ramesh7 avatar razorsedge avatar sheenaajay avatar tphoney avatar transifex-bot avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

puppetlabs-mysql's Issues

mysql_grant being called again on each puppet update

I am using the latest version 2.0-rc5 and have the problem where my mysql_grant gets called on each update which somehow means that the mysql module does not recognise that it already applied this grant.

Below is the relevant part of my manifest:

    mysql_user { "${username}@${hostname}":
        ensure          => 'present',
        password_hash   => $password,
    }

    mysql_grant { "${username}@${hostname}/*.*":
        ensure          => 'present',
        options         => ['GRANT'],
        privileges      => ['CREATE USER','ALTER','CREATE','DELETE','DROP','INDEX','INSERT','SELECT','UPDATE','LOCK TABLES','CREATE VIEW','SHOW VIEW','ALTER ROUTINE','CREATE ROUTINE','EXECUTE'],
        table           => '*.*',
        user            => "${username}@${hostname}",
    }

is this a bug or am I doing something wrong here?

support overriding additional options from mysql::params

From looking it seems there is no way to override certain parameters such as client_package_name. Since not all the parameters are passed to the appropriate mysql::client or mysql::server, it's hard to changes these except in mysql::params manually.

We use Percona server so we prefer to use their package name specifically.

mysql_grant broken

There are a couple of issues with mysql_grant. I''m just summarizing them all in this one issue since they are interrelated.

  1. The $user parameter has become mandatory but that is not validated. Leaving out $user gives this in the puppet agent log:
    Error: Could not set 'present' on ensure: private method sub' called for nil:NilClass atsome line in your code callingmysql_grant`
  2. The MySQL ON parameter of the GRANT statement is not optional according to Mysql manual: http://dev.mysql.com/doc/refman/5.1/en/grant.html . However the code seems to leave the ON clause out which results in:
Error: ...some resource/Mysql_grant[user@host/database.*]/ensure: change from absent to present failed: Execution of '/usr/bin/mysql --defaults-file=/root/.my.cnf -e GRANT ALL PRIVILEGES TO 'user'@'host' returned 1: ERROR 1064 (42000) at line 1: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'TO 'user'@'host'' at line 1

override_options broken since refactoring

According to README, one can override single options in my.cnf like this:

class { '::mysql::globals':
  override_options => { 'mysqld' => { 'max_connections' => '1024' } }
}

Unfortunately, this does not work as expected; merge() is not recursive.

wildcard in host parameter

I got the following error message when I try to use wildcard in host parameter:

Error: Could not prefetch mysql_grant provider 'mysql': Execution of '/usr/bin/mysql --defaults-file=/root/.my.cnf -NBe SHOW GRANTS FOR [email protected].%;' returned 1: ERROR 1064 (42000) at line 1: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '%' at line 1

.pp file has something like this:

mysql::db { 'mydb':
  user     => 'myuser',
  password => 'mypass',
  host     => '10.93.2.%',
  grant    => ['all'],
} 

It seems it doesn't like the wildcard. If I use localhost or full IP address, everything works fine.

Must be able to specify bind address

By default, Debian/ubuntu server package listens on 127.0.0.1 only. Must be able to manage /etc/mysql/my.cnf in some way to at least specify where the server will be listening.

/usr/sbin/service is not the correct path in some systems

Error: /Stage[main]/Mysql::Server/Exec[mysqld-restart]: Failed to call refresh: Could not find command '/usr/sbin/service'

This is true for some systems, but some systems use /sbin/service

CentOS 6.3 x86_64

[vagrant@localhost ~]$ uname -a
Linux localhost.localdomain 2.6.32-358.el6.x86_64 #1 SMP Fri Feb 22 00:31:26 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
[vagrant@localhost ~]$ sudo su -c 'which service'
/sbin/service

mysql::db is failing w/ puppet 2.6.18 and stdlib 2.6.0

mysql::db silently doesn't work using puppet 2.6.18 and stdlib 2.6.0 on CentOS 6.4. Using the default CentOS 6.4 puppet master. Downloaded the 2.6.0 stdlib from puppetforge just yesterday. Logs don't show it trying to build the db or add the user.

The only thing in the logs are:

Jul 30 16:58:53 swebb-test25 puppet-agent[5114]: Finished catalog run in 2.20 seconds
Jul 30 17:28:55 swebb-test25 puppet-agent[5114]: (/Stage[main]/Mysql::Backup/File[mysqlbackupdir]/owner) owner changed 'nobody' to 'root'
Jul 30 17:28:55 swebb-test25 puppet-agent[5114]: (/Stage[main]/Mysql::Backup/File[mysqlbackupdir]/group) group changed 'nobody' to 'root'
Jul 30 17:28:55 swebb-test25 puppet-agent[5114]: Finished catalog run in 1.78 seconds

On the puppet master, I see only the compiling output:

Jul 30 11:58:56 puppet puppet-master[10969]: Compiled catalog for swebb-test25.dishanywhere.com in environment production in 0.15 seconds

mysql::server::account_security does not remove anonymous users in mysql.db

Hi.

Possibly only when using percona-server , but when declaring mysql::server::account_security, there are still two entries in the mysql.db table:

mysql> select Host,DB,User from mysql.db;
+------+---------+------+
| Host | DB      | User |
+------+---------+------+
| %    | test    |      |
| %    | test\_% |      |
+------+---------+------+
2 rows in set (0.00 sec)

When running mysql_secure_installation, these entries are removed properly.
Usually, users in mysql.db have also entries in mysql.users. In this case, these entries are nonexistent. Although this absence in the mysql.users table can be a bug in percona-server, I think this class should remove the anonymous users from the mysql.db table nonetheless.

The following resource declaration in the class should be removing them ( the '@%' user matches ):

  database_user {
    [ "root@${::fqdn}",
      '[email protected]',
      'root@::1',
      "@${::fqdn}",
      '@localhost',
      '@%']:
    ensure  => 'absent',
    require => Class['mysql::config'],
  }

mysql_database does not create database with correct collation

When specifying a mysql_database resource with a collation type other than the default, the resource creates the database without setting the collation. This causes the initial puppet run to create the database with an incorrect collation, which is then corrected by the next run with the same manifest.

mysql::server::backup and --flush-logs and empty dump file

Running Debian 7 here and using the mysql::server::backup to automate backups of my MySQL server. Unfortunately it does not work, I get an empty dump file. Looking at the mysqlbackup.sh script I noticed that if I run the same dump without the "--flush-logs" the dump works.

As such I think it would be nice to have an option in the module to disable this "--flush-logs" parameter.

mysql_grant regex

Hello,

I might be wrong, but I think the regex for the mysql_grant provider be something more like:

if match = munged_grant.match
  (/^GRANT\s(.*)\sON\s(.*)\sTO\s([\w.:]+@[\w.:]+)(\s.*)$/)

Note the addition of characters such as "." and ":" toward the end. By just having \w+, fqdns, ipv4 addresses, and ipv6 addresses are excluded from being captured.

Thanks,
Joe

Error installing on Debian 6

node 'box1.rhysd.co.nz' {
 class { 'mysql::server':
  config_hash => { 'root_password' => 'blahalchlach' }
  }
}
Info: Retrieving plugin
Info: Caching catalog for box1.rhysd.co.nz
Info: Applying configuration version '1372045603'
Error: Execution of '/usr/bin/apt-get -q -y -o DPkg::Options::=--force-confold install mysql-server' returned 100: Reading package lists...
Building dependency tree...
Reading state information...
The following extra packages will be installed:
  mysql-server-5.1
Suggested packages:
  tinyca
The following NEW packages will be installed:
  mysql-server mysql-server-5.1
Preconfiguring packages ...
0 upgraded, 2 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/6663 kB of archives.
After this operation, 15.1 MB of additional disk space will be used.
Selecting previously deselected package mysql-server-5.1.
(Reading database ... 13818 files and directories currently installed.)
Unpacking mysql-server-5.1 (from .../mysql-server-5.1_5.1.49-3_amd64.deb) ...
egrep: /etc/mysql/: No such file or directory
Selecting previously deselected package mysql-server.
Unpacking mysql-server (from .../mysql-server_5.1.49-3_all.deb) ...
Processing triggers for man-db ...
Setting up mysql-server-5.1 (5.1.49-3) ...
Stopping MySQL database server: mysqld.
/etc/init.d/mysql: WARNING: /etc/mysql/my.cnf cannot be read. See README.Debian.gz ... (warning).
Starting MySQL database server: mysqld . . . . . . . . . . . . . . failed!
invoke-rc.d: initscript mysql, action "start" failed.
dpkg: error processing mysql-server-5.1 (--configure):
 subprocess installed post-installation script returned error exit status 1
configured to not write apport reports
dpkg: dependency problems prevent configuration of mysql-server:
 mysql-server depends on mysql-server-5.1; however:
  Package mysql-server-5.1 is not configured yet.
dpkg: error processing mysql-server (--configure):
 dependency problems - leaving unconfigured
configured to not write apport reports
Errors were encountered while processing:
 mysql-server-5.1
 mysql-server
E: Sub-process /usr/bin/dpkg returned an error code (1)

Error: /Stage[main]/Mysql::Server/Package[mysql-server]/ensure: change from purged to present failed: Execution of '/usr/bin/apt-get -q -y -o DPkg::Options::=--force-confold install mysql-server' returned 100: Reading package lists...
Building dependency tree...
Reading state information...
The following extra packages will be installed:
  mysql-server-5.1
Suggested packages:
  tinyca
The following NEW packages will be installed:
  mysql-server mysql-server-5.1
Preconfiguring packages ...
0 upgraded, 2 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/6663 kB of archives.
After this operation, 15.1 MB of additional disk space will be used.
Selecting previously deselected package mysql-server-5.1.
(Reading database ... 13818 files and directories currently installed.)
Unpacking mysql-server-5.1 (from .../mysql-server-5.1_5.1.49-3_amd64.deb) ...
egrep: /etc/mysql/: No such file or directory
Selecting previously deselected package mysql-server.
Unpacking mysql-server (from .../mysql-server_5.1.49-3_all.deb) ...
Processing triggers for man-db ...
Setting up mysql-server-5.1 (5.1.49-3) ...
Stopping MySQL database server: mysqld.
/etc/init.d/mysql: WARNING: /etc/mysql/my.cnf cannot be read. See README.Debian.gz ... (warning).
Starting MySQL database server: mysqld . . . . . . . . . . . . . . failed!
invoke-rc.d: initscript mysql, action "start" failed.
dpkg: error processing mysql-server-5.1 (--configure):
 subprocess installed post-installation script returned error exit status 1
configured to not write apport reports
dpkg: dependency problems prevent configuration of mysql-server:
 mysql-server depends on mysql-server-5.1; however:
  Package mysql-server-5.1 is not configured yet.
dpkg: error processing mysql-server (--configure):
 dependency problems - leaving unconfigured
configured to not write apport reports
Errors were encountered while processing:
 mysql-server-5.1
 mysql-server
E: Sub-process /usr/bin/dpkg returned an error code (1)

osfamily => Debian

Am I missing something here?

Posibility to set more than one Mysql:Db host

My typical usecase of using MySQL is, that I work with database localy from vagrant (localhost), but manage db outside the Vagrant (from client application trough port forwarding). To set this configuration, I need to have this config:

mysql::db { 'database':
  user     => 'user',
  password => 'password',
  host     => 'localhost',
  grant    => ['all'],
}

database_grant { 'user@%/database':
  privileges => ['all'] ,
}

It could be usefull to have posibility to have config like

mysql::db { 'database':
  user     => 'user',
  password => 'password',
  hosts    => ['localhost','%']
  grant    => ['all'],
}

mariaDB support ?

Hello Guys,

Any ideas about how to implement / consider mariaDB ?

Many Thanks,

mysql_grant is not idempotent

when used as a standalone type or from mysql::db, mysql_grant will always grant the permissions even if these permissions are already granted.
As a consequence, the node is marked as "changed" in Dashboard or any other reporting tool.

mysql_grant should check the permissions first, and grant the new ones only if they are not already granted.

Could not prefetch mysql_grant provider

I get this message on a puppet run:

Error: Could not prefetch mysql_grant provider 'mysql': Execution of '/usr/bin/mysql --defaults-file=/root/.my.cnf -NBe SHOW GRANTS FOR 'root'@'yomamma';' returned 1: ERROR 1141 (42000) at line 1: There is no such grant defined for user 'root' on host 'yomamma'

Some info from mysql:

MariaDB [(none)]> select user, host from mysql.user;
+------------------+-----------+
| user | host |
+------------------+-----------+
| root | 127.0.0.1 |
| root | ::1 |
| root | yomama |
| debian-sys-maint | localhost |
| mmm_agent | localhost |
| mmm_monitor | localhost |
| mmm_reader | localhost |
| mmm_writer | localhost |
| replication | localhost |
| root | localhost |
+------------------+-----------+
10 rows in set (0.00 sec)

MariaDB [(none)]> SHOW GRANTS FOR 'root'@'yomamma';
ERROR 1141 (42000): There is no such grant defined for user 'root' on host 'yomamma'
MariaDB [(none)]> SHOW GRANTS FOR root@yomamma;
ERROR 1141 (42000): There is no such grant defined for user 'root' on host 'yomamma'
MariaDB [(none)]> SHOW GRANTS FOR root@yomamma;
ERROR 1141 (42000): There is no such grant defined for user 'root' on host 'yomamma'
MariaDB [(none)]> SHOW GRANTS FOR root@127.0.0.1;
+----------------------------------------------------------------------------------------------------------------------------------------+
| Grants for [email protected] |
+----------------------------------------------------------------------------------------------------------------------------------------+
| GRANT ALL PRIVILEGES ON . TO 'root'@'127.0.0.1' IDENTIFIED BY PASSWORD '*D1A4CE85A15D483A108CE9908404169874531C50' WITH GRANT OPTION |
+----------------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.00 sec)

MariaDB [(none)]> show global variables like '%resolve%';
+-------------------+-------+
| Variable_name | Value |
+-------------------+-------+
| skip_name_resolve | ON |
+-------------------+-------+
1 row in set (0.00 sec)

remove need to pass root_password twice

in order for the root_password to be set in the /root/.my.cnf and also manage it with mysql_user, you have to pass root_password to mysql_server and also add root_password to the override_options hash. Why not merge in the root_password parameter into the options hash as a third hash, something like:

$root_pw_hash = { root_password => $root_password }
$options = mysql_deepmerge($mysql::params::default_options, $override_options, $root_pw_hash)

This way in mysql::server::root_password template it can continue to lookup the root_password from the options hash. You would also change the if statement to be like

if $mysql::server::options['root_password'] != 'UNSET' {

"Could not prefetch"… Where to specify root password?

I have now encountered these errors on two different production servers, always when there already was a mysql service defined (but not via Puppet).

err: Could not prefetch mysql_database provider 'mysql': Execution of '/usr/bin/mysql -NBe show databases' returned 1: ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: NO)

err: Could not prefetch mysql_grant provider 'mysql': Execution of '/usr/bin/mysql -NBe SELECT CONCAT(User, '@',Host) AS User FROM mysql.user' returned 1: ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: NO)

err: Could not prefetch mysql_user provider 'mysql': Execution of '/usr/bin/mysql -NBe SELECT CONCAT(User, '@',Host) AS User FROM mysql.user' returned 1: ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: NO)

I have tried specifying the root password in the following ways:

class { 'mysql::server':
    old_root_password => 'password',
    root_password => 'password',
    override_options => { root_password => 'password' }
}

Neither seems to work. As of yet, I have not been successful in using this package. The documentation isn't quite clear on this, or I'm just misinterpreting them.

[mysql::db] Error 400 on SERVER: Invalid parameter provider at /etc/puppet/environments/production/modules/mysql/manifests/db.pp:56 while creating databases with mysql::db

Hi,

I am always getting this error on the client:
"
Error 400 on SERVER: Invalid parameter provider at /etc/puppet/environments/production/modules/mysql/manifests/db.pp:56
"
On the puppet master the logs says:

pet-master[25938]: Invalid parameter provider at /etc/puppet/environments/production/modules/mysql/manifests/db.pp:56 on node vps01.example.org
Sep 19 12:12:36 do1 puppet-master[25938]: Invalid parameter provider at /etc/puppet/environments/production/modules/mysql/manifests/db.pp:56 on node vps01.example.org
Sep 19 12:12:36 do1 puppet-master[25938]: Invalid parameter provider at /etc/puppet/environments/production/modules/mysql/manifests/db.pp:56 on node vps01.example.org
Sep 19 12:12:36 do1 puppet-master[25938]: Report processor failed: undefined method `[]' for nil:NilClass

The node is defined like this

node 'vps01.example.org' inherits default {
class { 'mysql': }
class { 'mysql::ruby': }
class { 'mysql::server':
config_hash => { 'root_password' => 'testpw' },
}
mysql::db { 'exampledb':
user => 'example',
password => 'pass',
host => 'localhost',
grant => ['all'],
}
}

If I only use the clasess mysql, mysql::ruby and mysql::server all works ok. So the problem is with the mysql::db class while trying to create a new database

Any Idea what I am doing wrong?

Thanks for your time

Regards

Debian systems should be able to manage the root password

As of commit fb00c75, we no longer worry about setting the root password on debian systems as it is not a required step in setting up a functioning server. Users should still be able to manage the root password through the module, so we need to create 'manifests/server/debian.pp' that sets the password and creates the correct /root/.my.cnf file.

Since mysqladmin can only be used to set the password of the user connecting via mysqladmin ('-u'), the debian-sys-maint user in /etc/mysql/debian.cnf defaults file can probably be used to update the mysql.users table and FLUSH PRIVILEGES from an exec.

the flag `remove_default_accounts` appears to do nothing

If you call the mysql::server class with the remove_default_accounts flag, you are still able to log in anonymously which leads the user to believe it did not work.

class { '::mysql::server':
root_password => 'foo',
remove_default_accounts => true,
restart => true,
}

This spawned two questions:

http://dba.stackexchange.com/questions/51452/how-do-you-disable-anonymous-login-mysql/51455#51455

https://ask.puppetlabs.com/question/3662/disable-mysql-anonymous-accounts/?answer=3664

In actuality, remove_default_accounts does work, but because the password is stored in /root/.my.cnf the user can be led to believe that accounts without passwords still exist.

Solution:
Add a warning to the README.MD outlying this pitfall. Even if anonymous accounts are disabled, the root user will still appear to have password less logins.

manifests/server/monitor.pp uses incorrect resource names: mysql_user and mysql_grant

In manifests/server/monitor.pp we use incorrectly named resources:

mysql_user{
  "${mysql_monitor_username}@${mysql_monitor_hostname}":
    password_hash => mysql_password($mysql_monitor_password),
    ensure        => present,
    require       => Service['mysqld'],
}
mysql_grant { "${mysql_monitor_username}@${mysql_monitor_hostname}":
  privileges    => [ 'process_priv', 'super_priv' ],
  require       => [ Mysql_user["${mysql_monitor_username}@${mysql_monitor_hostname}"], Service['mysqld']],
}

Providers do not correctly handle per-database permissions

If you have a single database_user with multiple database_grants, that user's permissions on all databases is set to the permissions of the last grant declared.

class mysql::test {
    database {
            "foo":;
            "bar":; 
    }

    database_user { 
            "john@localhost":;       
    }

    database_grant {
            "john@localhost/foo":    
                    privileges => ['all'];   
            "john@localhost/bar":    
                    privileges => ['select_priv'];
    }
}

In this configuration, john does not have write access to the foo database, because the permissions have been set to the same as the bar database.

Here are the commands the provider runs in this setup:

debug: Puppet::Type::Database_grant::ProviderMysql: Executing '/usr/bin/mysql mysql -Be update db set select_priv = 'Y', insert_priv = 'Y', update_priv = 'Y', delete_priv = 'Y', create_priv = 'Y', drop_priv = 'Y', grant_priv = 'Y', references_priv = 'Y', index_priv = 'Y', alter_priv = 'Y', create_tmp_table_priv = 'Y', lock_tables_priv = 'Y', create_view_priv = 'Y', show_view_priv = 'Y', create_routine_priv = 'Y', alter_routine_priv = 'Y', execute_priv = 'Y' where user="john" and host="localhost"'
[...]
debug: Puppet::Type::Database_grant::ProviderMysql: Executing '/usr/bin/mysql mysql -Be update db set select_priv = 'Y', insert_priv = 'N', update_priv = 'N', delete_priv = 'N', create_priv = 'N', drop_priv = 'N', grant_priv = 'N', references_priv = 'N', index_priv = 'N', alter_priv = 'N', create_tmp_table_priv = 'N', lock_tables_priv = 'N', create_view_priv = 'N', show_view_priv = 'N', create_routine_priv = 'N', alter_routine_priv = 'N', execute_priv = 'N' where user="john" and host="localhost"'

Note that neither query mentions the db column of the table, so each updates two rows instead of one. The offending code seems to be this chunk in providers/database_grant/mysql.rb (~line 133):

                when :user
                        stmt = 'update user set '
                        where = ' where user="%s" and host="%s"' % [ name[:user], name[:host] ]
                        all_privs = MYSQL_USER_PRIVS
                when :db
                        stmt = 'update db set '
                        where = ' where user="%s" and host="%s"' % [ name[:user], name[:host] ]
                        all_privs = MYSQL_DB_PRIVS
                end

mysql_grant needs to quote username and host

Not a specialist here myself, just using it through the puppet modules in stackforge. But it seems mysql_grant is using user@host instead of 'user'@'host' which can lead to issues with some characters. In my case, that led to this error:

Error: Could not prefetch mysql_grant provider 'mysql': Execution of '/usr/bin/mysql --defaults-file=/root/.my.cnf -NBe SHOW GRANTS FOR [email protected];' returned 1: ERROR 1064 (42000) at line 1: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '-host.example.com' at line 1

Now, Ruby is really far from being my specialty but this rather ugly hack helped:

--- modules/mysql/lib/puppet/provider/mysql_grant/mysql.rb.orig 2013-09-17 14:56:34.593293855 +0200
+++ modules/mysql/lib/puppet/provider/mysql_grant/mysql.rb      2013-09-17 14:45:45.338294573 +0200
@@ -6,6 +6,8 @@
   def self.instances
     instances = []
     users.select{ |user| user =~ /.+@/ }.collect do |user|
+      user = user.split('@')
+      user = "\'#{user[0]}\'@\'#{user[1]}\'"
       query = "SHOW GRANTS FOR #{user};"
       grants = mysql([defaults_file, "-NBe", query].compact)
       # Once we have the list of grants generate entries for each.

Pretty sure someone with Ruby skills can convert that into pretty code. Or maybe it needs to be fixed elsewhere (no idea where the user stuff is actually coming from).

Removed .my.cnf = errors

If for any reason .my.cnf is removed (after it's initially created), the following error comes up on the next run:

err: Could not prefetch mysql_user provider 'mysql': Execution of '/usr/bin/mysql -NBe SELECT CONCAT(User,
'@',Host) AS User FROM mysql.user' returned 1: ERROR 1045 (28000): Access denied for user 'root'@'localhost'
(using password: NO)

err: /Stage[main]/Mysql::Server::Root_password/Mysql_user[root@localhost]/ensure: change from absent to present failed: Execution of '/usr/bin/mysql -e GRANT USAGE ON . TO 'root'@'localhost' IDENTIFIED BY PASSWORD '*0C0391BC20C40E95784D0BB5BB7216D8ADBCC17F' WITH MAX_USER_CONNECTIONS 0 MAX_CONNECTIONS_PER_HOUR 0 MAX_QUERIES_PER_HOUR 0 MAX_UPDATES_PER_HOUR 0' returned 1: ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: NO)

Removing anonymous accounts with account_security.pp

I've got a ::mysql::server class declared which includes "remove_default_accounts => 'true'" thus activating account_security.pp.

This removes most of what I would expect except for the anonymous accounts for ''@'localhost' and ''@'fqdn', although I don't get an error applying the configuration. I've checked inside account_security.pp and it does appear to be attempting to remove these accounts.

I've tested this by removing "remove_default_accounts => 'true'" and adding a dedicated mysql_user for '@localhost' and setting "ensure=>absent" and see the same behaviour - the configuration gets applied without error but the user remains.

inheritance hell - can not include mysql & mysql::server on the same node

mysql::server inherits from mysql which can/will cause duplicate class mysql declaration errors on nodes that include both mysql and mysql::server, depending on the exact parse order of the particular manifest. @apenney promised to fixed this in #puppet and to include a ponie in the module.

--reference 5e47aff57ab17946b624be8e8196726c9639acb0

mysql_grant not working in 2.0.0-rc3

I'm using 2.0.0-rc3 and mysql_grant doesn't seem to be working.

mysql_grant { 'web@%/.':
ensure => present,
options => ['GRANT'],
privileges => ['ALL'],
table => '.',
user => "web@%",
}

Debug: Executing '/usr/bin/mysql --defaults-file=/root/.my.cnf -e GRANT ALL PRIVILEGES ON . TO 'web'@'%' WITH GRANT OPTION'
Notice: /Stage[main]/Xyz_mysql::Xyz_users/Mysql_grant[web@%/.]/ensure: created
Debug: Executing '/usr/bin/mysql --defaults-file=/root/.my.cnf -NBe FLUSH PRIVILEGES'
Debug: /Stage[main]/Xyz_mysql::Xyz_users/Mysql_grant[web@%/.]: The container Class[Xyz_mysql::Xyz_users] will propagate my refresh event

The grant doesn't get applied by puppet. I confirmed that if I enter the mysql command it works as long as I enclose the SQL statement within double quotes.

Root user not granted permissions

Hi I'm on Ubuntu Raring with puppet 2.7 using the mysql module.

I have the following configuration:
include mysql::php
class { 'mysql::server':
config_hash => { 'root_password' => 'password' }
}
mysql::db { 'usvn':
user => 'usvn_user',
password => 'password',
host => 'localhost',
grant => ['all'],
}

I get the error message:
Jun 28 21:13:03 bochy puppet-agent[30456]: (/Stage[main]/Usvn/Mysql::Db[usvn]/Database[usvn]/ensure) change from absent to present failed: Execution of '/usr/bin/mysql --defaults-file=/root/.my.cnf -NBe create database usvn character set utf8' returned 1: ERROR 1044 (42000) at line 1: Access denied for user 'root'@'localhost' to database 'usvn'

When I check the permissions for the root user:
mysql> show grants;
+----------------------------------------------------------------------------------------------------------------------------------------------+
| Grants for root@localhost |
+----------------------------------------------------------------------------------------------------------------------------------------------+
| GRANT SELECT, RELOAD, LOCK TABLES, SHOW VIEW ON . TO 'root'@'localhost' IDENTIFIED BY PASSWORD '*F8077C7DA658A454B2915555C2F08BD1005BC362' |
| GRANT PROXY ON ''@'' TO 'root'@'localhost' WITH GRANT OPTION |
+----------------------------------------------------------------------------------------------------------------------------------------------+
2 rows in set (0.01 sec)

Can someone please tell my why my root user isn't granted all privileges

Release tags

Hi,

Please add missing tag for latest 0.9.0 release.

Thanks!

"max_allowed_packets" parameter for mysqldump is unkown

The correct name of the parameter is "max_allowed_packet" (without a "s" at the end).

vagrant@vagrant:~$ mysqldump --version
mysqldump: unknown variable 'max_allowed_packets=16M'

After removing the "s" in my.cnf, everything works fine

vagrant@vagrant:~$ mysqldump --version
mysqldump Ver 10.13 Distrib 5.5.32, for debian-linux-gnu (x86_64)

override_options overriding defaults?

Is it the intention that when you use override_options, the default options in my.cnf are stripped out? I've observed that when I use the example below, the defaults specified in params.pp are removed.

    class { 'mysql::server':
            override_options => { 'mysqld' => { 'max_connections' => '1024',
                                                'datadir' => '/var/lib/mysql/data' }
                    },
            }

Unknown function validate_re

When attempting to create a database via:

mysql::db {'mydb':
user => 'dbuser',
password => 'dbpass',
host => 'localhost',
}

I get the following error:

Error: Unknown function validate_re at /tmp/vagrant-puppet/modules-0/mysql/manifests/db.pp:47 on node testdb

Any help?

Latest module from forge version 0.9.0 and and puppet 3.2.4

mysql::db is failing w/ puppet 2.7.22 (was 2.6.18) and stdlib 2.6.0

This is a follow-on to my previous issue here:

#239

I upgraded the master and client to 2.7.22 and I'm still seeing no output with regards to generating the databases or users. My config hasn't changed from the previous ticket.

and here's the output after re-provisioning the client machine, upgrading the client to 2.7.22 and re-enabling the mysql stuff:

https://gist.github.com/scumola/6235609/raw/2c647b9210c1283412c09550039ef50a2f03f8f2/puppet.log

See the previous ticket for a full history.

Invalid resource type

I get the following error in any case I try to use this module:

Puppet::Parser::AST::Resource failed with error ArgumentError: Invalid resource type anchor at /tmp/vagrant-puppet/modules-0/mysql/manifests/server.pp:54

config_hash parameter is hiera unfriendly

The config hash parameter in mysql::server is not so friendly to hiera. Because the auto-parameter lookup will only perform a hiera() call, not a hiera_hash() call, one can't leverage defining parts of the hash at multiple levels of a hierarchy, leading to possible duplication of data.

fails to install on rhel5

on rhel5, the module fails with the following error message:

err: /Stage[main]/Mysql::Config/File[/etc/mysql/my.cnf]/ensure: change from absent to file failed: Could not set 'file on ensure: No such file or directory - /etc/mysql/my.cnf.puppettmp_238 at /etc/puppet/modules/mysql/manifests/config.pp:46

it looks like this is assuming a debian specific directory

mysql_user password?

Dumb question, but how or where do I specify password for the users under mysql_user ?

mysql::server::backup requires Service['mysqld']

On a fresh install (no mysql server existing) it is necessary to specify:

Service['mysqld'] -> Class['mysql::server::backup']
class { 'mysql::server:backup': ... }

Otherwise failures occur trying to ensure the Mysql_user and Mysql_grant that the class requires. Failures due to the server not running yet.

Should the above dependency need to be explicitly defined or can the dependency be managed within the class itself?

Error about Hiera Terminus, missing dependency on ruby-hiera?

On my relatively fresh Ubuntu 13.10 Server, I get errors trying to set up a MySQL database using this module's version 2.0.1. I can reproduce it with this one-liner:

include '::mysql::server'

Output:

Error: Hiera terminus not supported without hiera library at /home/lastorset/puppet/puppetlabs-mysql.hiera-test.pp:1 on node localhost.members.linode.com
Wrapped exception:
Hiera terminus not supported without hiera library
Error: Hiera terminus not supported without hiera library at /home/lastorset/puppet/puppetlabs-mysql.hiera-test.pp:1 on node localhost.members.linode.com

It went away when I installed the ruby-hiera package, although I still got

Warning: Config file /etc/puppet/hiera.yaml not found, using Hiera defaults

I'm not too familiar with Puppet modules yet, but is there a missing dependency here? I see "hiera" in Gemfile.lock, so it looks like somebody at least meant to declare it.

Service name on Ubuntu 10.04 LTS 2

Thanks for this module!

I'm trying to use it on Ubuntu 10.04 LTS 2.

If I declare

class { 'mysql::server': 
    root_password => 'foo'
}

I get

err: /Stage[main]/Mysql::Server/Service[mysqld]/enable: change from false to true failed: Execution of '/usr/sbin/update-rc.d mysqld defaults' returned 1: update-rc.d: /etc/init.d/mysqld: file does not exist
notice: /Stage[main]/Mysql::Server/Exec[set_mysql_rootpw]: Dependency Service[mysqld] has failures: true
warning: /Stage[main]/Mysql::Server/Exec[set_mysql_rootpw]: Skipping because of failed dependencies
notice: /Stage[main]/Mysql::Server/File[/root/.my.cnf]: Dependency Service[mysqld] has failures: true
warning: /Stage[main]/Mysql::Server/File[/root/.my.cnf]: Skipping because of failed dependencies
notice: /Stage[main]/Mysql::Server/Exec[mysqld-restart]: Dependency Service[mysqld] has failures: true
warning: /Stage[main]/Mysql::Server/Exec[mysqld-restart]: Skipping because of failed dependencies

On Ubuntu the restart script is /etc/init.d/mysql rather than /etc/init.d/mysqld. I have tried aliasing but no luck.

I'm loathed to hack your lovely module just for Ubuntu!

mysql_secure_installation

Via email:

It would be really nice if this module would have the functionality of the /usr/bin/mysql_secure_installation (Debian+Ubuntu I think) integrated. This basically secures a MySQL server on Debian and Ubuntu.

Help!

I feel like a nincompoop. I have

class { 'mysql::server':
}
class { 'mysql::globals':
override_options => { 'mysqld' => { 'max_connections' => '1024' } }
}

On my node for purely academic purposes to test the module, but it keeps coming up with the following error:

err: Could not retrieve catalog from remote server: Error 400 on SERVER: Duplicate declaration: Class[Mysql::Globals] is already declared; cannot redeclare at node.pp:208 on node build0.local
warning: Not using cache on failed catalog
err: Could not retrieve catalog; skipping run

Have I missed something entirely obvious?

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.