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