Thanks Neil,
In yours and Johns example you both have ${title} at the end of
Preferences. When I tried this (after his post, I haven't tried your code
yet), I ended up with a folder called Preferences/office_2011 which defeats
the purpose of what I am trying to do. Am I misunderstanding that line? I
understand why two modules can't manage the same folder (from a Puppet
perspective) but was thinking that all of my modules would send a list of
files to the one module that had the ability to write to that folder and it
would work.
I really appreciate everyone trying to help me, but I guess there is
something that I am not understanding, or perhaps I am not explaining
myself properly. If I have a variable after Preferences (which I need to
prevent the duplicate resource) then how do I get all of my files into the
root of that Preference folder?
I apologize if your code works the way I am asking, but if it does, then I
don't understand what the variable is doing after the word Preference and
could use some clarification on that. Also, what is the $components
variable mean? Is that a type of function or feature that I can read up on
in the documentation?
On Monday, September 22, 2014 2:27:44 PM UTC-5, Neil - Puppet List wrote:
>
> Hello
>
> I do not think that is possible or really desirable. Puppet is about
> desired state so you can not say the directory should both be
> /pathtodir
> ├── fileA
> └── fileB
>
> and /tmp should be
> /pathtodir
> ├── fileB
> └── fileC
>
> as the first says must not have fileC and the second says must have
> fileC. Those are conflicting.
>
> Back to what you could do, which is to write to two separate directories
> and then merge them together with a separate command that is triggered by
> either directory changing. But you should not go down that route especially
> in a situation like this where you can specify exactly what files you want.
>
> Going to your original post what you are trying to do is write the
> preferences for a particular application in the User Template for that
> application. Trouble is, looking on my mac, there are multiple plist files
> there for each application
>
> so transform your
> 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"],
> }
>
> into
>
> $components = ['com.microsoft.Excel.plist','com.microsoft.Outlook.plist',]
>
> macprefs::usertemplate{ $components:
> require => Package[$main_package],
> sourcebase => 'puppet:///modules/office_2011/Preferences',
> }
>
> (or that can be wrapped up into a define for this set of prefs,)
>
> now you need to implement macprefs::usertemplate. (I've ignored the
> language/locale issue which could complicate matters)
>
> so now you make a module and in there you do similar things to John's post
>
> in a file macprefs/manifest/init.pp start by making "/System/Library/User
> Template"
>
> class macprefs {
> # A shared resource:
> file { '/System/Library/User Template/English.lproj/Library/Preferences
> ':
> ensure => 'directory',
> owner => 'root',
> owner => 'wheel',
> mode => '0700'
> }
> }
>
> in a file macprefs/manifest/usertemplate.pp
>
> define macprefs::usertemplate($sourcebase, $require) {
> # relies on the preferences base directory:
> include 'macprefs'
>
> # A file in the templates directory:
> file { "/System/Library/User Template/English.lproj/Library/Preferences
> /${title}":
> ensure => 'file',
> source => "$sourcebase/$title",
> require => $require,
> owner => 'root',
> group => 'wheel',
> mode => '0600'
> }
> }
>
> ----
> Neil
>
> On 22 September 2014 17:30, <aar...@gmail.com <javascript:>> wrote:
>
>> Thanks John,
>>
>> By putting the /etc/preferences/${title} in the file line, aren't you
>> putting a subfolder in the preferences folder on the puppet agent? I tried
>> to follow your example and it happened to me.
>>
>> What I am looking to do is to have different modules writing into the
>> base folder, in your example "/etc/preferences/". The modules won't ever
>> have the same file names, so overwritting isn't a concern.
>>
>> Is this possible?
>>
>>
>> On Monday, September 22, 2014 9:33:04 AM UTC-5, jcbollinger wrote:
>>>
>>>
>>>
>>> On Saturday, September 20, 2014 2:33:34 PM UTC-5, aar...@gmail.com
>>> wrote:
>>>>
>>>> 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?
>>>>
>>>>
>>>
>>> A class may be declared multiple times (though the resource-like syntax,
>>> if used, must be the first one evaluated), with the same effect as
>>> declaring it just once. That is, classes are idempotent. Ordinary
>>> resources, including defined-type instance, may be declared only once.
>>> Given that defined types are usually meant to allow multiple instances, it
>>> follows that defined type instances must declare only resources that wholly
>>> belong to them; they must not not declare shared resources. Instead, they
>>> can rely on a class to declare the shared resources.
>>>
>>> For example:
>>>
>>> class my_module::preferences_base {
>>> # A shared resource:
>>> file { '/etc/preferences':
>>> ensure => 'directory',
>>> owner => 'root',
>>> owner => 'group',
>>> mode => '0644'
>>> }
>>> }
>>>
>>> define my_module::preference_file($source) {
>>> # relies on the preferences base directory:
>>> include 'my_module::preferences_base'
>>>
>>> # A file in the preferences base directory:
>>> file { "/etc/preferences/${title}":
>>> ensure => 'file',
>>> source => $source,
>>> owner => 'root',
>>> owner => 'group',
>>> mode => '0644'
>>> }
>>> }
>>>
>>>
>>> That should also work if the the shared directory is managed
>>> recursively, or if the defined type declares a directory instead of a file
>>> -- even a recursively managed one. Does that help?
>>>
>>>
>>> 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...@googlegroups.com <javascript:>.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/puppet-users/99ac011e-153b-4675-825f-575fd81bf911%40googlegroups.com
>>
>> <https://groups.google.com/d/msgid/puppet-users/99ac011e-153b-4675-825f-575fd81bf911%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/4ae2d5be-5b4b-4b50-9b1a-0753d68a084a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
