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 [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. ________________________________ 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 [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.
