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, <aarb...@gmail.com> 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+unsubscr...@googlegroups.com.
> 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/CAAohVBdZb_P5u6vTiaHuNrvfGd_LdSd7fRv1iL_t3DkDu1KtQg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
