Actually, on second thought it would be good if this was usable in hiera
hierarchies. Will that work with a value in a hash?
Can you do something like '%{trusted["nodename"]}'?
--
Erik Dalén
On Monday 8 April 2013 at 13:07, Erik Dalén wrote:
>
>
> On Friday 5 April 2013 at 20:49, Andy Parker wrote:
>
> > In issue #19514 (https://projects.puppetlabs.com/issues/19514) there
> > is some discussion about adding some trusted information to the puppet
> > manifests. Chris Spence has provided a suggested solution, but he
> > wasn't sure about it. It adds a topscope variable called
> > "servernodename" that contains the name that the node has checked in
> > with, which is validated against the certificate.
> >
> > The proposed solution fits this one particular use case, but has the
> > drawback of continuing the use of topscope for different purposes.
> > There has been a bit of discussion between Patrick, Eric, and myself
> > about this and we batted around a couple of ideas:
> >
> > * Create a pseudo-class, like settings, for trusted data
> > * Use these topscope variables
> > * Create a topscope hash for trusted data
> >
> > The first seems kinda nice, but has the issue that class scope lookups
> > leak topscope.
> >
> > > bundle exec puppet apply -e '$foo = 1 notice($settings::foo)'
> >
> > Notice: Scope(Class[main]): 1
> > Notice: Finished catalog run in 0.04 seconds
> >
> > This means that it would be very easy to use something that you think
> > is trusted, but it turns out you are actually using the untrusted top
> > scope fact.
> >
> > The second (topscope variables) have the problem, that there is
> > nothing unifying them into a common whole that calls out what all of
> > the trusted data is. It also has the drawback of creating an ever
> > growing set of variables that will conflict with people’s manifests.
>
>
>
> I don't really see how they conflict as variables in people's manifests will
> be in class scopes and facts are in top scope.
>
> But I agree that it will make it trickier to know what is trusted and what
> isn't as there's nothing distinguishing them.
> >
> > The third option probably turns out to be the best. It gives us a
> > place to add more trusted information over time without having to
> > worry about clobbering manifest data. It doesn’t leak data from other
> > sources. It also fits with normal data structures and data structure
> > manipulation functions that exist.
> >
> > So in order to get the trusted name we should create a top level hash
> > named “trusted”, with a key called “nodename”.
>
>
>
>
> Hmm, not sure about the name "trusted", maybe "server" as it is data set by
> the server and not the client?
>
> Also, will this still be set when running puppet apply? Of course it won't be
> trusted or server set then, but might be nice for compatibility.
> >
> > I think that this should be done without modifying the Puppet::Node
> > class/object and instead we just inject this one top level variable in
> > the compiler.
>
>
> Yeah, there's some issues to think about with custom auth.conf settings
> though. Like if you allow other certs to access catalog or node objects, or
> even unauthenticated access to them.
>
> --
> Erik Dalén
--
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/puppet-dev?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
