On Tuesday, November 13, 2012 11:37:12 AM UTC-6, Bernardo Costa wrote:
>
> 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.
Let me be sure you understand that my suggestion (1) results in exactly one
file being managed on each client, and it requires a per-node file on the
master only for those nodes that require a file different from some
standard one. It is therefore a fairly good choice both when most of your
nodes want the same mountpoints (because you need special-case files only
for a few nodes), and at may be a good choice when most nodes are different
-- even if there is a shared core of common mount points -- because you'll
need special-case files for most nodes anyway. Of course, you may be
somewhere in between, or the suggestion may just not suit you.
> 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 don't understand what you mean by that. In particular, your use of
"incremental" makes me suspect a misunderstanding: my option (1) does not
involve concatenation of source files. Puppet will sync the target file
with the first file from its 'source' list that exists. Thus, for those
nodes that have a corresponding puppet:///files/automount/${hostname}.conf
file, that file will be the source used, and for all other nodes
puppet:///files/automount/basic.conf would be used instead.
> 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 ?
>
Option 3 (using the Concat module) makes the most sense if you are building
the file from a relatively small number of possible blocks (each of which
could define any number of mount points). If your mount points fall into
natural groups by role, location, department, or such then modeling them as
file fragments via Concat might really clarify your manifests.
Alternatively, it might work out well to have the "basic" mount points in
one static fragment, and everything else in one optional, template-built
fragment.
On the other hand, although Concat is a useful module, it could be a lot
heavier than you really need. You'll need to decide for yourself whether
it's worth it. You should be able to find some talk about it in the
archives of this group, and you can find the module itself on the Forge.
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/-/3c5I1Eo1CDgJ.
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.
