Puppet agent not correcly configuring facts synch'd from master

Bug #1076286 reported by Andrea Biancini
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
puppet (Ubuntu)
New
Medium
Unassigned

Bug Description

Hi all,
I'm writing to signal a very easy to fix potential problem to your puppet package.
The package for the agent, as provided, does not permit to facts defined on the master to be correctly deployed and used on the agent side.

To reproduce the error, for example, I could define in the master a site.pp as follow:
node puppetclient {
  include modulewithfact

  file { '/tmp/puppettest':
    ensure => present,
    content => $test_fact,
  }
}
And a module, under modules/modulewithfact, that has under the lib/facter a file test_fact.rb as follows:
Facter.add(:test_fact) do
  confine :kernel => "Linux"
  setcode do
        "Content from the fact"
  end
end
Given this configuration the expected behavior should be that the fact is deployed on every agent (of course if they enable pluginsync=true in the puppet.conf) and then properly executed.
So the file /tmp/puppettest should contain the string "Content from the fact".

This is not happening, with the default configuration, because the agent is not instructed to include in the facterlib path all the facts synchronized from the server.
To avoid this situation I simply added to the /etc/default/puppet file the following line:
FACTERLIB=/var/lib/puppet/lib/facter
which permits to include in the facterlib the folder where facts from the server are synchronized by the agent.

I am writing to propose you to add this line in the standard /etc/defatult/puppet file in the puppet package from further versions.
I hope my example and explaination is clear enough.

Thanks and regards,
Andrea

Revision history for this message
Stig Sandbeck Mathisen (ssm) wrote : Re: [Bug 1076286] [NEW] Puppet agent not correcly configuring facts synch'd from master

Hello, and thanks for reporting an issue with puppet.

Andrea Biancini <email address hidden> writes:

> To reproduce the error, for example, I could define in the master a site.pp as follow:
> node puppetclient {
> include modulewithfact
> }

You do not need a manifest in order to check if facts propagate from
master to nodes. Factsync takes place before the manifest is compiled.

1: Set pluginsync=true in /etc/puppet/puppet.conf on the node

2: Run "puppet agent --test --noop" on the node

3: If you have authenticated the node to the master, you should see the
   fact being transmitted.

4: Verify by:

   run "facter --puppet" on the node. Do you see your fact?

   check /var/lib/puppet/yaml/facts/<node>.yaml on the master, do you
   see the new fact there?

What is your puppet version, your facter version, and your ubuntu
version?

> To avoid this situation I simply added to the /etc/default/puppet file
> the following line:
> FACTERLIB=/var/lib/puppet/lib/facter
> which permits to include in the facterlib the folder where facts from
> the server are synchronized by the agent.

I don't think this is the correct fix. This will not have any effect if
you run "puppet agent --test" on the command line.

--
Stig Sandbeck Mathisen

Revision history for this message
Andrea Biancini (andrea-biancini) wrote :

Hi, yes I know it is not needed to have a manifest file to propagate the fact to the node.
In fact the facter gets propagated and is available on the node machine, however whey I try to recall it from a manifest, the fact simply is not evaluated.

I try to better describe the problem by answering your questions and adding some informations.
Following your procedure:
1: already done
2: done
3: yes the fact is properly transmitted
4: I can correctly see the fact running "facter --puppet" on the node

I am using:
Ubuntu 12.04.1 LTS
puppet 2.7.11-ubuntu2.1
facter 1.6.5-1ubuntu2.1

However, for the use I would like to achieve with puppet, the fact the the command facter --puppet works correctly is not satisfactory.
In fact I would like the node to synchronize with the agent using the puppet daemon launched with
service puppet start.

In this case the facter on the node do not gets evaluated correctly.
To solve this problem I found that putting a value for the FACTERLIB including the folder where the facts are deployed from the master to the nodes, I would solve the error.
So I added this directive in the /etc/default/puppet file which is sourced in the /etc/init.d/puppet init script.

I hope you could test and reproduce the problem, using the fact from a manifest.
If you then have a better and more "clean" solution (instead of the one I proposed) I will be glad to accept it.
For the moment on my servers I will leave my modification which is working correctly and without evident problems.

Thanks,
A.

Revision history for this message
Michael Stahnke (stahnma) wrote :

If I understand this report correctly, you're getting the exact experience as designed.

Puppet sources additional directories for facts, (hence facter -p).

If you want standalone facter to source more directories you will always have to modify FACTERLIB. Where/how you choose to do that is up to you.

I would vote against your proposed change as it changes the expected behavior of facter and puppet.

Revision history for this message
Robie Basak (racb) wrote :

> Puppet sources additional directories for facts, (hence facter -p).

If I understand this report correctly, it sounds to me that the problem is that puppet is not sourcing /var/lib/puppet/lib/facter for facts, which is where factsync is writing them. Setting FACTERLIB in /etc/default/puppet is a workaround for the daemon, but will not work when calling "puppet agent --test" from the commandline, which should work too (but presumably doesn't).

Is this an accurate interpretation? Have I understood your description wrong? What is upstream's behaviour here?

Changed in puppet (Ubuntu):
importance: Undecided → Medium
Revision history for this message
Andrea Biancini (andrea-biancini) wrote :

Robie, yes the problem is exactly the one you described.
The puppet daemon does not source /var/lib/puppet/lib/facter for facts and my proposed modification is a workaround to have it properly running.
Also the command "puppet agent --test" does not source the facts in /var/lib/puppet/lib/facter and this is not solved by the modification I proposed.

My proposal is a very quick fix to have the daemon properly running.
I thought that when running the puppet command from commandline the user could define FACTERLIB in his environment somehow.
Of course if you can find better solutions, they're very welcome.

Revision history for this message
Robie Basak (racb) wrote :

Thanks Andrea.

I'm not sure about fixing /etc/default/puppet in Ubuntu as in my judgement changing "puppet agent --test" to behave differently from the daemon would be worse for users. For the time being, users can find this bug and the associated workaround.

For a proper fix, the next step is to identify whether this bug is present in the upstream project, introduced in the Debian packaging or introduced in Ubuntu's modifications. If Ubuntu hasn't introduced the problem, we should get a bug filed in the appropriate bug tracker. Are you able to help with this, please?

Revision history for this message
Andrea Biancini (andrea-biancini) wrote :

Robie, I tested it on Debian wheezy and the situation is exactly the same.
I will try and track the problem to signal it at the more appropriate level.

Revision history for this message
Matthaus Owens (matthaus-m) wrote :

I wasn't able to reproduce this on precise. I used the following manifest to test the fact:

node default {
  file { '/tmp/puppettest':
    ensure => present,
    content => $test_fact,
  }
}

I had just the fact example you used in (/etc/puppet/modules/modulewithfact/lib/facter/test_fact.rb)...

Facter.add(:test_fact) do
  confine :kernel => "Linux"
  setcode do
        "Content from the fact"
  end
end

The puppet run was as follows...

puppet agent -t
info: Loading facts in /etc/puppet/modules/modulewithfact/lib/facter/test_fact.rb
info: Caching catalog for precise-64.localdomain
info: Applying configuration version '1353888521'
notice: /Stage[main]//Node[default]/File[/tmp/puppettest]/ensure: created
notice: Finished catalog run in 0.02 seconds

And the content was as expected.

cat /tmp/puppettest
Content from the fact

Revision history for this message
Matthaus Owens (matthaus-m) wrote :

And running it from a remote agent had the correct content as well once "pluginsync=true" was added to the agent's puppet.conf.

Revision history for this message
Robie Basak (racb) wrote : Re: [Bug 1076286] Re: Puppet agent not correcly configuring facts synch'd from master

Matthaus,

Thanks for trying. Did you use a puppetmaster in your test our was it local only? I get the impression that it won't reproduce unless it is the former.

Revision history for this message
Matthaus Owens (matthaus-m) wrote :

So if the problem is that custom facts don't get to agents by default after installing the puppet package, a solution could be to add "pluginsync=true" to the puppet.conf in the package, but that might be surprising to users, depending on what behavior they expect.

Side note: pluginsync defaults to true in Puppet 3.0

Revision history for this message
Matthaus Owens (matthaus-m) wrote :

Robie,
I used a puppetmaster in both cases. In the first example the agent and master were on the same sytem, in the second they were on seperate systems.

Revision history for this message
Andrea Biancini (andrea-biancini) wrote :

On my linux box the fact is synched on the agent (with pluginsync=true attribute) and the fact file is created in the folder /var/lib/puppet/lib/facter (and not in /etc/puppet/modules/modulewithfact/lib/facter/test_fact.rb as by your example).

At this point the puppet daemon is not able to find the fact and so it does not get executed correctly.
I'm curious to know why the problem didn't came up on your servers.....

Revision history for this message
Matthaus Owens (matthaus-m) wrote :

Andrea,

The first example was master and agent on the same machine, so it found the module in the modulepath without pluginsync. The second example was agent and master on different machines.
Can you post the output of your puppet.conf and `puppet agent -t --trace --debug` on the agent? That might help figure out what's going on.

Here is the output from that second run.

# Cleanup
root@lucid-64:~# rm -rf /tmp/puppettest
root@lucid-64:~# rm -rf /var/lib/puppet/lib/

# Puppet Run
root@lucid-64:~# puppet agent -t
info: Retrieving plugin
notice: /File[/var/lib/puppet/lib/facter]/ensure: created
notice: /File[/var/lib/puppet/lib/facter/test_fact.rb]/ensure: defined content as '{md5}fc59074ecb5d02756ee6c2095677bb92'
info: Loading downloaded plugin /var/lib/puppet/lib/facter/test_fact.rb
info: Loading facts in /var/lib/puppet/lib/facter/test_fact.rb
info: Caching catalog for lucid-64.localdomain
info: Applying configuration version '1352931741'
notice: /Stage[main]//Node[default]/File[/tmp/puppettest]/ensure: created
notice: Finished catalog run in 0.03 seconds

# Correct content in file
root@lucid-64:~# cat /tmp/puppettest
Content from the fact

# Correct facter in lib
root@lucid-64:~# find /var/lib/puppet/lib/
/var/lib/puppet/lib/
/var/lib/puppet/lib/facter
/var/lib/puppet/lib/facter/test_fact.rb

Revision history for this message
Andrea Biancini (andrea-biancini) wrote :

Hi Matthaus,
I just re-executed the operations described. I work with master and agent on two different machines.
On the agent machine the /etc/puppet/puppet.conf is as follows:
<<
[main]
logdir=/var/log/puppet
vardir=/var/lib/puppet
ssldir=/var/lib/puppet/ssl
rundir=/var/run/puppet
factpath=$vardir/lib/facter
templatedir=$confdir/templates
prerun_command=/etc/puppet/etckeeper-commit-pre
postrun_command=/etc/puppet/etckeeper-commit-post

[agent]
server=puppet.example.com
report=true
pluginsync=true
runinterval=1800
>>

Now the outputs:
# Cleanup
root@puppetclient:~# rm -Rf /tmp/puppettest
root@puppetclient:~# rm -Rf /var/lib/puppet/lib/

# Puppet Run
root@puppetclient:~# puppet agent -t
info: Retrieving plugin
notice: /File[/var/lib/puppet/lib/puppet]/ensure: removed
notice: /File[/var/lib/puppet/lib/augeas]/ensure: removed
notice: /File[/var/lib/puppet/lib/facter/util]/ensure: removed
notice: /File[/var/lib/puppet/lib/facter/test_date.rb]/ensure: removed
notice: /File[/var/lib/puppet/lib/facter/ldapserver.rb]/ensure: removed
notice: /File[/var/lib/puppet/lib/facter/shib2idp_status.rb]/ensure: removed
notice: /File[/var/lib/puppet/lib/facter/facter_dot_d.rb]/ensure: removed
notice: /File[/var/lib/puppet/lib/facter/root_home.rb]/ensure: removed
notice: /File[/var/lib/puppet/lib/facter/test_fact.rb]/ensure: defined content as '{md5}fc59074ecb5d02756ee6c2095677bb92'
notice: /File[/var/lib/puppet/lib/facter/puppet_vardir.rb]/ensure: removed
notice: /File[/var/lib/puppet/lib/facter/shib2idp_javasecurity.rb]/ensure: removed
notice: /File[/var/lib/puppet/lib/facter/pe_version.rb]/ensure: removed
info: Loading downloaded plugin /var/lib/puppet/lib/facter/test_fact.rb
info: Loading facts in /var/lib/puppet/lib/facter/test_fact.rb
info: Caching catalog for puppetclient.example.com
info: Applying configuration version '1353052499'
notice: /Stage[main]//Node[puppetclient]/File[/tmp/puppettest]/ensure: created
notice: Finished catalog run in 0.14 seconds

# Wrong content in file
root@puppetclient:~# cat /tmp/puppettest
root@puppetclient:~#

# Correct facter in lib
root@puppetclient:~# find /var/lib/puppet/lib/
/var/lib/puppet/lib/
/var/lib/puppet/lib/facter
/var/lib/puppet/lib/facter/test_fact.rb

Revision history for this message
Matthaus Owens (matthaus-m) wrote :

Andrea,
Can you post the output of your puppet run using `puppet agent -t --trace --debug` on the agent? That might help figure out what's going on.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.