Uploaded image for project: 'Puppet'
  1. Puppet
  2. PUP-5441

$trusted is not available in master compile and fails when coming from PDB



    • Bug
    • Status: Closed
    • Blocker
    • Resolution: Fixed
    • PUP 3.8.3, PUP 4.2.3
    • PUP 4.3.0
    • None
    • None
    • 3
    • Language 2015-11-11
    • Bug Fix
    • Sanitizes the trusted info in the node object when it is restored from cache. This prevents "Attempt to assign to a reserved variable name: 'trusted' " errors when running standalone compiles on a master node, among other scenarios.


      There are two sides to this problem:

      • As the subject says - the information in $trusted is not available when running applications like puppet master compile and puppet lookup under most normal configurations (unless being hit by the next part of the problem)
      • When having a configuration that directly hits puppet db for information, puppet db stores the trusted information as a regular node parameter. When puppet db terminus returns that, an attempt is subsequently made to set the privileged scope variable $trusted and that is rejected. There are several tickets that report this problem.

      Resurrecting $trusted

      We absolutely do want to resurrect the $trusted information. If not done, then puppet master compile will not work if manifests include use of $trusted, or (as recommended) that the hiera hierarchy uses $trusted to get a trusted certname as part of the path to data.

      We should therefore resurrect the information in a reasonable way. This means two things:

      • When caching a node - it should cache the trusted facts as a parameter with the name "trusted" just like it is done in puppet db.
      • A node given to the compiler should be "sanitized" before it is used. If there is real trusted data (from a remote request) or from a self authenticated local "apply" available, that trusted data should be used. If not available, but available in form of parameters looked up from the node indirection (cache or backing store) that trusted information should be used with one extra processing step being performed.
      • If the trusted information comes from the indirection, the attribute authenticated should be set to false if the process is not running as root, otherwise, this attribute retains its value (i.e. most likely the value "remote" which means that the node cert was used to authenticate).

      Note that the difference in $trusted[authenticated] is of importance for those that manage secrets as it can be used to take an alternative path in the logic - using anonymized/boilerplate values instead of real values. This is of value if users should be able to run master compile to debug what is going on in a catalog, but they are not authorized to see certain values. (A fairly advanced use-case). Running as root allows a user to run exactly as if a request was authenticated from a cert - the user must know that the configuration is safe - i.e. that a backing store/cache is in use that can be trusted.

      Relationship to other tickets/reportd problems

      This ticket was created because although there are several other reports of the error when trusted is being processed as a parameter - the conditions that cause the problem to occur are different - the reported error typically masks a different error (a configuration failure).

      Here are some of the causes:

      • routes setting points to the wrong or non existing routes.yaml file
      • the routes are wrong
      • the wrong terminus is used for PDB cache
      • user has experimented with termini and have bad data in the cache
      • there is a time skew between agent and master that causes a cache miss (cache timeout is taken from runinterval setting).
      • settings for termini are not done which results in defaults being used which leaves it up to the applications used to set the terminus based on if it is running in master, or agent mode. A setting of 'none' is sometimes (rare) what should have been used.

      The detection of which of these cases that triggrs the 'trusted problem' is difficult to find as the build up of the settings typically fall back on defaults when things are missing (there are several cases above where an error or a warning should be issued to make it easier to find the problem).


        Issue Links



              Unassigned Unassigned
              henrik.lindberg Henrik Lindberg
              0 Vote for this issue
              6 Start watching this issue



                Zendesk Support