Change mysql_grant provider to ignore/delete double-quotes -- as it does with single quotes and backticks -- in the returned list of existing grants. With ANSI_QUOTES enabled in MySQL's sql_mode, grant identifiers (e.g. database name) are quoted with double-quotes rather than backticks, for example "foo".* vs. `foo`.*. This breaks mysql_grant's evaluation of existing grants and causes it to apply grants with every run.
If a user exists in the database upon first Puppet run (for example, in the case of loading a database snapshot) and the run sets that user's :ensure attribute to 'absent', the mysql_grant provider will throw an error when the dependency chain causes it to try to destroy the grants associated with that user because the DROP statement from the mysql_user provider already removed the grants. To fix, we must check if the user exists before revoking the grants.
- Added MySQL version and flavour detection support
- Added mysql_datadir provider/type (replaces Exec[mysql_install_db])
- Added version specific parameters my.cnf ([mysqld-5.X] sections)
- Version specific user mangement SQL (ALTER USER for 5.7.6++ ...)
Rebased-By: David Schmitt <david.schmitt@puppetlabs.com>
The password column has been renamed to authentication_string in MySQL >=5.7.6.
By using: SELECT /*!50706 AUTHENTICATION_STRING AS */ PASSWORD the query will
continue to work in older versions as well as newer ones.
We want to make sure we are validating the entire user parameter (and
validating it consistently between mysql_user and mysql_grant).
Additionally, for munging we do not want to do anything that could
truncate the username.
instead of making mysql::db have a hard dependency on mysql::server, we
now have a (soft) dependency on it through the types (mysql_user, and
mysql_database) that mysql::db uses. (n.b.: mysql_grant depends on
mysql_user so it doesn't need an explicit dependency on mysql::server)
Starting MariaDB 10.0.0, usernames are now 80 long.
Our mysql_user and mysql_grant types now take that into consideration.
This check is *opportunistic*. It will only take place if the
mysql_version fact is available. If that is not the case, it will be
skipped, leaving the database itself to deal with it, and returning its
error verbatim to our users, if it does fail.
Our fixed and extended tests assume this isn't the first run, and the
fact is already in place.
https://tickets.puppetlabs.com/browse/MODULES-1676
This is identical to what PASSWORD('') in MySQL does:
5.6.22-debug-log> CREATE USER 'testpwd'@'localhost' IDENTIFIED BY 'foo';
Query OK, 0 rows affected (0.03 sec)
5.6.22-debug-log> SELECT User,Host,Password FROM mysql.user WHERE
User='testpwd';
+---------+-----------+-------------------------------------------+
| User | Host | Password |
+---------+-----------+-------------------------------------------+
| testpwd | localhost | *F3A2A51A9B0F2BE2468926B4132313728C250DBF |
+---------+-----------+-------------------------------------------+
1 row in set (0.01 sec)
5.6.22-debug-log> SET PASSWORD FOR 'testpwd'@'localhost' = PASSWORD('');
Query OK, 0 rows affected (0.00 sec)
5.6.22-debug-log> SELECT User,Host,Password FROM mysql.user WHERE
User='testpwd';
+---------+-----------+----------+
| User | Host | Password |
+---------+-----------+----------+
| testpwd | localhost | |
+---------+-----------+----------+
1 row in set (0.00 sec)
This uses CREATE USER xxx IDENTIFIED WITH yyy
For tests:
unix_socket is not loaded by default, so this might require:
install plugin unix_socket soname 'auth_socket.so';
The mysql_native_password plugin is available by default and
allows you to also set a password.
Try to make it compatible with MySQL < 5.5.7 it uses version
specific code with "/*!50508 stmt */"
This uses CREATE USER xxx IDENTIFIED WITH yyy
For tests:
unix_socket is not loaded by default, so this might require:
install plugin unix_socket soname 'auth_socket.so';
The mysql_native_password plugin is available by default and
allows you to also set a password.
As usernames containing special characters must be quoted, they
may have two extra characters that are not counted against the
size limit of 16 characters. This patch adds a regex to handle
this case.
Commit cdd7132ff9 added logic to catch invalid database usernames,
but the regex it uses fails to match usernames with special characters that are properly quoted,
causing errors with usernames that used to work in versions < 3.0.0. This fixes the regex so that
if the username is quoted, anything is allowed between the quotes.
From the docs (http://dev.mysql.com/doc/refman/5.5/en/identifiers.html):
"Permitted characters in quoted identifiers include the full Unicode Basic Multilingual Plane (BMP),
except U+0000"
As per http://dev.mysql.com/doc/refman/5.5/en/identifiers.html , MySQL
allows for more than '\w-'. This commit improves the check to ensure
that:
- if username only contains [0-9a-zA-Z$_], it might be quoted. It is
not a requirement though
- if username contains anything else, it MUST be quoted
I kept 2 checks, but the 2nd one can probably be removed (I can't find a
username which match the 2nd one but not the first.)
* Mysql uses the underscore character to represent a single character
wildcard.
* A grant on table `the_database`.* would match `theAdatabase`.*, so
underscores must be escaped to avoid this match.
* The output from mysql escapes special characters (\n, \t, \0, and \\),
but the input does not need to be escaped.
* In order for the provider to compare the tables, the output of
mysql -NBe <query> must have \\ substituted with \.
Old regex is : /^GRANT\s(.+)\sON\s(.+)\sTO\s(.*)@(.*?)(\s.*)$/ . The
last part (\s.*)$ means "a space followed by anything". The issue is
that when user has no GRANT privileges, the "SHOW GRANTS FOR #{user_string}" returns
"GRANT SELECT ON `database`.* TO 'user'@'%'" which does not match (\s.*)$ .
This small patch fixes this making last bloc optional (thanks to '?').
mysql_grant has an autorequire()'d dependency on the .my.cnf file used
by the provider to talk to the database.
I've added this to mysql_database and mysql_user too since logically
these also need the file to be in place.
I've hit this bug because of a slightly unusual edge case in our own
manifests, but I think this fix belongs upstream regardless.
On MySQL v5.5.38, creating a database such as:
CREATE DATABASE `mydb` CHARACTER SET binary COLLATE binary;
seems to hit a parser bug. A workaround is simply to quote COLLATE
`binary`. As the quoting is harmless, and for aesthetics, quote both
the CHARACTER SET and COLLATE arguments.
Check for database existence when dropping to prevent
ERROR 1008 (HY000): Can't drop database 'test'; database doesn't exist
Signed-off-by: Ray Lehtiniemi <rayl@mail.com>
If database grant has backslash in database name (for example: example\_dev), then puppet will try to apply same resource every run because MySQL reports that table name with double backslash (for example: example\\_dev). By global replace of double backslash with single one, this issue is fixed.
In the grant provider users are fetched by querying mysql.user table. Grants
for those users are fetched using show grants for... syntax. This can lead to
errors, when some of the users in mysql.user table do not have currently
active grants.
This happens at least when MySQL is started with --skip-name-resolve option,
when there are users with the hostname part specified as a FQDN. Such users are
created by mysql_install_db. This leads to problems if mysql::account_security
is included for the node and skip-name-resolve is specified in override_options
hash for mysql::server.
Includes acceptance test for the change.
This addresses https://tickets.puppetlabs.com/browse/MODULES-1040.
The user parameter is required to have the form username@host. A grant
is identified in the instances method by a name of the form
username@host/table. The resource will fail to be identified as already
existing if the name given to the resource does not match this form.
MySQL/MariaDB automatically downcase hostnames:
MariaDB [mysql]> create user 'testuser'@'HOSTNAME';
MariaDB [mysql]> select user,host from user where host = 'hostname';
+----------+----------+
| user | host |
+----------+----------+
| testuser | hostname |
+----------+----------+
This causes problems when a mysql_user or datbase_user has an hostname
with non-lowercase characters:
database_user { "root@HOSTNAME":
ensure => absent,
}
The SELECT statements used to determine if the user exists will fail
because the comparisons use "HOSTNAME" but the database has "hostname".
This patch forces the hostname part of "user@hostname" to lower case in
the custom type definitions.
A prior commit accidently broke this, meaning that mysql_database
was querying the mysql defaults instead of each individual database
when trying to determine the current collate settings.
