Error: Could not find class <class> for <host> on node <host>

[joe]

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

[jcbollinger]

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

[jcbollinger]

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