Puppet users - Feb 2013 - Error: Could not find class <class> for <host> on node <host>

I''m a first time user that just installed Puppet 3.1.0 over the weekend
and
hit a road block that I can''t seem to get across.  I have a Linux
master
(Mageia 2) and two Windows 7 clients.  I was able to get basic recipes 
working by putting the resources directly in the node definitions.  Now
I''m
trying to move to the next step and start using classes.  I am *not* using 
modules, yet.  From the docs, it appeared that that is Ok.  However, no 
matter what I''ve attempted, the Puppet Master is not able to find the
class
definition.  I started out having my classes in separate .pp files, but
I''m
currently just trying to define them in init.pp.  Here''s my current
simple
example that is failing:

*init.pp*
  class blahwin {
    file { ''harris2.txt'':
      path => ''c:/temp/harris2.txt'',
      ensure => file,
    }
  }

  class blah {
    file { ''harris3.txt'':
      path => ''/tmp/harris3.txt'',
      ensure => file,
    }
  }

*site.pp*
node ''base'' {

}

node ''magic.example.com'' inherits base {
  include blah
}

node ''nfs-desktop'' inherits base {
  include blahwin
}

node ''nfs-desktop.example.com'' inherits nfs-desktop {
  file { ''harris.txt'':
      path => ''c:/temp/harris.txt'',
      ensure => file,
    }
}

Currently, I''m using the inheritance approach since someone on stack 
overflow mentioned it helped having the FQDN node inherit from the host 
name.  For me it made no difference.  I have applied those .pp files. 
 magic.example.com is the puppet master.

Before I added "include blah" to the master node definition, here is
the
output I get when I run the agent on the nfs-desktop:
C:\Program Files (x86)\Puppet Labs\Puppet\bin>puppet agent --test --verbose
Error: Could not retrieve catalog from remote server: Error 400 on SERVER: 
Could not find class blahwin for nfs-desktop.example.com on node 
nfs-desktop.example.com
Warning: Not using cache on failed catalog
Error: Could not retrieve catalog; skipping run

Now that "include blah" is part of the master definition, here is what
I
get when I try to run "sudo puppet apply site.pp" on the master:
[josh@magic] /etc/puppet/manifests > puppet apply site.pp
NOTE: Gem.latest_load_paths is deprecated with no replacement. It will be 
removed on or after 2011-10-01.
Gem.latest_load_paths called from 
/usr/lib/ruby/site_ruby/1.8/puppet/util/rubygems.rb:54
.
Error: Could not find class blah for magic.example.com on node 
magic.example.com
Error: Could not find class blah for magic.example.com on node 
magic.example.com


So even attempting to use the class on the master is problematic.  At one 
point I did have the classes in unique .pp files, but moved them into 
init.pp after hitting this very error.  Any help is appreciated.


-- 
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.

The simple answer is to put

include manifests/*.pp

in your site.pp, but real answer to follow the module convention: 

http://docs.puppetlabs.com/puppet/2.7/reference/modules_fundamentals.html

-- 
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, February 11, 2013 9:24:14 AM UTC-6, Josh D
wrote:
>
> I''m a first time user that just installed Puppet 3.1.0 over the
weekend
> and hit a road block that I can''t seem to get across.  I have a
Linux
> master (Mageia 2) and two Windows 7 clients.  I was able to get basic 
> recipes working by putting the resources directly in the node definitions. 
>  Now I''m trying to move to the next step and start using classes. 
I am
> *not* using modules, yet.


There is no reason to defer using modules.  Indeed, not doing so is part of 
your problem.

 
>  From the docs, it appeared that that is Ok.


You can use Puppet without modules, but in some ways it''s actually
harder.

 
>  However, no matter what I''ve attempted, the Puppet Master is not
able to
> find the class definition.  I started out having my classes in separate .pp
> files, but I''m currently just trying to define them in init.pp.


The file name "init.pp" is special only for modules.  A file
"init.pp" in
your main manifests/ directory is not special in any way.  Puppet will not 
see anything you put there unless you use the ''import''
function in your
site.pp (which *is* special) to instruct Puppet to parse its contents.  But 
don''t do that, please.  Even if you''re not going to split your
code into
multiple modules, you owe it to yourself to at least create and use *one*, 
in which you can put all your classes.

 
>  Here''s my current simple example that is failing:
>
> *init.pp*
>   class blahwin {
>     file { ''harris2.txt'':
>       path => ''c:/temp/harris2.txt'',
>       ensure => file,
>     }
>   }
>
>   class blah {
>     file { ''harris3.txt'':
>       path => ''/tmp/harris3.txt'',
>       ensure => file,
>     }
>   }
>
>
One way you could make a module out of that would be to create a directory 
modules/site/manifests/ (where the modules/ directory is a sibling of your 
main manifests/ directory), and in it to create these files:

blahwin.pp:
----------
class site::blahwin {
  file { ''harris2.txt'':
    path => ''c:/temp/harris2.txt'',
    ensure => file,
  }
}

blah.pp:
--------
class site::blah {
  file { ''harris3.txt'':
    path => ''c:/temp/harris3.txt'',
    ensure => file,
  }
}


Then
 
> *site.pp*
> node ''base'' {
>
> }
>
> node ''magic.example.com'' inherits base {
>   include blah
>

That becomes "include ''site::blah''".

 
> }
>
> node ''nfs-desktop'' inherits base {
>   include blahwin
>

And that becomes "include ''site::blahwin''".

Voila, you''re using modules.

 
> }
>
> node ''nfs-desktop.example.com'' inherits nfs-desktop {
>   file { ''harris.txt'':
>       path => ''c:/temp/harris.txt'',
>       ensure => file,
>     }
> }
>
>  
> Currently, I''m using the inheritance approach since someone on
stack
> overflow mentioned it helped having the FQDN node inherit from the host 
> name.  For me it made no difference.  I have applied those .pp files.  
> magic.example.com is the puppet master.
>

Your problem was not related to node inheritance, which you should not use 
without understanding why you are doing so.  Some would say you
shouldn''t
use it at all, though I am not among those myself.

 
>
> Before I added "include blah" to the master node definition, here
is the
> output I get when I run the agent on the nfs-desktop:
> C:\Program Files (x86)\Puppet Labs\Puppet\bin>puppet agent --test
--verbose
> Error: Could not retrieve catalog from remote server: Error 400 on SERVER: 
> Could not find class blahwin for nfs-desktop.example.com on node 
> nfs-desktop.example.com
> Warning: Not using cache on failed catalog
> Error: Could not retrieve catalog; skipping run
>

Yes.  Puppet is telling you that it doesn''t know where to find the 
definition of class blahwin (refer to my earlier comments about
"init.pp"
in your main manifests directory not being special).  One of the more 
important things that modules give you is a way to lay out your manifest 
files so that Puppet will find the classes you create without you 
explicitly telling it where to look.  My comments above may serve as an 
introduction to that, but you should really read the docs at 
http://docs.puppetlabs.com/puppet/3/reference/modules_fundamentals.html.

 
>
> Now that "include blah" is part of the master definition, here is
what I
> get when I try to run "sudo puppet apply site.pp" on the master:
> [josh@magic] /etc/puppet/manifests > puppet apply site.pp
> NOTE: Gem.latest_load_paths is deprecated with no replacement. It will be 
> removed on or after 2011-10-01.
> Gem.latest_load_paths called from 
> /usr/lib/ruby/site_ruby/1.8/puppet/util/rubygems.rb:54
> .
> Error: Could not find class blah for magic.example.com on node 
> magic.example.com
> Error: Could not find class blah for magic.example.com on node 
> magic.example.com
>
>
The problem is the same, but you should not do that.  If you want the 
master to manage itself, then do so via the agent (i.e. run the agent on 
the system that is also running the master).


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.

On Monday, February 11, 2013 1:46:30 PM UTC-6, joe
wrote:
>
> The simple answer is to put
>
> include manifests/*.pp
>
> in your site.pp
>
You misspelled ''import''.  As we apparently agree, however,
that''s a
suboptimal solution.


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.