Jira (PUP-8220) Handle lookup CLI "trusted" in a better way

9 views
Skip to first unread message

Henrik Lindberg (JIRA)

unread,
Nov 30, 2017, 4:26:02 AM11/30/17
to puppe...@googlegroups.com
Henrik Lindberg created an issue
 
Puppet / Bug PUP-8220
Handle lookup CLI "trusted" in a better way
Issue Type: Bug Bug
Assignee: Unassigned
Created: 2017/11/30 1:25 AM
Priority: Normal Normal
Reporter: Henrik Lindberg

The handling of trusted facts in the lookup CLI is somewhat unclear. In this ticket we need to discuss and decide on how it should handle trusted information and if something needs to change.

See background in PUP-7507.
Add Comment Add Comment
 
This message was sent by Atlassian JIRA (v7.0.2#70111-sha1:88534db)
Atlassian logo

Henrik Lindberg (JIRA)

unread,
Nov 30, 2017, 4:30:03 AM11/30/17
to puppe...@googlegroups.com
Henrik Lindberg commented on Bug PUP-8220
 
Re: Handle lookup CLI "trusted" in a better way

Thomas Hallgren In PUP-7505 you say that trusted is computed from other facts - can you elaborate on that? (As I recall it, they all come from a certificate).

Thomas Hallgren (JIRA)

unread,
Nov 30, 2017, 5:21:02 AM11/30/17
to puppe...@googlegroups.com

Henrik Lindberg I also give an example. The 'clientcert' is just another fact, and trusted is derived from that.

Gerhardus Geldenhuis (JIRA)

unread,
Nov 30, 2017, 5:34:02 AM11/30/17
to puppe...@googlegroups.com

Users will be stupid... as in it is very likely that someone ( me probably ) will specify facts for the trusted hash that is different from what it would have been had it been computed. I personally view 

puppet lookup --facts <file>

as a debug tool and if I do something stupid in it I will see strange behaviour. Perhaps a warning or notice might be in order if you do something like that.

My original intend was to use puppet lookup as a tool to verify my hiera hierarchy is working and supplying the right data. Since we use a number of trusted facts (extended trusted facts ) as part of our hierarchy being able to specify these trusted facts in a debug situation is very useful. We don't currently have PuppetDB configured so those facts can't be obtained by puppet lookup. However I don't want to be relying on puppetdb either and need to pre-emptively test the hierarchy for correct fact lookup.

Henrik Lindberg (JIRA)

unread,
Nov 30, 2017, 5:35:03 AM11/30/17
to puppe...@googlegroups.com

Hm, yes - there is no remote operation, hence no validated cert to pick values from (that is why authentication is "local"). I don't remember exactly how it then populates the trusted information, if it looks up the cert to get them, and what happens if there is no cert.

I imagine that by giving the certname and there is a cert you want the rest of the values from that cert.
Should you be able to override those?
Is it ok if a cert does not exist (you are preparing stuff for a node that does not yet exist)? If so, you must be able to specify all of the trusted information fields.

Henrik Lindberg (JIRA)

unread,
Nov 30, 2017, 5:54:02 AM11/30/17
to puppe...@googlegroups.com

When testing with lookup CLI there are several use cases:

  • The node does not exist (yet):
    • want to simulate and check how data gets resolved
    • a module author want to test against canned typical facts for a platform to verify module layer data
  • The node exists:
    • want to simulate an upcoming change (in facts/trusted)
    • want to use node with (PDB) known facts
    • node has not called in yet, or no facts in PDB (no PDB in use) - need to have an accurate set of facts/trusted
    • want to use canned facts as it is too much of a hassle to get facts for the node, want to also override some of them (the ones specific to the node)

Gerhardus Geldenhuis (JIRA)

unread,
Nov 30, 2017, 6:18:02 AM11/30/17
to puppe...@googlegroups.com

Henrik Lindberg I think it is useful to override values like the certname. When I was playing around with the tool I manually set the hostname on the command line but for most of my data checks, hostnames would not matter since data is determined by datacentre and serviceline which is information captured as extended facts in the certificate. My assumption has mostly been that if I specify it, it will be used and merged with other available data. I am not dead set on such behaviour and as long as the behaviour is very clearly documented or "explained" when increasing the verbosity I think that would be make it easier to use and more difficult to get wrong.

Your outlay of the use cases looks spot on and I would probably have a use case for most of them. My clients work in a very regulated space and this tool ( puppet lookup) makes it very easy for me to proof the effect or lack of effect a data change will have and give me a warm fussy feeling because I know I have tested and won't be breaking stuff.

Maggie Dreyer (JIRA)

unread,
Sep 25, 2019, 7:53:03 PM9/25/19
to puppe...@googlegroups.com
Maggie Dreyer updated an issue
 
Change By: Maggie Dreyer
Team: Server
This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)
Atlassian logo

Jorie Tappa (JIRA)

unread,
Oct 7, 2019, 2:54:04 PM10/7/19
to puppe...@googlegroups.com
Jorie Tappa updated an issue
Change By: Jorie Tappa
Team: Coremunity

Jorie Tappa (JIRA)

unread,
Oct 7, 2019, 2:55:03 PM10/7/19
to puppe...@googlegroups.com
Jorie Tappa updated an issue
Change By: Jorie Tappa
Sprint: Coremunity Grooming

Josh Cooper (Jira)

unread,
Apr 22, 2020, 8:32:02 PM4/22/20
to puppe...@googlegroups.com
Josh Cooper commented on Bug PUP-8220
 
Re: Handle lookup CLI "trusted" in a better way

The lookup application looks up keys based on the node name (either the local node's Puppet[:node_name_value] or the name specified on the command line). If we lookup facts using the facts terminus (using facter or puppetdb), then we could verify that the hostname, domain, fqdn facts in the facts file are consistently set (either all or none). We can then construct a TrustedInformation object from those facts and push the object on the context when making the node request.
This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935)
Atlassian logo

Josh Cooper (Jira)

unread,
Apr 22, 2020, 8:34:03 PM4/22/20
to puppe...@googlegroups.com
Josh Cooper updated an issue
 
Change By: Josh Cooper
Acceptance Criteria: If a facts file is specified and it overrides any of {{hostname}}, {{domain}}, {{fqdn}}, {{clientcert}}, then it must override all of them.

If a facts file overrides these values, then they should be reflected in the trusted information used for classification and lookup resolution.

Josh Cooper (Jira)

unread,
Apr 23, 2020, 12:43:03 AM4/23/20
to puppe...@googlegroups.com
Josh Cooper updated an issue
Change By: Josh Cooper
Sprint: Coremunity Grooming Hopper
Reply all
Reply to author
Forward
0 new messages