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/5e108b5c-a7fa-4fa1-9881-67c9cbabe2bc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
