Thoughts on MySQL module and grants as collections...

40 views
Skip to first unread message

Sean Alderman

unread,
Nov 12, 2013, 10:38:02 AM11/12/13
to example42-pu...@googlegroups.com
Hi,

I'm working to setup a module for a university department that encompasses the entire website they want to publish.  They're using a bunch of various php tool which I haven't got much control over, but I am using puppet with Ex42's Apache, PHP, MySQL, NFS, and other modules to make this happen.  I'm also using environments to differentiate between development, test and production.  Each environment's site has it's own DNS name, load balancer (outside of my control), a MySQL server, and X number of Apache/PHP servers.

So, one of the tricks I'm using is $::environment such that the DocRoot is an nfs mount based on $::environment.  I'm wondering I wouldn't also be able to do something similar with MySQL Grants.  Granted, I'm not sure my puppet-fu is strong enough to use stored-config, but I was hoping to use the Nagios module as a guide. 

I was thinking that each webserver provisioned for an environment would export a resource for the MySQL grants it needs, then the database server in the same environment could collect those resources and define them using Ex42's mysql::grant?  In reading the Puppet docs, it would seem that setting up a tag by environment would prevent grants from bleeding across environments.

Does that sound possible?  Sorry if this is off topic a bit.

Alessandro Franceschi

unread,
Nov 12, 2013, 12:08:46 PM11/12/13
to example42-pu...@googlegroups.com
Yes, it's possible and can be done exactly in the way you expressed.
You have to export the Mysql::Grant resource and collect them according to custom tags.
An example (to be honest never tested by me) is here:

On the mysql server or that case, you'd have to collect with:
  Mysql::Grant <<| tag =="mysql_grants_${::fqdn}" | >>
and
  Mysql::Grant <<| tag =="mysql_grants_${::ipaddress}" | >>

In your case it could be something like   Mysql::Grant <<| tag == $environment | >>

Sean Alderman

unread,
Nov 12, 2013, 2:03:51 PM11/12/13
to example42-pu...@googlegroups.com
Cool, I'll let you know how it goes.  While I was poking around, before I saw your reply, I saw a similar example in using iptables::rule at the bottom of the puppet-iptables readme.

Is it possible to set an exported iptables rule resource in the webserver manifest, that's collected on the database's manifest too?

Alessandro Franceschi

unread,
Nov 12, 2013, 2:21:49 PM11/12/13
to example42-pu...@googlegroups.com
Yes, somehow a bit creepy but yes.
Same logic applies: facts are evaluated  on the exporting nodes: you export the iptables::rule with the $::ipaddress (and the proper tags) and source and that can be collected where you need them.

Sean Alderman

unread,
Nov 13, 2013, 5:07:17 PM11/13/13
to example42-pu...@googlegroups.com
Firewall Resources are looking good...

Mysql::Grant's not so much...Is it possible that your mysql::grant define needs something to support exported resources?  I'm just reaching, but the firewall resources are working swell, I just can't seem to figure out why this is different.

Database Server Run produces:

err: Could not retrieve catalog from remote server: Could not intern from pson: Could not convert from pson: Could not find relationship target "Mysql::Grant[]"

The server side manifest looks like:

  ###   Webservers in current environment
  Mysql::Grant <<| tag == $module::grant_tag |>> { }

The client side manifest looks like:

  # Database MySQL Grant
  @@mysql::grant { "${::fqdn}-dbgrant":
    mysql_db         => $module::db_name,
    mysql_user       => $module::db_user,
    mysql_password   => $module::db_passwd,
    mysql_privileges => 'ALL',
    mysql_host       => $::fqdn,
    tag              => $module::grant_tag,
  }

If the define isn't the issue, I'll take this thread over to the puppet list, and get out of everyone's hair over here.  Thanks for the help!

Sean Alderman

unread,
Nov 13, 2013, 5:17:37 PM11/13/13
to example42-pu...@googlegroups.com
Sorry, I think I might have just found it...

Looks like an empty variable due to a typo in my params_lookup function.
Reply all
Reply to author
Forward
0 new messages