Well, what I could understand from your proposition (1) is that I should
elect one of the hosts as representative of a group of hosts and make all
other hosts inherit its configuration like the example I am showing below.
class automount {
file { "/var/tmp/auto.direct":
source =>"puppet:///files/automount/${hostname}.conf",
}
}
node default {
include automount
}
node itchy1, itchy2, itchy3 inherits default {
file { "/var/tmp/auto.direct":
source =>"puppet:///files/automount/itchy.conf",
}
}
What I'd like to avoid using this scheme of concatenating templates is
changing many files when only one entry is changed. Supposing many hosts
mount a specific directory, if the provider file of this directory changes,
then I'd need to use a sed script to change only one entry. In fact, this
is a complex issue. Maybe the best thing is not putting every direct
mountpoints in only one map/file but splitting them in maybe two, three or
four. For this, I'd need a auto.master file like the one below.
/- /etc/auto1.direct
/- /etc/auto2.direct
/- /etc/auto3.direct
/- /etc/auto4.direct
Your idea of defining a basic map and just override the basic if a
particular map exists with the name of the host is interesting but for my
case, I'd need almost one particular map for each host. Most of the hosts
have particular direct mountpoints. Although this is a fairly complex thing
to configure in all hosts, I am trying to find the most simple and elegant
solution :) For now, I am trying to avoid using concat module as I prefer
to have the bare minimum of puppet features and not many dependences on
external tools. Anyway, thank you for you help.
Em terça-feira, 13 de novembro de 2012 20h09min31s UTC-2, jcbollinger
escreveu:
>
>
>
> 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/-/2CGcGM9RVb4J.
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.
