Thanks Neil,

I am not sure I understand exactly what you mean, so I will post the code I 
have done for testing (I am using different paths, but the concept is the 
same as the original post). 

Here is the class with the define.  It is in a module called copy_directory.

class copy_directory {
}

define managed_preferences ($source = undef) {
  file {"/tmp/":
    source  => "puppet:///modules/${source}/tmp",
    recurse => true,
    owner   => "root",
    group   => "root",
    mode    => 600,
  }
}

Here is the module that calls it.  

include copy_directory

class test_module {
  managed_preferences { 'title':
  source => "$module_name",
  }
}

I also created a module called test_module2 with the same code.  I know 
that file {"/tmp/": is causing the problem, but the entire point is 
different modules copy files into that directory. To me I'm defining it 
once, and using it twice.  As I defined it in the copy_directory module, 
and I am using it in the test_module and test_module2.   What am I doing 
wrong?

On Saturday, September 20, 2014 12:11:28 PM UTC-5, Neil wrote:
>
> Hi
>
> You should not define it twice. You use it twice.
>
> As in your example the apache uses the firewall define. It does not define 
> the file resource again.
>
> Define managed_preference in a class that you'll use as a library and use 
> that in the modules that need it.
>
> Note the resources using the define 
> each have their own name
>
> Neil
> On 20 Sep 2014 17:46, <aar...@gmail.com <javascript:>> wrote:
>
>> I figured out how to create a define type and again it works for the 
>> first module, but when I add a second I get the exact same error which is 
>> what I expected based on the link below.
>>
>> So, does anyone know how to accomplish this?  
>>
>> On Friday, September 19, 2014 6:59:19 PM UTC-5, aar...@gmail.com wrote:
>>>
>>> It appears I'm looking for a defined type to do this.   
>>> https://docs.puppetlabs.com/learning/definedtypes.html#
>>> special-little-flowers
>>>
>>> I'll see if I can get this to work for my purpose though this article 
>>> mentions duplicate definitions and I'm guessing I'll have the same problem. 
>>>  
>>>
>>> On Friday, September 19, 2014 5:34:08 PM UTC-5, aar...@gmail.com wrote:
>>>>
>>>> Glad the concept is correct, but I've been playing with it and am not 
>>>> sure which part of the firewall class processes the passed on code. In the 
>>>> firewall/apache analogy, you use the following code.
>>>>
>>>> class apache {
>>>>   firewall { '100 allow http and https access':
>>>>     port   => [80, 443],
>>>>     proto  => tcp,
>>>>     action => accept,
>>>> }
>>>>
>>>> What I am not seeing is what part of the firewall class receives this 
>>>> information and knows what to do with those parameters.  If I understood 
>>>> this, I could probably figure out my example.  
>>>>
>>>> I tried in my situation
>>>>
>>>> managed_preferences { 
>>>>        source  => "puppet:///modules/office_2011/Preferences",
>>>>        require => Package["$main_package"],
>>>>      }
>>>>
>>>> thinking that it would send these two parameters to the newly create 
>>>> managed_preferences class.  Again, I don't know how to receive the 
>>>> information to process it in the managed_preferences class.   Is the 
>>>> managed_preferences class a different type of class than the office_2011 
>>>> class?  If I knew the official terminology I could look it up and probably 
>>>> figure this out.  
>>>>
>>>> Thanks again
>>>>
>>>> On Friday, September 19, 2014 5:06:15 PM UTC-5, Ygor wrote:
>>>>>
>>>>> Use the same approach the firewall module uses:  A main class, 
>>>>> declared at a global level, creates/manages the folder. A defined type is 
>>>>> used to create/manage imdividual prefs files and is involed inside the 
>>>>> module for the individual app.
>>>>>
>>>>> A basic pronciple of object-oriented code. Pull out the common bits 
>>>>> and manage them in one place - in this case: the common folder. 
>>>>>
>>>>> "Sometimes I think the surest sign that intelligent life exists 
>>>>> elsewhere in the universe is that none of it has tried to contact us."
>>>>>
>>>>> Bill Waterson (Calvin & Hobbes)
>>>>>
>>>>> On Sep 19, 2014, at 5:09 PM, aar...@gmail.com wrote:
>>>>>
>>>>> I have a single class for every application to be installed on our 
>>>>> Macintosh clients.  The problem I am having is in the section of the 
>>>>> class 
>>>>> below.  This copies files to the User Template folder so when users login 
>>>>> they get predefined preferences.  
>>>>>
>>>>> file { "System/Library/User Template/English.lproj/
>>>>> Library/Preferences/":
>>>>>     source  => "puppet:///modules/office_2011/Preferences",
>>>>>     owner   => "root",
>>>>>     group   => "wheel",
>>>>>     mode    => 600,
>>>>>     recurse => true,
>>>>>     require => Package["$main_package"],
>>>>>     }
>>>>>
>>>>> This would work perfect if I had only one application in which I 
>>>>> wanted managed preferences.  I am getting an error that the User Template 
>>>>> folder is being managed by another class.  I understand why.  I also 
>>>>> understand the purpose.  This code however only copies files into the 
>>>>> Template Folder, it doesn't overwrite, or purge the folder.  So, in 
>>>>> theory, 
>>>>> what I want to do should be a valid approach to managing preferences.  
>>>>>
>>>>> I have an idea, but don't know how to execute it.  So I hope someone 
>>>>> can help.
>>>>>
>>>>> In the Puppetlabs/Firewall module, you can access it from another 
>>>>> module.  So if I have an apache module, I can tell the Firewall module I 
>>>>> want to open port 80.
>>>>>
>>>>> I would like to make a Macintosh Managed Preferences module that will 
>>>>> manage the User Template folder, and in each application module, I can 
>>>>> provide that module with files.  
>>>>>
>>>>> How can I accomplish this?
>>>>>
>>>>> Thanks in advance.  
>>>>>
>>>>>
>>>>>  -- 
>>>>> You received this message because you are subscribed to the Google 
>>>>> Groups "Puppet Users" group.
>>>>> To unsubscribe from this group and stop receiving emails from it, send 
>>>>> an email to puppet-users...@googlegroups.com.
>>>>> To view this discussion on the web visit https://groups.google.com/d/
>>>>> msgid/puppet-users/7fe782a1-fba4-4cef-aeab-4cf85ed170d2%
>>>>> 40googlegroups.com 
>>>>> <https://groups.google.com/d/msgid/puppet-users/7fe782a1-fba4-4cef-aeab-4cf85ed170d2%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>>> .
>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>
>>>>>  -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Puppet Users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to puppet-users...@googlegroups.com <javascript:>.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/puppet-users/f0f84a30-7fd5-4cef-a74e-6735b6f70734%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/puppet-users/f0f84a30-7fd5-4cef-a74e-6735b6f70734%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/fe3ecd75-0940-483a-aff5-210db9246d20%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to