Problem loading custom modules
Jonathan Gazeley
I'm a puppet newbie, so please bear with me. I've installed puppetmaster
on a CentOS box, and I have another CentOS box running as a test client
while I get to grips.
I installed puppetmaster from the EPEL repository.
I've added some content to site.pp and nodes.pp (in
/etc/puppet/manifests) and these show up on my test client and do
uninteresting things like set permissions on /etc/passwd.
In my puppet.conf I added "modulepath = /etc/puppet/modules". This
appears correctly when I run puppet --printconfig modulepath
I created the tree /etc/puppet/modules/ntp/manifests/ and created an
init.pp with this content:
class ntp {
package { "ntp": ensure => installed }
service { "ntpd": ensure => stopped }
}
I "include"d my ntp class in the client's node declaration. When running
puppet on the client, no errors are thrown but it is not able to import
the ntp module.
Have I missed something? Can anyone point out an obvious mistake?
Many thanks,
Jonathan
----------------------------
Jonathan Gazeley
Systems Support Specialist
ResNet | Wireless & VPN Team
IT Services
University of Bristol
----------------------------
luke.bigum
> init.pp with this content:
>
> class ntp {
> package { "ntp": ensure => installed }
> service { "ntpd": ensure => stopped }
>
> }
How do you know the client isn't doing what you told it if there are
no error messages? What classes are on your client? Run this for a
list:
cat /var/lib/puppet/classes.txt
A more comprehensive check is to list all the resources that can
execute on your client with:
puppetd --test --noop --evaltrace
Does the ntp stuff appear in that list? If it does then you've
probably got the ntp package already installed and the ntp service
already stopped, so Puppet doesn't have to do anything :)
Jonathan Gazeley
>> I created the tree /etc/puppet/modules/ntp/manifests/ and created an
>> init.pp with this content:
>>
>> class ntp {
>> package { "ntp": ensure => installed }
>> service { "ntpd": ensure => stopped }
>>
>> }
>
> Hi Jonathan,
>
> How do you know the client isn't doing what you told it if there are
> no error messages? What classes are on your client? Run this for a
> list:
>
> cat /var/lib/puppet/classes.txt
>
> A more comprehensive check is to list all the resources that can
> execute on your client with:
>
> puppetd --test --noop --evaltrace
>
> Does the ntp stuff appear in that list? If it does then you've
> probably got the ntp package already installed and the ntp service
> already stopped, so Puppet doesn't have to do anything :)
>
Thanks for your response. Sorry, I realised I made a mistake in my
message. There *was* an error message, as follows:
# /usr/sbin/puppetd --server puppet.resnet.bris.ac.uk --test --evaltrace
err: Could not retrieve catalog from remote server: Error 400 on SERVER:
Could not parse for environment production: No file(s) found for import
of 'ntp' at /etc/puppet/manifests/site.pp:6
warning: Not using cache on failed catalog
err: Could not retrieve catalog; skipping run
To reiterate, my 'ntp' class is defined in
/etc/puppet/modules/ntp/manifests/init.pp and I have defined modulepath
in my puppet.conf. The ntp module is imported in site.pp and included in
nodes.pp.
So it looks like my puppetmaster isn't correctly picking up my
modulepath. Any ideas?
Also, is there a way to get more verbose logging on the puppetmaster?
Currently I only have masterhttp.log, but I would like to enable debug
logging to see everything the puppetmaster is doing.
Felix Frank
> /etc/puppet/modules/ntp/manifests/init.pp and I have defined modulepath
> in my puppet.conf. The ntp module is imported in site.pp and included in
> nodes.pp.
Are the permissions adequate for your puppetmaster process?
> So it looks like my puppetmaster isn't correctly picking up my
> modulepath. Any ideas?
Are you pasting those paths and settings? Some typos tend to evade the
eye after just so many hours; you may want to paste excerpts from your
manifest, configs and filesystem listings somehwere.
> Also, is there a way to get more verbose logging on the puppetmaster?
> Currently I only have masterhttp.log, but I would like to enable debug
> logging to see everything the puppetmaster is doing.
I like to do this on occasion:
$ puppet master --masterport 8141 --no-daemonize --debug --verbose
--color false --pidfile=/var/run/puppet/master.debug.pid
That way, you get a second puppetmaster on another port, and can query
it from your clients using
$ puppetd --test --noop --masterport 8141
HTH,
Felix
Jonathan Gazeley
>> To reiterate, my 'ntp' class is defined in
>> /etc/puppet/modules/ntp/manifests/init.pp and I have defined modulepath
>> in my puppet.conf. The ntp module is imported in site.pp and included in
>> nodes.pp.
>
> Are the permissions adequate for your puppetmaster process?
Thanks for your reply. The tree "/etc/puppet/modules" has been chowned
and chmodded to be the same as the other things in /etc/puppet. SELinux
is disabled.
>
>> So it looks like my puppetmaster isn't correctly picking up my
>> modulepath. Any ideas?
>
> Are you pasting those paths and settings? Some typos tend to evade the
> eye after just so many hours; you may want to paste excerpts from your
> manifest, configs and filesystem listings somehwere.
I have pasted these excerpts for verification. The "modulepath"
directive is in puppet.conf as follows. Which subsection should it be in
- main, puppetd or puppetmasterd? Currently it's in all three, just to
be sure.
modulepath = /etc/puppet/modules
In site.pp:
import "nodes"
import "ntp"
In nodes.pp:
node 'espresso.resnet.bris.ac.uk' {
include ntp
}
>
>> Also, is there a way to get more verbose logging on the puppetmaster?
>> Currently I only have masterhttp.log, but I would like to enable debug
>> logging to see everything the puppetmaster is doing.
>
> I like to do this on occasion:
> $ puppet master --masterport 8141 --no-daemonize --debug --verbose
> --color false --pidfile=/var/run/puppet/master.debug.pid
>
> That way, you get a second puppetmaster on another port, and can query
> it from your clients using
> $ puppetd --test --noop --masterport 8141
Thank you, that's an excellent idea.
>
> HTH,
> Felix
>
Cheers,
Jonathan
--
Felix Frank
> include ntp
> }
To get anything going, try to rename class ntp to ntp::ntp and include
it as that. You can strip down to more straight-forward naming once that
works.
BTW, I don't see how your 'import "nodes"' ever worked. But apparently
it does.
Jonathan Gazeley
>> node 'espresso.resnet.bris.ac.uk' {
>> include ntp
>> }
>
> To get anything going, try to rename class ntp to ntp::ntp and include
> it as that. You can strip down to more straight-forward naming once that
> works.
Hmm, no luck using ntp::ntp instead of ntp. The problem seems to be in
importing rather than including. I tried using ntp, ntp::ntp, and the
full path /etc/puppet/modules/ntp/manifests/init.pp.
It always fails with:
err: Could not retrieve catalog from remote server: Error 400 on SERVER:
Could not parse for environment production: No file(s) found for import
of 'ntp' at /etc/puppet/manifests/site.pp:6
It's as if it can't figure out the module path, which I have specified
in the [main] section of my puppet.conf. I have triple-checked that
there is no typo, and that the permissions are OK.
>
> BTW, I don't see how your 'import "nodes"' ever worked. But apparently
> it does.
>
I don't know where I got that from - it was either in the default
configuration from the EPEL repository, or I saw it on a mailing list /
forum. It seems to work because nodes.pp is in the same dir as site.pp.
Thanks,
luke.bigum
> importing rather than including. I tried using ntp, ntp::ntp, and the
> full path /etc/puppet/modules/ntp/manifests/init.pp.
>
> It always fails with:
>
> err: Could not retrieve catalog from remote server: Error 400 on SERVER:
> Could not parse for environment production: No file(s) found for import
> of 'ntp' at /etc/puppet/manifests/site.pp:6
You shouldn't need to "import" your ntp module as Puppet should auto
load it if the pathing is all correct, which it looks like it is.
Remote the 'import "ntp"' line from your site.pp:
In site.pp:
import "nodes.pp"
Then run the evaltrace on your node to see if your module and
resources are there. Like Felix, an import of "nodes" seems is strange
to me - maybe Puppet will implicitly add a .pp extension for files in
the CWD? You should not need to explicitly import your module
manifests, using include and Puppet with a correct modulepath should
find it.
-Luke
Jonathan Gazeley
>
> Hi Jonathan,
>
> You shouldn't need to "import" your ntp module as Puppet should auto
> load it if the pathing is all correct, which it looks like it is.
OK, good to know.
> Remote the 'import "ntp"' line from your site.pp:
I've removed this line.
>
> In site.pp:
>
> import "nodes.pp"
Got that.
>
> In nodes.pp:
>
> node 'espresso.resnet.bris.ac.uk' {
> include ntp
> }
Got that too.
Unfortunately puppetmaster can't find the ntp class. Running the
puppetmasterd in debug mode, it prints this:
err: Could not find class ntp at /etc/puppet/manifests/nodes.pp:3 on
node espresso.resnet.bris.ac.uk
Line 3 in nodes.pp is the "include ntp" line.
So it still seems as if the modulepath declaration isn't work properly.
Puppet doesn't print any debug messages at startup about bad permissions
etc, and I've verified that the path is typed correctly.
Can I confirm that the modulepath declaration should be in the [main]
section of puppet.conf? I've it in all sections without luck, though.
Thanks for your help,
Jonathan
>
> Then run the evaltrace on your node to see if your module and
> resources are there. Like Felix, an import of "nodes" seems is strange
> to me - maybe Puppet will implicitly add a .pp extension for files in
> the CWD? You should not need to explicitly import your module
> manifests, using include and Puppet with a correct modulepath should
> find it.
>
> -Luke
>
Felix Frank
Hauling out the big guns boils down to (for me):
strace -e trace=file -f puppet master --no-daemonize ... 2>&1 | grep ntp
That should eventually spit a few stat or open attempts that fail, when
the master tries to import the ntp module.
Otherwise, grep for modules instead, and see where the master is
actually looking.
HTH,
Felix
Jonathan Gazeley
> Hauling out the big guns boils down to (for me):
>
> strace -e trace=file -f puppet master --no-daemonize ... 2>&1 | grep ntp
>
> That should eventually spit a few stat or open attempts that fail, when
> the master tries to import the ntp module.
Thank you. Using strace shows that while the permissions were set
correctly on my /etc/puppet/modules tree, the directories didn't have
the "X" flag to allow browsing.
Slightly embarrassing, but thank you both for you help on this on. A
quick chmod +X and suddenly it's all working perfectly.
Cheers,
Jonathan
Felix Frank
> On 10/01/11 16:20, Felix Frank wrote:
>> Hauling out the big guns boils down to (for me):
>>
>> strace -e trace=file -f puppet master --no-daemonize ... 2>&1 | grep ntp
>>
>> That should eventually spit a few stat or open attempts that fail, when
>> the master tries to import the ntp module.
>
> Thank you. Using strace shows that while the permissions were set
> correctly on my /etc/puppet/modules tree, the directories didn't have
> the "X" flag to allow browsing.
I find your understanding of "set correctly" disturbing ;p
That's why I originally asked for pastes of configs, manifests *and*
filesystem listings (not to the list preferably, use pastebin services).
But it worked out, you just had to do a bit more walking.
Cheers,
Felix
Jonathan Gazeley
> On 01/10/2011 05:30 PM, Jonathan Gazeley wrote:
>> On 10/01/11 16:20, Felix Frank wrote:
>>> Hauling out the big guns boils down to (for me):
>>>
>>> strace -e trace=file -f puppet master --no-daemonize ... 2>&1 | grep ntp
>>>
>>> That should eventually spit a few stat or open attempts that fail, when
>>> the master tries to import the ntp module.
>>
>> Thank you. Using strace shows that while the permissions were set
>> correctly on my /etc/puppet/modules tree, the directories didn't have
>> the "X" flag to allow browsing.
>
> I find your understanding of "set correctly" disturbing ;p
Heh. The w and r flags and ownership were OK! Usually on my system
directories are browseable by default, so I'm not sure why they weren't
in this case.
>
> That's why I originally asked for pastes of configs, manifests *and*
> filesystem listings (not to the list preferably, use pastebin services).
OK, I will bear this in mind. While I'm new to Puppet, I've administered
FreeRADIUS and been on their mailing list for years. Over there, they're
very anti-pastebin, and prefer entire configs and debug logs (up to
1000+ lines) sent straight to the list as plaintext in the body of the
message.
>
> But it worked out, you just had to do a bit more walking.
Indeed. Thanks for your help, and have a nice day!
>
> Cheers,
> Felix
Thomas Bellman
> That's why I originally asked for pastes of configs, manifests *and*
> filesystem listings (not to the list preferably, use pastebin services).
I strongly disagree! Having things on a website instead of in
the actual mail I'm reading and possibly responding to sucks.
It's one more step I have to do to actually look at the code
or whatever is causing the problem, it distrupts the flow of
reading and understanding the mail, and I have to be able to
actually access the website at the moment I'm reading the
mail.
So please *do* post such things directly to the list.
/Bellman
Daniel Pittman
> Felix Frank wrote:
>
>> That's why I originally asked for pastes of configs, manifests *and*
>> filesystem listings (not to the list preferably, use pastebin services).
>
> I strongly disagree! Having things on a website instead of in
> the actual mail I'm reading and possibly responding to sucks.
> It's one more step I have to do to actually look at the code
> or whatever is causing the problem, it distrupts the flow of
> reading and understanding the mail, and I have to be able to
> actually access the website at the moment I'm reading the
> mail.
The biggest problem I have with it is the websites expire much faster
than email does, so this information often gets lost later. In any
case, generally we at Puppet Labs encourage people to post these
details to the list for ease of developer interaction – and because
you folks out there in the community are so good at spotting the
problems from them!
If your data is really huge, to the point that it isn't reasonable, we
are happy to work without, but would usually ask for excerpts first –
we don't want to download a gigabyte for a one line issue either. :)
Regards,
Daniel
--
✉ Daniel Pittman <dan...@rimspace.net>
⌨ dan...@rimspace.net (XMPP)
☎ +1 503 893 2285
♻ made with 100 percent post-consumer electrons