I''m starting to use hiera more, to try to clean up and better
modularize
some of our stuff.
I know you can use various facts (such as $::hostname) when defining the
hierarchy and where to look.
We have a few variables that are set based on patterns of hostname, and
currently we have a selector that matches the hostname against a regex.
Is there a clean way to move this to hiera? A straight %{hostname} in the
hiera.yaml won''t work, since then I''d have to create a .yaml
per hostname
and it''d be a hassle to
Say I have the hostnames setup like: "prefix-purpose-[A-Z]-[0-9]+"
where
prefix is a fixed value across all names, purpose describes whether it is a
web server, app server etc.
I''d like to be able to specify things for a given
"prefix-purpose-[A-Z]"
range as well as on a "prefix-purpose" basis.
I do hope what I am asking is clear, if not I apologize.
--
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/-/u3bhvLZBz2sJ.
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.
----- Original Message -----> From: llowder@oreillyauto.com > To: puppet-users@googlegroups.com > Sent: Thursday, June 28, 2012 7:59:50 PM > Subject: [Puppet Users] hiera questions > > I''m starting to use hiera more, to try to clean up and better > modularize some of our stuff. > > I know you can use various facts (such as $::hostname) when defining > the hierarchy and where to look. > > We have a few variables that are set based on patterns of hostname, > and currently we have a selector that matches the hostname against a > regex. > > Is there a clean way to move this to hiera? A straight %{hostname} in > the hiera.yaml won''t work, since then I''d have to create a .yaml per > hostname and it''d be a hassle to > > Say I have the hostnames setup like: "prefix-purpose-[A-Z]-[0-9]+" > where prefix is a fixed value across all names, purpose describes > whether it is a web server, app server etc. > > I''d like to be able to specify things for a given > "prefix-purpose-[A-Z]" range as well as on a "prefix-purpose" basis. > > I do hope what I am asking is clear, if not I apologize.I would make facts on the nodes for these. Let say $role and $subrole and then just use those in your hierarchy with %{role} and %{subrole} thus allowing you to set variable for all those machines there. -- 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 Thursday, June 28, 2012 2:04:09 PM UTC-5, R.I. Pienaar wrote:> > > > ----- Original Message ----- > > I would make facts on the nodes for these. Let say $role and $subrole > and then just use those in your hierarchy with %{role} and %{subrole} > thus allowing you to set variable for all those machines there. >That''s simple enough, and the docs [1] for creating a custom fact are mostly straightforward. The one thing I am unclear on, in the "plugins in modules" [2] document, it says that if you are going to put your custom stuff in a module (such as in their example, named ''custom'') it says to follow the standard layout, and that you have to have a manifests/init.pp. If all that is actually in the thing is lib/facter/myfact.rb, what do I put in the manifests/init.pp ? Is it enough for it to exist but be empty? The document was somewhat unclear on this, or I missed it when reading. [1] http://docs.puppetlabs.com/guides/custom_facts.html [2] http://docs.puppetlabs.com/guides/plugins_in_modules.html -- 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/-/NKCt1qaRwiEJ. 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.
You need your custom fact script in: <module>/lib/facter/<script> On 29/06/2012, at 7:37, "llowder@oreillyauto.com" <llowder@oreillyauto.com> wrote:> > > On Thursday, June 28, 2012 2:04:09 PM UTC-5, R.I. Pienaar wrote: > > > ----- Original Message ----- > > I would make facts on the nodes for these. Let say $role and $subrole > and then just use those in your hierarchy with %{role} and %{subrole} > thus allowing you to set variable for all those machines there. > > That''s simple enough, and the docs [1] for creating a custom fact are mostly straightforward. > > The one thing I am unclear on, in the "plugins in modules" [2] document, it says that if you are going to put your custom stuff in a module (such as in their example, named ''custom'') it says to follow the standard layout, and that you have to have a manifests/init.pp. >You need your custom fact script in: <module>/lib/facter/<script>> If all that is actually in the thing is lib/facter/myfact.rb, what do I put in the manifests/init.pp ? Is it enough for it to exist but be empty? >You would normally put your module definitions in init.pp but you should have the following as a minimum: class <module name> { }> The document was somewhat unclear on this, or I missed it when reading. > > [1] http://docs.puppetlabs.com/guides/custom_facts.html > [2] http://docs.puppetlabs.com/guides/plugins_in_modules.html > -- > 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/-/NKCt1qaRwiEJ. > 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.-- 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.
In regard to: Re: [Puppet Users] hiera questions, llowder@oreillyauto.com...:> On Thursday, June 28, 2012 2:04:09 PM UTC-5, R.I. Pienaar wrote: >> ----- Original Message ----- >> >> I would make facts on the nodes for these. Let say $role and $subrole >> and then just use those in your hierarchy with %{role} and %{subrole} >> thus allowing you to set variable for all those machines there. >> > > That''s simple enough, and the docs [1] for creating a custom fact are > mostly straightforward.I would echo what others have said. Create some custom facts for personalities or roles (and subroles, etc., if necessary) for your systems, and have your hierarchy set to search based on those. We use: :hierarchy: - secure/fqdn/%{clientcert} - fqdn/%{clientcert} - secure/location/%{location} - location/%{location} - secure/common - common Note that "location" is a custom fact for us, based on datacenter. You could do something similar, just don''t go crazy with the hierarchy levels.> The one thing I am unclear on, in the "plugins in modules" [2] document, it > says that if you are going to put your custom stuff in a module (such as in > their example, named ''custom'') it says to follow the standard layout, and > that you have to have a manifests/init.pp. > > If all that is actually in the thing is lib/facter/myfact.rb, what do I put > in the manifests/init.pp ? Is it enough for it to exist but be empty?Yes it is. You probably have some kind of "base" or "our_site" module already that just does things like include ntp include admin_packages include ssh include syslog etc. You could associate your custom fact(s) with that module by putting them in the lib/facter directory for that module. Tim -- Tim Mooney Tim.Mooney@ndsu.edu Enterprise Computing & Infrastructure 701-231-1076 (Voice) Room 242-J6, IACC Building 701-231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 -- 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 Thu, Jun 28, 2012 at 08:04:09PM +0100, R.I.Pienaar wrote:> I would make facts on the nodes for these. Let say $role and $subrole > and then just use those in your hierarchy with %{role} and %{subrole} > thus allowing you to set variable for all those machines there.Howdy: I was wondering what is the best way to manage custom facts for a disparate group of servers that need to report different fact values for the same fact name? I am about to embark on hiera-based puppet architecture and want to archetect it only once. I have some doubts about the recommended ways of rolling out facter as it can get messy burying facter server host configuration logic in disparate modules. Let''s say you want to create only one custom fact script to manage all your facts based on data center location and functional server host grouping. You decide you can manage all your custom facts from one ruby/facter script if you create a ruby function using a hash with your facter matching hostnames loaded in the hash as the key and you can lookup location and function. Now you have to choose which module to roll it from, but it''s arbitrary. Would one hash in a single custom facter script be enough configuration for the all the hosts? I argue it would as you can add rows and columns to the hash, so it should be able to support all your facter needs. Either using custom facts or loading in all your hosts into a hiera hash, you still have to know your hostnames. However, why bury your custom facter script in a module with all the configuration in there too? The current architecture and directed use of facter alongside puppet/hiera seems to go against the nature of moving your configuration out of manifests as the direction of puppet/hiera is headed now. I was thinking of creating a hiera hash or two (I am using YAML so far. I could use as many hashes as required but one should be enough probably, plus any arrays), including the information/configuration, grouping servers by location and function, minimally. In my puppet modules I can use hiera to call up my hash and create ruby/puppet functions to do the server host location and functional logic based on the default facter facts of hostname and operatingsystem reported by the server host themselves. All the configuration remains in hiera and the module manifests remain puppet business logic. Comments? Regards, -dkw -- 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. juli 2012 17:26, Darryl Wisneski wrote:> modules I can use hiera to call up my hash and create ruby/puppet > functions to do the server host location and functional logic based > on the default facter facts of hostname and operatingsystem reported > by the server host themselves. All the configuration remains in > hiera and the module manifests remain puppet business logic. > > Comments?Off list as I''m too lazy to write in length and explain it all ;-) Do you care that the node (i.e root on the server) is able to say anything at all about its role and location? If you place a fact on the system that says what it is it could lie. What I''m getting at is security. I''ve designed my own hiera setup so that I don''t use ANY host-derived facts, at all. The only thing I can be (relatively) sure of on the puppetmaster is that clientcert is what it says it is. In a multi-tenant scenario (or easier even, in a scenario where all your servers have a common root password) where would you place your source of truth? Don''t know if you see this or care but still fired this off. best, Jan Ivar Beddari Linux/Mac architect University of Bergen, Norway -- 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.
On 02. juli 2012 17:26, Darryl Wisneski wrote:> > Regards, > -dkwOuch, sorry Darryl, I hit the wrong button and posted what I thought of as a private veeeeery quick reply to you .. right on the list. Now at least everyone sees my honest-to-god thoughts on the matter. And the scope of the message becomes a bit more broad. Might even be worth starting a new thread. To the OP, sorry for being such a thread crasher. As to your question I think the answers you got are OK but hopefully you understand what caveats there might be security-wise. best, Jan Ivar -- 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.
On Mon, Jul 02, 2012 at 10:13:51PM +0200, Jan Ivar Beddari wrote:> On 02. juli 2012 17:26, Darryl Wisneski wrote: > > > > Regards, > > -dkw > > Ouch, sorry Darryl, I hit the wrong button and posted what I thought of > as a private veeeeery quick reply to you .. right on the list.Jan: I too am sorry I stole the thread. I had best intentions, alas I got carried away. I am interested in learning how you structured your hiera data and dealt with puppet code with the use of no/limited facts. The security point is well taken. At some point though, there has to be trust (obviously). General security best-practice considers mitigating procedures (such as IDS, file integrity monitoring (aide), and regular patching) your best attempt to avoid placing too much trust in the management tool. Regards, -dkw> > Now at least everyone sees my honest-to-god thoughts on the matter. And > the scope of the message becomes a bit more broad. Might even be worth > starting a new thread. > > To the OP, sorry for being such a thread crasher. As to your question I > think the answers you got are OK but hopefully you understand what > caveats there might be security-wise. > > best, > Jan Ivar > > -- > 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. >-- 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.
> > I would make facts on the nodes for these. Let say $role and $subrole > and then just use those in your hierarchy with %{role} and %{subrole} > thus allowing you to set variable for all those machines there. >As far as I understood puppet is a config management system that configures systems consistently over the enterprise based on facts and Hiera is a hierarchical system that tells puppet whet the servers need (or actually the other way arround, puppet looks up Hiera info). Setting facts on a few servers is no problem, but what happens if you manage several 100 servers? One of the primary goals for us in implementing puppet/hiera was to avoid logins on servers. Every config change should NOT happen on a server. A server must be completely replaceable. We never want to come to a situation where we would have to look into a damaged server trying to find out what custom roles were defined in it. So, how do we solve this? We want to manage a server by just putting those roles in hiera. If we want a server to do more we simply add a role. If we need more servers to do more we create a new role, define what needs to be done and add that role to the corresponding .yaml files. so, a server on our hiera has something like: roles: - database than it will load a file global/roles/database.yaml that has: classes: - mysql This way our entire config is still in one place and we never have to do any "per server" work. Just the way Puppet was originally designed (again, as far as I understood). best regards, Alex -- 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/-/FzmHYCxLUqMJ. 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.
This thought crossed our minds as well. I created the following feature request awhile back: https://projects.puppetlabs.com/issues/13934#change-60706 the intent behind which is "if this fact is flagged as immutable, and it changes, something is drastically wrong… (don''t)? do something" until something along those lines is implemented, however, the following works reasonably well: the client/puppet master communication is wrapped around the base layer of trust of the ssl cert''s CN. if you use that name to perform a lookup against an accessory lookup table before feeding hiera, this will accommodate most environments ''bootstrappy'' needs… i.e.: certname: fooweb.product1.somesite.com<http://fooweb.product1.somesite.com> role: webserver tier: qa environment: product1 etc… your lookup table is outside of the client''s control, so it cannot change these pieces of information. It also can not easily change it''s certname… this provides a reasonable amount of security, and flexibility… I''d prefer to set a handful of facts that I know are ''correct'' at system install time and not perform extra puppet master work at manifest compilation time, but that''s just me. W On Jul 2, 2012, at 2:57 PM, Jan Ivar Beddari wrote: On 02. juli 2012 17:26, Darryl Wisneski wrote: modules I can use hiera to call up my hash and create ruby/puppet functions to do the server host location and functional logic based on the default facter facts of hostname and operatingsystem reported by the server host themselves. All the configuration remains in hiera and the module manifests remain puppet business logic. Comments? Off list as I''m too lazy to write in length and explain it all ;-) Do you care that the node (i.e root on the server) is able to say anything at all about its role and location? If you place a fact on the system that says what it is it could lie. What I''m getting at is security. I''ve designed my own hiera setup so that I don''t use ANY host-derived facts, at all. The only thing I can be (relatively) sure of on the puppetmaster is that clientcert is what it says it is. In a multi-tenant scenario (or easier even, in a scenario where all your servers have a common root password) where would you place your source of truth? Don''t know if you see this or care but still fired this off. best, Jan Ivar Beddari Linux/Mac architect University of Bergen, Norway -- 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. ________________________________ This message may contain confidential or privileged information. If you are not the intended recipient, please advise us immediately and delete this message. See http://www.datapipe.com/legal/email_disclaimer/ for further information on confidentiality and the risks of non-secure electronic communication. If you cannot access these links, please notify us by reply message and we will send the contents to you. -- 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.