On Mon, Apr 8, 2013 at 4:42 AM, Erik Dalén <[email protected]>wrote:
> 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"]}'?
>
>
Hiera doesn't support that kind of lookup....
> --
> 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.
>
>
>
--
Andrew Parker
[email protected]
Freenode: zaphod42
Twitter: @aparker42
Software Developer
*Join us at PuppetConf 2013, August 22-23 in San Francisco - *
http://bit.ly/pupconf13*
**The first 150 tickets sold will be available at a 35% discount - register
now!*
--
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.
