Ok John, it looks like sourceselect exists for handling files like the ones 
under /etc/profile.d which is not the case for automount. Good to know. 
About the options I have, I'd prefer not doing #1 for two reasons: one is 
that many mountpoints would be duplicated toward many files as they are 
common for all hosts or for a great number of them, and two is that I'd 
like to reduce the number of different automount maps managed which makes 
me avoid doing a one map for each host policy. But the cost of doing things 
this way is managing hosts as a group of them and having to treat the 
automount maps as incremental although it is not like this.
I think I have seen an example of #2 and just could make it work int this 
way but I can't remember of having seen any example of #3. Is there any 
advantage on trying way #3 ? If I do it, I believe I'll ne to install this 
concat module. Where is it available ?

Em terça-feira, 13 de novembro de 2012 12h45min43s UTC-2, jcbollinger 
escreveu:
>
>
>
> On Monday, November 12, 2012 1:00:14 PM UTC-6, Bernardo Costa wrote:
>>
>> I am using puppet-2.6.17 from a centos 5.x box and after reading the 
>> documentation (
>> http://docs.puppetlabs.com/references/2.6.17/type.html#file) I feel the 
>> need of using the sourceselect parameter set to all for 
>> copying/concatenating contents from multiple files to a single one. But it 
>> miserably fails on this issue. Below is an example of configuration I have 
>> tried without success. The idea is to create a base class for common 
>> contents of an automount map and also two specialized classes for 
>> particular mount points of each node. I believe with "sourceselect => all" 
>> it would be possible but I couldn't see it working. Any ideas of why ...?
>>
>
>
> The 'sourceselect' parameter doesn't do what you think it does.  It 
> applies only to File resources that manage directories recursively, where 
> it directs Puppet to combine the contents of all the specified 'source' 
> directories that exist.  Furthermore, "combine" in that case applies at the 
> level of identifying which files to manage, from which sources; it does not 
> produce concatenation under any circumstances.
>
>  
>
>>
>> File {
>>     ensure => file,
>>     group  => "root",
>>     owner => "root",
>>     mode  => "0644",
>> }
>>
>> class automount {
>>     file { "/var/tmp/auto.direct": 
>>         source => "puppet:///files/automount/basic.conf",
>>         sourceselect => "all",
>>     }   
>> }
>>  
>> class automount::itchy inherits automount {
>>     File['/var/tmp/auto.direct'] { 
>>         source => [ "puppet:///files/automount/itchy.conf", 
>> "puppet:///files/automount/basic.conf" ],
>>         sourceselect => "all",
>>     }   
>> }
>>
>> class automount::scratchy inherits automount { 
>>     File['/var/tmp/auto.direct'] { 
>>         source => [ "puppet:///files/automount/scratchy.conf", 
>> "puppet:///files/automount/basic.conf" ],
>>         sourceselect => "all",
>>     }   
>> }
>>
>> node default { 
>>     include automount
>> }
>>  
>> node 'itchy' inherits default {
>>     include automount::itchy
>> }
>>
>> node 'scratchy' inherits default {
>>     include automount::scratchy
>> }
>>
>
>
> Some of your options are:
>
>    1. Make puppet:///files/automount/scratchy.conf and the like complete 
>    configuration files rather than supplemental file fragments
>    2. Use 'content' instead of 'source', and create the content via the 
>    template() function (even if only to perform the concatenation when you 
>    want it)
>    3. Use the Concat module to build your files from fragments where 
>    needed (though this is really a wrapper around the above)
>
> Note that although option (1) will produce some duplication of your config 
> files, it could greatly simplify your manifests.  Consider:
>
> class automount {
>   file { "/var/tmp/auto.direct": 
>     source => [
>       "puppet:///files/automount/${hostname}.conf",
>       'puppet:///files/automount/basic.conf"]
>   } 
> }
>
> No subclasses or special node blocks needed.
>
> In fairness, options (2) and (3) could also be written to avoid 
> subclassing and special node blocks, but not so simply and easily as it can 
> be done with option (1).
>
>
> John
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/puppet-users/-/AHrhwrVJ0dYJ.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Reply via email to