Puppet users - May 2013 - hiera not using non-root user custom fact

Hi,

Before I begin, my environment consists of a standard master/client config with
the exception that all my clients run under a non-root user.  I have to use
non-root so I can''t simply restart under root to fix the problem.

Master -> 3.1.1
Client  -> 2.7.17

using mostly the hiera() function in my classes.

problem:

I have run into an issue today where my custom fact is not being passed to hiera
in order to determine which hiera file to use (see hierarchy).  The custom fact
is definitely defined what it should be but its almost as if it has a
differently scope then say a root level custom fact.  Because of this hiera data
is coming up undefined which causes my classes to fail.

$myvar = hiera(''var-name'')   --> should use custom_env and
custom_release to help determine where the variable is defined in hiera.

Are custom facts from non root users simply not relayed to hiera?

:hierarchy:
  - nodes/%{::fqdn}
  - releases/%{custom_release}
  - env/%{custom_env}
  - common



I have put a bandaid fix in for now which sets these variables via top scope
assignment in one of my classes and allows me to control everything from hiera
instead of using custom facts.  However, I am not sure if this follows good
puppet coding practices when using hiera, since I am using hiera to feed hiera. 
I don''t want to have to define these variables for every node.

bandaid fix:
# this is a top scope variable that is currently a hack to fix an unknown bug
with hiera and local puppet facts
$custom_env = hiera(''custom_env'')  --> defined under
nodes/nodename
$custom_release = hiera(''custom_release'')   --> defined
under nodes/nodename
class roles::specialapp(

  )

{
    include specialapp_profile

}


If this is a new bug, I''ll be happen to file a ticket.

Thanks,

Corey Osman
corey@logicminds.biz







-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

On Monday, May 6, 2013 9:22:40 PM UTC-5, Corey Osman
wrote:
>
> Hi,
>
> Before I begin, my environment consists of a standard master/client config 
> with the exception that all my clients run under a non-root user.  I have 
> to use non-root so I can''t simply restart under root to fix the
problem.
>
> Master -> 3.1.1
> Client  -> 2.7.17
>
> using mostly the hiera() function in my classes.
>
> problem:
>
> I have run into an issue today where my custom fact is not being passed to 
> hiera in order to determine which hiera file to use (see hierarchy).  The 
> custom fact is definitely defined what it should be but its almost as if it
> has a differently scope then say a root level custom fact.  Because of this
> hiera data is coming up undefined which causes my classes to fail.
>
> $myvar = hiera(''var-name'')   --> should use custom_env
and custom_release
> to help determine where the variable is defined in hiera.
>
> Are custom facts from non root users simply not relayed to hiera?
>

The master does not know or care what user the agent runs as.  If hiera is 
not seeing your custom facts (or the expected values for them) then you are 
probably mistaken about them being passed correctly, or else you have not 
instructed hiera the way you think you have done.

 
>
> :hierarchy:
>   - nodes/%{::fqdn}
>   - releases/%{custom_release}
>   - env/%{custom_env}
>   - common
>
>
For certainty, it might be better to use absolute names in those fact 
references "%{::custom_release}" and "%{::custom_env}". 
That your
workaround is successful, however, indicates that not doing so is not the 
problem.

 
>
> I have put a bandaid fix in for now which sets these variables via top 
> scope assignment in one of my classes and allows me to control everything 
> from hiera instead of using custom facts.  However, I am not sure if this 
> follows good puppet coding practices when using hiera, since I am using 
> hiera to feed hiera.  I don''t want to have to define these
variables for
> every node.
>
> bandaid fix:
> # this is a top scope variable that is currently a hack to fix an unknown 
> bug with hiera and local puppet facts
> $custom_env = hiera(''custom_env'')  --> defined under
nodes/nodename
> $custom_release = hiera(''custom_release'')   -->
defined under
> nodes/nodename
> class roles::specialapp(
>
>   )
>
> {
>     include specialapp_profile
>
> }
>
>
> If this is a new bug, I''ll be happen to file a ticket.
>
>
I''m not convinced that it''s a bug at all.  I am inclined to
think that you
are mistaken about the fact values being communicated correctly to the 
master.  What makes you confident that they are received correctly?  It is 
not unreasonable to posit that running the agent as an unprivileged user 
interferes with fact evaluation on the client.


John

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

I was able to solve this.  The facts were being communicated correctly, 
however the custom facts had a additional newline at the end.  So I just 
needed to clean up the whitespace.

 fact.last.strip

Once the fact was cleaned, hiera lookups started to work again.




On Monday, May 6, 2013 7:22:40 PM UTC-7, Corey Osman
wrote:
>
> Hi,
>
> Before I begin, my environment consists of a standard master/client config 
> with the exception that all my clients run under a non-root user.  I have 
> to use non-root so I can''t simply restart under root to fix the
problem.
>
> Master -> 3.1.1
> Client  -> 2.7.17
>
> using mostly the hiera() function in my classes.
>
> problem:
>
> I have run into an issue today where my custom fact is not being passed to 
> hiera in order to determine which hiera file to use (see hierarchy).  The 
> custom fact is definitely defined what it should be but its almost as if it
> has a differently scope then say a root level custom fact.  Because of this
> hiera data is coming up undefined which causes my classes to fail.
>
> $myvar = hiera(''var-name'')   --> should use custom_env
and custom_release
> to help determine where the variable is defined in hiera.
>
> Are custom facts from non root users simply not relayed to hiera?
>
> :hierarchy:
>   - nodes/%{::fqdn}
>   - releases/%{custom_release}
>   - env/%{custom_env}
>   - common
>
>
>
> I have put a bandaid fix in for now which sets these variables via top 
> scope assignment in one of my classes and allows me to control everything 
> from hiera instead of using custom facts.  However, I am not sure if this 
> follows good puppet coding practices when using hiera, since I am using 
> hiera to feed hiera.  I don''t want to have to define these
variables for
> every node.
>
> bandaid fix:
> # this is a top scope variable that is currently a hack to fix an unknown 
> bug with hiera and local puppet facts
> $custom_env = hiera(''custom_env'')  --> defined under
nodes/nodename
> $custom_release = hiera(''custom_release'')   -->
defined under
> nodes/nodename
> class roles::specialapp(
>
>   )
>
> {
>     include specialapp_profile
>
> }
>
>
> If this is a new bug, I''ll be happen to file a ticket.
>
> Thanks,
>
> Corey Osman
> corey@logicminds.biz
>
>
>
>
>
>
>  
>
-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.