I thought I had it, but I don't. I will post my code and explain what I
think it is doing. Perhaps someone can see my misunderstanding.
This is init.pp in a module called managed_preferences.
class managed_preferences {
}
define mac_managed_preferences ($application) { #application variable is
the name of the application from the module which installs the application
include managed_preferences
file { "/System/Library/User
Template/English.lproj/Library/Preferences/${source}" : # the source is
the file from the line directly below, this seems true as the correct files
copy when I have only one application
source => "puppet:///modules/${application}/Preferences/",
#application from the module with the install command, finds the files I
want to copy to the client in the /Preferences folder. In this example
office_2011
owner => "root",
group => "wheel",
mode => "600",
recurse => "true",
}
This is code from init.pp from a module called office_2011 which installs
the application.
mac_managed_preferences { "$module_name":
application => $module_name, # resolves to the folder or class
name of the application, allows path to be resolved for the Preferences
folder on the server to be located.
}
When I have both applications assigned to the client, I get the duplicate
declaration. When only one is assigned, it works as expected.
The duplication error is as follows: Duplicate declaration:
File[/System/Library/User Template/English.lproj/Library/Preferences/]
Having variables in the source and destination is what I though I needed.
I feel that the declaration is duplicate because I am declaring file
..../Preferences/$(source) which is different for each module that
communicates with this one.
I know it has been explained, and I just don't understand. How is
mac_managed_preferences declared twice?
Sorry and thanks.
On Tuesday, September 23, 2014 10:23:36 AM UTC-5, [email protected] wrote:
>
> John,
>
> I would like to re-explain the problem I am trying to solve to make sure
> that what I want to do is possible, and that it can be done in the way you
> are trying to help me.
>
> In my first post, I mentioned wanting different modules to write to the
> /System/Library/User
> Template/English.lproj/Library/Preferences/ folder. Which I will now
> just call preferences.
>
> I have two modules I am working on, one installs Office 2011, and one
> installs Maya 2012. Office has three files that I want to put in the
> preferences folder, and Maya has one.
>
> So the tree on each client would be:
>
> /preferences/com.microsoft.*
> /preferences/com.autodesk.*
>
> As you can see, the files are in the root of the preferences folder, not
> subfolders of it.
>
> It is possible other modules (applications I install) may have individual
> files in the root of preferences and a subfolder, or just a subfolder with
> preferences inside.
>
> I envision on my master I would have the preferences that I need copied to
> the preferences of the client to be in the
> modules/office_2012/files/preferences folder.
>
> I hope this clears the problem up and I have an idea for another solution
> if the above approach won't work.
>
> Is it possible for puppet to read the files in the preferences folder on
> the master in a loop and the file name be a variable so that the file type
> (/Preferences/${variable}) would be the correct destination?
>
>
>
> On Tuesday, September 23, 2014 8:49:10 AM UTC-5, jcbollinger wrote:
>>
>>
>>
>> On Monday, September 22, 2014 4:51:38 PM UTC-5, [email protected] wrote:
>>>
>>> I did the following to see if it would work, and I got (for me anyway) a
>>> surprising result. It may be the source of some of my confusion and reason
>>> why I'm finding this so difficult. Note, I don't want to do this this way.
>>> I just did it as an experiment.
>>>
>>> define mac_managed_preferences ($source) {
>>> include managed_preferences
>>>
>>> file { "/System/Library/User
>>> Template/English.lproj/Library/Preferences/${source}" :
>>> source => "puppet:///modules/${source}/Preferences/",
>>> owner => "root",
>>> group => "wheel",
>>> mode => "600",
>>> recurse => "true",
>>> }
>>>
>>> exec { "Move Preferences":
>>> command => "mv $source/* ../Preferences/",
>>> path => "/bin",
>>> cwd => "/System/Library/User
>>> Template/English.lproj/Library/Preferences/",
>>> require => File["/System/Library/User
>>> Template/English.lproj/Library/Preferences/${source}"],
>>> }
>>>
>>> exec { "Delete Folder":
>>> command => "rm -rf $source",
>>> path => "/bin/",
>>> cwd => "/System/Library/User
>>> Template/English.lproj/Library/Preferences/",
>>> require => Exec["Move Preferences"],
>>>
>>> }
>>> }
>>>
>>> Here is the relevant portion of the module that installs the application.
>>>
>>> mac_managed_preferences { "$module_name":
>>> source => "$module_name",
>>> }
>>>
>>>
>>> I got an error: Duplicate declaration [Move Preferences] is already
>>> declared in file (path to managed_preferences file) cannot redeclare at
>>> (path to same file). In my previous posts I said that I though that I
>>> accessed the module multiple times, but declared it once, but this message
>>> is making me understand that puppet says I was declaring it multiple times,
>>> but I am unsure how.
>>>
>>
>>
>> Multiple declaration is not about how many times a resource appears in
>> your manifests files; it is about how many times it appears in the
>> *catalog* built from the manifests. Every instance of a defined type
>> added to the catalog carries a declaration of each resource declared in the
>> type definition's body. Each declaration of a defined type creates a
>> separate instance. E.g.
>>
>> # two instances of defined type
>> # my_module::my_type:
>> my_module::my_type { 'foo': }
>> my_module::my_type { 'bar': }
>>
>> That's why I said earlier that "defined type instances must declare only
>> resources that wholly belong to them; they must not not declare shared
>> resources". Let me now augment that by pointing out that any resource that
>> is not specific to a defined-type instance cannot wholly belong to that
>> instance, at least when multiple instances of the type are declared.
>>
>>
>> John
>>
>>
--
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/3cc68ae9-046b-4c7c-b039-ec4234fb95dd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
