As I'm in over my head, let's supply you with (part of) the manifests in
question:
The define:
define sugar::definitions_sug_wp (
$template = 'sugar/etc/httpd/conf.d/sugar6x.conf.erb',
$client_domain = "$title",
$mysql_rootpwd = "$mysql_password",
$mysql_dbname,
$mysql_pwd,
$sugar_admin,
$sugar_pwd,
) {
# This is for example to create the httpd.conf and the sugar-folder. So
this has to be in both. As you can see, I parametrized the httpd-conf, so I
can specify it in my class. Also, the ${client_domain}-variable is used
throughout this define.
file {
"/etc/httpd/conf.d/sug-${client_domain}.conf":
content => template($template),
owner => 'root',
group => 'root',
mode => '0644',
notify => Service['httpd'];
"/var/log/sugar/${client_domain}":
ensure => 'directory';
}
# The following is specific to the WordPress-installation and doesn't need
to be applied to every machine. So this part isn't in the define 'define
sugar::definitions_sug'.
file {
# Configuratie van publieke html
"/var/www/html/${client_domain}":
owner => 'apache',
group => 'apache',
mode => '0744',
ensure => 'directory';
# Configuratiefile WordPress
"/var/www/html/${client_domain}/wp-config.php":
owner => 'apache',
group => 'apache',
mode => '0744',
require => File["/var/www/html/${client_domain}"],
content => template('sugar/wordpress/wp-config.php.erb');
I call both defines ('sugar::definitions_sug_wp' and 'define
sugar::definitions_sug') in the following class:
class sugar::instances {
sugar::definitions_sug {
# SugarCRM - ECM2
'node1':
mysql_dbname => 'dbname1',
mysql_pwd => 'password1';
sugar::definitions_sug_wp {
'node2':
sugar_admin => 'text1',
sugar_pwd => 'password2',
mysql_dbname => 'dbname2',
mysql_pwd => 'password3';
I include this class on one node to get several sugar-only vhosts and
several sugar+wordpress-nodes on that node.
Hope this helps you explain things to me!
On Monday, November 5, 2012 3:41:37 PM UTC+1, jcbollinger wrote:
>
>
>
> On Monday, November 5, 2012 3:48:58 AM UTC-6, Erwin Bogaard wrote:
>>
>> Thanks again for you reply, but it seems like you don't fully understand
>> what I'm having problems with. So I'll try to clarify it a little more:
>> 1. The current way of using two defines is working flawlessly. So I (at
>> least partly) understand the concepts surrounding those.
>> 2. Because I have two types of machines: some with just sugar and some
>> with sugar and wordpress, I now use two defines that overlap in part
>> (define1 contains all kinds of info about creating sugar db + unpacking
>> tar, etc, while define2 contains all the sugar info of define1 + stuff
>> about creating a wordpress db + unpacking wp tar, etc), this means editing
>> two files when I change something in the sugar define. As this can lead to
>> differing configurations because of editing errors (and always twice the
>> work), I would like to be able to split the defines up, so I can call
>> define1 (sugar) on all machines and define1 (sugar) and sefine 2
>> (wordpress) on the other machines.
>> 3. Some of the variables are shared, for example the mysqld_pwd is used
>> twice, and I add a different suffix for sugar and wordpress to get two
>> databases. For the httpd-configuration, I specify a different template,
>> which is easy to to with defines. So all instances have unique resources,
>> hence the choice for defines, not classes.
>>
>> Does this help you help me?
>>
>
>
> No, not really. You have been relatively clear about what you are trying
> to accomplish, but I don't understand what is preventing you from
> accomplishing it. Perhaps that means you're stumbling over something that
> seems trivial to me. For example, if the real question is how to share
> data between two or more defined types, then you have at least three
> choices:
>
> 1. Define the data in a class, and have each definition reference the
> class variables instead of taking that data in the form of parameters.
> 2. Externalize the data (e.g. into an Hiera data store), and have each
> definition reference the needed values by the same fixed key.
> 3. Record the data in global variables, and have each definition
> reference the global values. (I wouldn't recommend this one except as a
> temporary hack.)
>
> If that doesn't help then perhaps you should try reducing the problem to
> the simplest possible example that captures the issue. Often such an
> exercise will itself help you work out the problem, but if it doesn't then
> we can be a lot more helpful to you with actual (simple) manifests to
> critique.
>
>
> John
>
>
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/OtbcKBd0GgIJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
