Ah, now I see where you're coming from.
Turns out the virtual resource is a good idea then after all.
To make this work, I believe you have to
- not declare the virtual resource in the central class
- do declare one virtual header snippet per defined type
- realize the header snippet in the same
On Fri, Feb 15, 2013 at 10:12 AM, Felix Frank
wrote:
> Hi,
>
> it's paramount that you generate a unique $name for each invocation of
> your defined type, e.g.
>
> pam::header { "limits-$name": }
>
> You can take advantage of the fact that the "calling" defines have
> unique names of their own.
R
Hi,
it's paramount that you generate a unique $name for each invocation of
your defined type, e.g.
pam::header { "limits-$name": }
You can take advantage of the fact that the "calling" defines have
unique names of their own.
HTH,
Felix
On 02/15/2013 03:31 PM, Darin Perusich wrote:
>> > I belie
Hi Felix,
On Thu, Feb 14, 2013 at 7:07 AM, Felix Frank
wrote:
> So basically you want all generated files to use the same header
> template? Hmm.
This is correct.
> I believe what you want is another defined type that represents "the
> header snippet for a specific pam config file" and declares
Wait, what?
You're starship-overriding the one header resource to use whatever
target "gets lucky"? I think this is bound to break, no?
So basically you want all generated files to use the same header
template? Hmm.
I believe what you want is another defined type that represents "the
header snip
Hello All,
I have two defined types which I'd like to share a common, realized
header concat resource but when both are declared in a manifest the
header is only applied to one of the types. When the headers are
declared independently for each type the work but that's is a bunch of
nearly identica
