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, aar...@gmail.com 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, aar...@gmail.com 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 puppet-users+unsubscr...@googlegroups.com.
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.
