Hi Folks To begin with i am looking to deploy a completely new puppet config based on the truth module https://github.com/jordansissel/puppet-examples/tree/master/nodeless-puppet/modules/truth However i want a way of separating data from modules based on this hierarchy: domain - ie blogs.com => common data distributed to all nodes/devices cluster ie. DC1 => ip address changes for services like ntp, resolver etc environment/zone - ie UAT => data and modules common to this environment server class ie web => include a role for apache, jboss, etc Is it possible to structure hiera to use this hierarchy ? Anybody have any ideas - remember i wont be using node resources but truth statements -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Ok i did some reading and watched a youtube clip on it also.
Heira can be set in the params manifest which is what ll do - quite
dangerous that ill be using this approach at a company i work for :-)
Next i have established my hierarachy as such :
hierarchy: - %{_domain}/%{_environment}/%{_cluster}/%{_class}
%{_domain}/%{_environment}/%{_cluster}
%{_domain}/%{_environment}
%{_domain}
: yaml:
:datadir: /etc/puppet/hierdatadb
So the filesystem looks like this:
/etc/puppet/hierdatadb/ri3k.com/preprod/uk1/web.yaml
/etc/puppet/hierdatadb/ri3k.com/preprod/uk1.yaml
/etc/puppet/hierdatadb/ri3k.com/preprod.yaml
because im using a nodeless approach ill have to create a factor
plugin that will read the following values
/etc/system_facts
role:apache
_domain:ri3k.com
_cluster:dc1
_environment:systest
_class:web
ill have to figure out better fact names but i hope im making sence
here. The factor pluging and files will be setup at deployment time -
and puppet can then be run manually which will use the values to set
the host and define its role
Can anyone suggest a better way of doing this ?
On Mar 2, 1:15 pm, Daysmen <acuz...@gmail.com>
wrote:> Hi Folks
>
> To begin with i am looking to deploy a completely new puppet config
> based on the truth
modulehttps://github.com/jordansissel/puppet-examples/tree/master/nodeless-...
>
> However i want a way of separating data from modules based on this
> hierarchy:
>
> domain - ie blogs.com => common data distributed to all nodes/devices
> cluster ie. DC1 => ip address changes for services like ntp, resolver
> etc
> environment/zone - ie UAT => data and modules common to this
> environment
> server class ie web => include a role for apache, jboss, etc
>
> Is it possible to structure hiera to use this hierarchy ?
>
> Anybody have any ideas - remember i wont be using node resources but
> truth statements
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
On 02. mars 2012 14:15, Daysmen wrote:> Hi Folks > > To begin with i am looking to deploy a completely new puppet config > based on the truth module > https://github.com/jordansissel/puppet-examples/tree/master/nodeless-puppet/modules/truth >Just a general comment of nodeless Puppet and the truth-enforcer design: It is a great solution if you know what you are doing. First, you must really consider what and where is your source of truth, security wise. If not you could end up with root at any server in the design being able to override its truth to be whatever it wants to. If that is ok with you, then please go ahead. Our Puppet installation is multi-everything, platforms, roles, admins, organizational units and so on. A model where each node possibly could decide and/or override its truth would not work for us. -- http://www.uib.no/personer/Jan.Ivar.Beddari -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
The same would apply to customised facts used to provide information to puppet master to compile the catalog If the facts can be change the surely this would alter the build My customised facts are stored in a root owned file that - i guess for security you could as well audit that file or lock it down using selinux preventing even root from changing it (though selinux enabled be an administrative burden for some) My point is that customised facts via export variables or a puppet fact plugin can be changed On Mar 13, 7:55 am, Jan Ivar Beddari <jan.ivar.bedd...@uib.no> wrote:> On 02. mars 2012 14:15, Daysmen wrote: > > > Hi Folks > > > To begin with i am looking to deploy a completely new puppet config > > based on the truth module > >https://github.com/jordansissel/puppet-examples/tree/master/nodeless-... > > Just a general comment of nodeless Puppet and the truth-enforcer design: > It is a great solution if you know what you are doing. > > First, you must really consider what and where is your source of truth, > security wise. If not you could end up with root at any server in the > design being able to override its truth to be whatever it wants to. If > that is ok with you, then please go ahead. > > Our Puppet installation is multi-everything, platforms, roles, admins, > organizational units and so on. A model where each node possibly could > decide and/or override its truth would not work for us. > > --http://www.uib.no/personer/Jan.Ivar.Beddari-- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.