When we are working with tables_priv we need to first get a downcased array of the currently set privileges, and a downcased array of the desired permissions.
Then we make a list of the permissions to revoke by subtracting the requested permissions from the currently set ones.
If the list of permissions to revoke is not empty, then we issue a REVOKE.
Then we make a list of the permissions to add by subtracting the requested permissions from the current set (no need to add select again if it is already there).
Then if the set of permissions to add is not empty, then we actually execute the statement.
To handle this, this comment removes the create_row for table_privs, it also selects the actual value of the Table_priv so its value can be used instead of the method that is used for Y/N value settings
The current procedure of setting the root MySQL password leaks the root
password by giving it to the setmysqlpass.sh script on the command line.
This means that during the couple of seconds that the script is
executing, the password is visible in the process list!
Since we're already writing the password in the /root/.my.cnf file, make
the setmysqlpass.sh script parse this file to retrieve the password
instead of receiving it from a command line argument.
Also, in some shells the 'echo' command might appear in the process
list. Use a heredoc notation to create the output without using a
command.
Signed-off-by: Gabriel Filion <lelutin@gmail.com>
The current procedure of setting the root MySQL password leaks the root
password by giving it to the setmysqlpass.sh script on the command line.
This means that during the couple of seconds that the script is
executing, the password is visible in the process list!
Since we're already writing the password in the /root/.my.cnf file, make
the setmysqlpass.sh script parse this file to retrieve the password
instead of receiving it from a command line argument.
Also, in some shells the 'echo' command might appear in the process
list. Use a heredoc notation to create the output without using a
command.
Signed-off-by: Gabriel Filion <lelutin@gmail.com>
Parameter unless failed: 'mysqladmin -uroot status > /dev/null' is both unqualifed and specified no search path at /etc/puppet/modules/mysql/manifests/server/base.pp:62
unless you have set globally:
Exec { path => "/usr/bin:/usr/sbin/:/bin:/sbin:/usr/local/bin:/usr/local/sbin" }
. change the default nagios::service::mysql check to use the check_mysql_health 'connection-time' check mode, which is identical to the original check, with some additional information
. stop using nagios::plugin::deploy because this doesn't work when more than one node attempts to realize this class
. stop exporting the nagios_command because this doesn't work when more than one node attempts to realize this class
. remove the check_health define, instead this be how it was before, as the previous nagios::service::mysql define
1. use the new plugin deploy feature in nagios (nagios::plugin::deploy)
2. remove unnecessary classes and inheritance - this plugin seems reasonable to install by default, and in fact it could be argued that the other 'check_mysql' plugin that still remains can be removed, as its functionality is vastly overshadowed by this one
3. add the 'repl_client_priv' mysql grant privs to the nagios user. these are needed for the check_mysql_health plugin slave replication modes. According to http://dev.mysql.com/doc/refman/5.0/en/privileges-provided.html#priv_replication-client - The REPLICATION CLIENT privilege enables the use of SHOW MASTER STATUS and SHOW SLAVE STATUS. These privileges are not too much to provide to the nagios user, as they are only informational
4. setup the define "check_health" so it can be used easily
* create a mysql::server::nagios::base class with the common parts needed for the basic plugin, and the health plugin
* make mysql::server:nagios inherit mysql::server:nagios::base
* create a new class mysql::server::nagios::check_health inheriting ::base
the nagios module has also received a new define to setup the different nagios::service pieces for the different health check modes that might be desired
its assumed you would setup the different health check modes in site-mysql/init.pp as different hosts will require different modes and/or parameters, for example:
class site-mysql::server {
include mysql::server::nagios::check_health
nagios::service::mysql_health { [ 'connection-time', 'uptime', 'threads-connected', 'threadcache-hitrate' ]:
require => Mysql_grant[$nagios_mysql_user],
}
case $hostname {
"eider": {
nagios::service::mysql_health { [ 'slave-io-running', 'slave-sql-running', 'slave-lag' ]:
require => Mysql_grant[$nagios_mysql_user],
}
}
}
}
