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+unsubscr...@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.
