Puppet users - Feb 2012 - Multiple runs needed to update configs?

Hey folks,

I''ve got a fairly basic out-of-the-box puppetmaster/puppet setup (out
of the box on Ubuntu, that is), but am running into a bit of an odd
problem with updating clients.

The first time a host runs Puppet, and every time I change anything in
the configs on the server, the agent has to run once and abort for
each included class (module, thing..) on the machine I''m trying to
configure before it finally just works after ''n'' tries and
everything
works fine.

I''ve tried to Google this, asked some colleagues with Puppet smarts,
and not come up with any useful hints. Anyone got any idea what''s
going on here? See below for a sample run of (multiple) attempts.

Cheers,
Mike

# puppet agent --test
err: Could not retrieve catalog from remote server: Error 400 on
SERVER: Could not find class unix for hostname.uffish.net at
/etc/puppet/manifests/templates.pp:2 on node hostname.uffish.net
warning: Not using cache on failed catalog
err: Could not retrieve catalog; skipping run
# puppet agent --test
err: Could not retrieve catalog from remote server: Error 400 on
SERVER: Could not find class users for hostname.uffish.net at
/etc/puppet/manifests/templates.pp:3 on node hostname.uffish.net
warning: Not using cache on failed catalog
err: Could not retrieve catalog; skipping run
# puppet agent --test
err: Could not retrieve catalog from remote server: Error 400 on
SERVER: Could not find class ntp for hostname.uffish.net at
/etc/puppet/manifests/templates.pp:8 on node hostname.uffish.net
warning: Not using cache on failed catalog
err: Could not retrieve catalog; skipping run
# puppet agent --test
err: Could not retrieve catalog from remote server: Error 400 on
SERVER: Could not find class bind for hostname.uffish.net at
/etc/puppet/manifests/templates.pp:9 on node hostname.uffish.net
warning: Not using cache on failed catalog
err: Could not retrieve catalog; skipping run
# puppet agent --test
err: Could not retrieve catalog from remote server: Error 400 on
SERVER: Could not find class squid for hostname.uffish.net at
/etc/puppet/manifests/templates.pp:24 on node hostname.uffish.net
warning: Not using cache on failed catalog
err: Could not retrieve catalog; skipping run
# puppet agent --test
info: Caching catalog for hostname.uffish.net
(from here on in, runs normally)

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

On 25.2.2012 20:11, Mike Knell wrote:
> The first time a host runs Puppet, and every time I change anything in
> the configs on the server, the agent has to run once and abort for
> each included class (module, thing..) on the machine I''m trying to
> configure before it finally just works after ''n'' tries
and everything
> works fine.
Could it be the filetimeout?

$ puppet agent --genconfig
...
# The minimum time to wait (in seconds) between checking for updates in
# configuration files.  This timeout determines how quickly Puppet
checks whether
# a file (such as manifests or templates) has changed on disk.
# The default value is ''15''.
# filetimeout = 15
...

-- 
Kind Regards, Markus Falb

Hi Markus,

I''m pretty new, too, I struggled with the same error just today.
Here''s how I resolved it.

The error message ''Could not find class'' sometimes occurs when
puppet
doesn''t like the contents of the class.

Start with the simplest possible class, and see if puppet finds it.
Something like:

-- snip --
class mydir {
 # create /etc/mydir
  file { "/etc/mydir":
    ensure => directory,
  }
}
-- snip --

Paul


On Feb 25, 12:30 pm, Markus Falb <markus.f...@fasel.at>
wrote:
> On 25.2.2012 20:11, Mike Knell wrote:
>
> > The first time a host runs Puppet, and every time I change anything in
> > the configs on the server, the agent has to run once and abort for
> > each included class (module, thing..) on the machine I''m
trying to
> > configure before it finally just works after ''n''
tries and everything
> > works fine.
>
> Could it be the filetimeout?
>
> $ puppet agent --genconfig
> ...
> # The minimum time to wait (in seconds) between checking for updates in
> # configuration files.  This timeout determines how quickly Puppet
> checks whether
> # a file (such as manifests or templates) has changed on disk.
> # The default value is ''15''.
> # filetimeout = 15
> ...
>
> --
> Kind Regards, Markus Falb
>
>  signature.asc
> < 1KViewDownload
-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Mon, Feb 27, 2012 at 1:51 AM, paulS <pstivers3@gmail.com>
wrote:
> Hi Markus,
>
> I''m pretty new, too, I struggled with the same error just today.
> Here''s how I resolved it.
>
> The error message ''Could not find class'' sometimes occurs
when puppet
> doesn''t like the contents of the class.
The difference for me is that after multiple runs (one for each
class), Puppet just decides the config''s good to go and runs it. I
don''t think it''s got anything to do with the syntax of the
code - it
behaves the same even for very basic configurations. Server''s 2.7.1,
clients have been a mixture of versions and platforms, so it''s got to
be something server-side, I think.

m.

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

A colleague of mine had a similar issue. When he ran it, the first time it 
failed and the second time it succeeds.
 
We noticed that his init.pp under modules/manifest doesn''t contain a
class.
By adding an empty class, e.g. class xyz { }, solved the issue.

On Saturday, February 25, 2012 2:11:36 PM UTC-5, Mike Knell wrote:
> Hey folks,
>
> I''ve got a fairly basic out-of-the-box puppetmaster/puppet setup
(out
> of the box on Ubuntu, that is), but am running into a bit of an odd
> problem with updating clients.
>
> The first time a host runs Puppet, and every time I change anything in
> the configs on the server, the agent has to run once and abort for
> each included class (module, thing..) on the machine I''m trying to
> configure before it finally just works after ''n'' tries
and everything
> works fine.
>
> I''ve tried to Google this, asked some colleagues with Puppet
smarts,
> and not come up with any useful hints. Anyone got any idea what''s
> going on here? See below for a sample run of (multiple) attempts.
>
> Cheers,
> Mike
>
> # puppet agent --test
> err: Could not retrieve catalog from remote server: Error 400 on
> SERVER: Could not find class unix for hostname.uffish.net at
> /etc/puppet/manifests/templates.pp:2 on node hostname.uffish.net
> warning: Not using cache on failed catalog
> err: Could not retrieve catalog; skipping run
> # puppet agent --test
> err: Could not retrieve catalog from remote server: Error 400 on
> SERVER: Could not find class users for hostname.uffish.net at
> /etc/puppet/manifests/templates.pp:3 on node hostname.uffish.net
> warning: Not using cache on failed catalog
> err: Could not retrieve catalog; skipping run
> # puppet agent --test
> err: Could not retrieve catalog from remote server: Error 400 on
> SERVER: Could not find class ntp for hostname.uffish.net at
> /etc/puppet/manifests/templates.pp:8 on node hostname.uffish.net
> warning: Not using cache on failed catalog
> err: Could not retrieve catalog; skipping run
> # puppet agent --test
> err: Could not retrieve catalog from remote server: Error 400 on
> SERVER: Could not find class bind for hostname.uffish.net at
> /etc/puppet/manifests/templates.pp:9 on node hostname.uffish.net
> warning: Not using cache on failed catalog
> err: Could not retrieve catalog; skipping run
> # puppet agent --test
> err: Could not retrieve catalog from remote server: Error 400 on
> SERVER: Could not find class squid for hostname.uffish.net at
> /etc/puppet/manifests/templates.pp:24 on node hostname.uffish.net
> warning: Not using cache on failed catalog
> err: Could not retrieve catalog; skipping run
> # puppet agent --test
> info: Caching catalog for hostname.uffish.net
> (from here on in, runs normally)
>
>
-- 
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 view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/b453e637-4067-4c0b-903a-907cb75a7973%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

On Saturday, February 25, 2012 1:11:36 PM UTC-6, Mike Knell
wrote:
>
> Hey folks,
>
> I''ve got a fairly basic out-of-the-box puppetmaster/puppet setup
(out
> of the box on Ubuntu, that is), but am running into a bit of an odd
> problem with updating clients.
>
> The first time a host runs Puppet, and every time I change anything in
> the configs on the server, the agent has to run once and abort for
> each included class (module, thing..) on the machine I''m trying to
> configure before it finally just works after ''n'' tries
and everything
> works fine.
>
This is surpassingly strange.  I am inclined to suspect that there is 
something going on on the system hosting your master that is contributing 
to this issue, but it''s hard to guess what that might be.  "Could
not find
class" typically means more or less what it says: in response to a 
declaration of the specified, as-yet unknown class, Puppet (on the master) 
was unable to load the class definition.

For a class "mymodule", Puppet will be looking in file 
<modulepath>/mymodule/manifests/init.pp.  For a class 
"mymodule[::ns_segment ...]::myclass, it will be looking in file 
<modulepath>/mymodule/manifests[/ns_segment ...]/myclass.pp.  Typical 
problems include misnaming of the module''s top-level directory, 
access-control issues preventing the Puppet process from reading the target 
file, and failure to use a fully-qualified name to define the target class 
within the file.

The issue is without a doubt on the master.  It is not a timeout on the 
agent/master channel.  Are the errors truly per-node, or are they perhaps 
only per manifest file?  That is, if you try to sync a second client node, 
does it get its own set of failures for the included classes that already 
failed for the first node?  I''d be very surprised if it did.

I suspect a contributory external (to Puppet) factor in this case because 
none of the typical problems are of the sort that otherwise would be 
expected to resolve by themselves.  Note, too, that my speculative external 
factor is not what causes the classes to fail the first time -- rather, it 
is what causes them to succeed the second and subsequent times.

If you will indulge me in a chain of wild speculation, my best guess is 
that an access-control issue is at the root of the problem, and there is 
some kind of system service running that observes the failures and fixes 
them without operator intervention.  Among all the access control 
mechanisms of which I am aware, SELinux is the most likely to be paired 
with an fully-automated permission fixer (though I''ve not actually
heard of
such a thing, which would make SELinux largely moot).

If I''m right, the root problem would be that the manifest files are
being
installed with an SELinux context that does not permit the master to read 
them.  The first time the master attempts to do so, a monitor detects the 
failure (daemons that do at least that much are available), and modifies 
the target file''s SELinux context to permit the requested access in the
future.  If that manifest is later modifed then a different SELinux context 
may be set on it, depending on the context from which it is modified, that 
again denies access to Puppet.

All that speculation depends on SELinux to be enabled and operating in 
enforcing mode (on the master).  The ''getenforce'' command
should tell you
whether that is the case, or perhaps Ubuntu offers a GUI interface that 
would tell you.  Also, you probably should see messages in your system log 
describing access-control failures and automated corrective actions.  If 
SELinux is running in enforcing mode then you can test whether it is 
contributing to your problem by switching it to permissive mode, either via 
a GUI if available, or via the command "setenforce 0".


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 view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/48e24dba-1dda-4ec7-8af9-116a26fd084a%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.