On Monday, September 22, 2014 2:58:52 PM UTC-5, aar...@gmail.com wrote:
>
> 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'm not sure exactly what you are misunderstanding. Myself, I am evidently
having trouble understanding either exactly what it is you are trying to
do, or else why you cannot use the approach I outlined to do it.
Yes, the point of adding "/${title}" to the end of the name of the managed
File resource is to make that resource manage a subdirectory of the
Preferences directory (or a plain file in that directory) instead of the
Preferences directory itself. This supposes that each defined type
instance will manage some one or more files in that directory, unique to
that instance, rather than the directory itself. That is the only way it
can work to split the management across multiple defined type instance, as
no two instances can manage the same resource.
> 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.
>
>
There is no "sending around lists of files". Each File resource specifies
state for exactly one file/directory, and there must not be multiple
specifications for the same file (even if they are identical). The
declaration of a recursive File resource causes additional File resources
to be declared implicitly, based on the File's source tree on the master,
where explicit File resources corresponding to those files are not declared.
> 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?
>
You are missing the point. Duplicate resources are not fundamentally about
resource *titles*. That's ancillary. They are about having exactly one
specification for each target resource to be managed on the client.
> 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?
>
>
Neil's example code demonstrates another variation on the same approach I
presented. The general idea is that each for each application for which
preferences are to be managed, the corresponding defined type instance must
declare only the files / subdirectories of the user's Preferences folder
that belong to that application.
Neil and I both suppose that the preferences for each application are in
fact segregated from one another in separate files or subdirectories of the
Preferences directory. If that's not the case then you need a different
approach.
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/f52fa7f1-6d4a-47d6-9e95-5b5074409252%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
