Puppet users - Jun 2010 - Unable to use custom type loaded from module

I found myself unable to load/use a custom type I''ve been working on.
To minimize the variables, I copy-n-pasted the "File" example from the
documentation link below, just changing the name from "file" to
"haddock" to avoid conflicting with the real File type.

   
http://projects.puppetlabs.com/projects/puppet/wiki/Development_Complete_Resource_Example

I''ve installed the type and provider here:

    modules/custom/lib/puppet/type/haddock/haddock.rb
    modules/custom/lib/puppet/provider/haddock/haddock.rb

When I run the client, I see log messages indicating the files have
sync''d across, and I can see the files here:

    /var/lib/puppet/lib/puppet/provider/haddock/haddock.rb
    /var/lib/puppet/lib/puppet/type/haddock/haddock.rb

Yet if I add a resource using this type to the client:

    haddock { "/tmp/haddock": ensure => exists }

The server returns this error on the next run:

    Could not find resource type haddock at
/etc/puppet/dev/manifests/nodes.pp:489 on node puppeteer

My puppet.conf is pasted below.  Note that my client is running in the
"development" environment.

Any ideas what I might be doing wrong?

-Ben





[main]
logdir=/var/log/puppet
vardir=/var/lib/puppet
ssldir=/var/lib/puppet/ssl
rundir=/var/run/puppet
factpath=$vardir/lib/facter
pluginsync=true
environments = production,development,bootstrap

[puppetmasterd]
templatedir=/etc/puppet/templates
modulepath=/etc/puppet/modules

[bootstrap]
modulepath =
/etc/puppet/bootstrap/modules:/etc/puppet/prod/modules:/etc/puppet/prod/services
manifest = /etc/puppet/bootstrap/site.pp

[development]
manifest = /etc/puppet/dev/manifests/site.pp
modulepath = /etc/puppet/dev/modules:/etc/puppet/dev/services

[production]
manifest = /etc/puppet/prod/manifests/site.pp
modulepath = /etc/puppet/prod/modules:/etc/puppet/prod/services

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

Ben Beuchler <insyte@gmail.com> writes:
> I found myself unable to load/use a custom type I''ve been working
on.  To
> minimize the variables, I copy-n-pasted the "File" example from
the
> documentation link below, just changing the name from "file" to
"haddock" to
> avoid conflicting with the real File type.
[...]
> My puppet.conf is pasted below.  Note that my client is running in the
> "development" environment.  Any ideas what I might be doing
wrong?
You didn''t read the bit (which, IIRC, isn''t all that obvious)
that explains
that custom types and plugins don''t play very nicely with environments;
you
are going to get the production stuff, not development stuff.

I think the developers just committed a fix for that to a branch, ready for
testing, so you might want to troll the BTS and see about testing it in your
use case though. :)

        Daniel
-- 
✣ Daniel Pittman            ✉ daniel@rimspace.net            ☎ +61 401 155 707
               ♽ made with 100 percent post-consumer electrons

-- 
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 Fri, Jun 11, 2010 at 7:59 PM, Daniel Pittman <daniel@rimspace.net>
wrote:
> Ben Beuchler <insyte@gmail.com> writes:
>
>> I found myself unable to load/use a custom type I''ve been
working on.  To
>> minimize the variables, I copy-n-pasted the "File" example
from the
>> documentation link below, just changing the name from "file"
to "haddock" to
>> avoid conflicting with the real File type.
>
> [...]
>
>> My puppet.conf is pasted below.  Note that my client is running in the
>> "development" environment.  Any ideas what I might be doing
wrong?
>
> You didn''t read the bit (which, IIRC, isn''t all that
obvious) that explains
> that custom types and plugins don''t play very nicely with
environments; you
> are going to get the production stuff, not development stuff.
>
> I think the developers just committed a fix for that to a branch, ready for
> testing, so you might want to troll the BTS and see about testing it in
your
> use case though. :)
>
>        Daniel
> --
> ✣ Daniel Pittman            ✉ daniel@rimspace.net            ☎ +61 401 155
707
>               ♽ made with 100 percent post-consumer electrons
>
> --
> 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.
>
>
There are a bunch of workarounds for this though.

A lot of the time you can get away with just a shell provider and type
for manifest validation, as the client will get the right one synced
down for use in actual resource application.

I mean it''s frustrating, but it''s not impossible. I have
enough of the
types in my puppetmaster libdir to allow manifests to compile. It does
mean you have to be careful when adding/removing parameters to your
type though.

-- 
nigel

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

> You didn''t read the bit (which, IIRC, isn''t all that
obvious) that explains
> that custom types and plugins don''t play very nicely with
environments;
Yep.  I missed that.
> I think the developers just committed a fix for that to a branch, ready for
> testing, so you might want to troll the BTS and see about testing it in
your
> use case though. :)
Is this the one you mean?

http://projects.reductivelabs.com/issues/3791

-- 
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 lot of the time you can get away with just a shell provider and type
> for manifest validation, as the client will get the right one synced
> down for use in actual resource application.
Is an appropriately named but empty type/provider in the default
environment adequate to fool puppetmaster?  Or is there some minimum
functionality that needs to be included?

Thanks!

-Ben

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

Am 12.06.2010 08:56, schrieb Ben Beuchler:
>> A lot of the time you can get away with just a shell provider and type
>> for manifest validation, as the client will get the right one synced
>> down for use in actual resource application.
>
> Is an appropriately named but empty type/provider in the default
> environment adequate to fool puppetmaster?  Or is there some minimum
> functionality that needs to be included?
You need the proper params and properties, so the manifest validates. If 
you have additional validation rules and want to have them checked on 
the master, you need those too.


Best Regards, David
-- 
dasz.at OG              Tel: +43 (0)664 2602670     Web: http://dasz.at
Klosterneuburg                                         UID: ATU64260999

        FB-Nr.: FN 309285 g          FB-Gericht: LG Korneuburg

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

> There are a bunch of workarounds for this though.
>
> A lot of the time you can get away with just a shell provider and type
> for manifest validation, as the client will get the right one synced
> down for use in actual resource application.
I thought I understood what you were suggesting, but apparently not.
The default environment is "production" on my system, so I replicated
my custom type in the "custom" module in the production environment.
Still received the same error.  I removed it completely from the
"development" environment and switched the client to production.  Same
"Could not find resource type blah" error.

A quick look in $libdir (/var/lib/puppet/lib) shows my custom types are there.

The type in question and my puppet config:

http://pastebin.ws/6t422

I''m quite perplexed.

-Ben

-- 
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, Jun 14, 2010 at 2:36 PM, Ben Beuchler <insyte@gmail.com>
wrote:
>> There are a bunch of workarounds for this though.
>>
>> A lot of the time you can get away with just a shell provider and type
>> for manifest validation, as the client will get the right one synced
>> down for use in actual resource application.
>
> I thought I understood what you were suggesting, but apparently not.
> The default environment is "production" on my system, so I
replicated
> my custom type in the "custom" module in the production
environment.
> Still received the same error.  I removed it completely from the
> "development" environment and switched the client to production.
 Same
> "Could not find resource type blah" error.
>
> A quick look in $libdir (/var/lib/puppet/lib) shows my custom types are
there.
>
> The type in question and my puppet config:
>
> http://pastebin.ws/6t422
>
> I''m quite perplexed.

Sorry, I wasn''t quite clear. You need to make this accessible to the
libdir on the *server*.

So whatever your puppetmasterd libdir is, you need to somehow ensure
the types/providers are there. We do it with symlinks.


-- 
nigel

-- 
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 2010-06-15 01:21, Nigel Kersten wrote:
> Sorry, I wasn''t quite clear. You need to make this accessible to
the
> libdir on the *server*.
>
> So whatever your puppetmasterd libdir is, you need to somehow ensure
> the types/providers are there. We do it with symlinks.
I think it is sufficient to set modulepath under [puppetmasterd] in
the puppet.conf file.  I do:

     [puppetmasterd]
         modulepath = /config/e/production/modules
         ...

where /config/e/production is where my production environment lives.
Then puppetmasterd will look in /config/e/production/modules/*/lib
for custom types, functions and facts.


	/Bellman

-- 
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 Tue, Jun 15, 2010 at 1:00 AM, Thomas Bellman <bellman@nsc.liu.se>
wrote:
> On 2010-06-15 01:21, Nigel Kersten wrote:
>
>> Sorry, I wasn''t quite clear. You need to make this accessible
to the
>> libdir on the *server*.
>>
>> So whatever your puppetmasterd libdir is, you need to somehow ensure
>> the types/providers are there. We do it with symlinks.
>
> I think it is sufficient to set modulepath under [puppetmasterd] in
> the puppet.conf file.  I do:
>
>    [puppetmasterd]
>        modulepath = /config/e/production/modules
>        ...
>
> where /config/e/production is where my production environment lives.
> Then puppetmasterd will look in /config/e/production/modules/*/lib
> for custom types, functions and facts.
I dislike setting a default modulepath, as it means that''s the one
clients get if they incorrectly specify their environment.


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


-- 
nigel

-- 
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 2010-06-15 16:20, Nigel Kersten wrote:
> On Tue, Jun 15, 2010 at 1:00 AM, Thomas Bellman<bellman@nsc.liu.se> 
wrote:
>> I think it is sufficient to set modulepath under [puppetmasterd] in
>> the puppet.conf file.  I do:
>>
>>     [puppetmasterd]
>>         modulepath = /config/e/production/modules
>>         ...
> I dislike setting a default modulepath, as it means that''s the one
> clients get if they incorrectly specify their environment.
I mitigate that by also doing

     manifestdir = /dev/null
     manifest = /dev/null/site.pp

Then I get "err: Could not retrieve catalog from remote server: Error
400 on SERVER: Could not parse for environment xyzzy: Could not find
file /dev/null/site.pp" if I happen to specify a non-existing environment.
Not very elegant, but seems to do the trick.


	/Bellman

-- 
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 Tue, Jun 15, 2010 at 7:58 AM, Thomas Bellman <bellman@nsc.liu.se>
wrote:
> On 2010-06-15 16:20, Nigel Kersten wrote:
>
>> On Tue, Jun 15, 2010 at 1:00 AM, Thomas
Bellman<bellman@nsc.liu.se>
>>  wrote:
>
>>> I think it is sufficient to set modulepath under [puppetmasterd] in
>>> the puppet.conf file.  I do:
>>>
>>>    [puppetmasterd]
>>>        modulepath = /config/e/production/modules
>>>        ...
>
>> I dislike setting a default modulepath, as it means that''s the
one
>> clients get if they incorrectly specify their environment.
>
> I mitigate that by also doing
>
>    manifestdir = /dev/null
>    manifest = /dev/null/site.pp
>
> Then I get "err: Could not retrieve catalog from remote server: Error
> 400 on SERVER: Could not parse for environment xyzzy: Could not find
> file /dev/null/site.pp" if I happen to specify a non-existing
environment.
> Not very elegant, but seems to do the trick.
Are you using an external node classifier? I thought that when I
deployed a classifier it stopped that trick from working... but I
could be wrong.


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


-- 
nigel

-- 
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 2010-06-15 17:07, Nigel Kersten wrote:
> On Tue, Jun 15, 2010 at 7:58 AM, Thomas Bellman<bellman@nsc.liu.se> 
wrote:
>> I mitigate that by also doing
>>
>>     manifestdir = /dev/null
>>     manifest = /dev/null/site.pp
> Are you using an external node classifier? I thought that when I
> deployed a classifier it stopped that trick from working... but I
> could be wrong.
Nope.  Haven''t found any reason for using a node classifier for my
systems.  A plain site.pp is simpler, and more flexible in several
ways which matters to me (although less flexible in some other ways).
Not to mention that external classifiers are global, so if you want
per-environment classifiers you need a global "indrector" classifier
first...

So, I don''t know if the above extra parameters work or not when you
use an external node classifier.


	/Bellman

-- 
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 Tue, 15 Jun 2010, Nigel Kersten wrote:
> >> I dislike setting a default modulepath, as it means
that''s the one
> >> clients get if they incorrectly specify their environment.
> >
> > I mitigate that by also doing
> >
> >    manifestdir = /dev/null
> >    manifest = /dev/null/site.pp
> 
> Are you using an external node classifier? I thought that when I
> deployed a classifier it stopped that trick from working... but I
> could be wrong.
I use an external node classifier, in conjunction with settings
like this:

   [puppetmasterd]
   environments = UNCONFIGURED,list,of,good,environments
   environment = UNCONFIGURED
   manifestdir = /etc/puppet/UNCONFIGURED
   # modulepath and manifest not set at this level

   [UNCONFIGURED]
   manifest = /etc/puppet/UNCONFIGURED/site.pp
   modulepath = /etc/puppet/UNCONFIGURED/empty-directory

UNCONFIGURED/site.pp contains little more than a "fail" statement.

My external node classifier forces environment = UNCONFIGURED
for any client that it doesn''t know about.

I found that setting manifestdir to something that did not exist
caused puppet to create it.  I didn''t try /dev/null, but I''d
be
afraid of puppet converting it from a device to a directory.

--apb (Alan Barrett)

-- 
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 Tue, Jun 15, 2010 at 9:23 AM, Alan Barrett <apb@cequrux.com>
wrote:
> On Tue, 15 Jun 2010, Nigel Kersten wrote:
>> >> I dislike setting a default modulepath, as it means
that''s the one
>> >> clients get if they incorrectly specify their environment.
>> >
>> > I mitigate that by also doing
>> >
>> >    manifestdir = /dev/null
>> >    manifest = /dev/null/site.pp
>>
>> Are you using an external node classifier? I thought that when I
>> deployed a classifier it stopped that trick from working... but I
>> could be wrong.
>
> I use an external node classifier, in conjunction with settings
> like this:
>
>   [puppetmasterd]
>   environments = UNCONFIGURED,list,of,good,environments
>   environment = UNCONFIGURED
>   manifestdir = /etc/puppet/UNCONFIGURED
>   # modulepath and manifest not set at this level
>
>   [UNCONFIGURED]
>   manifest = /etc/puppet/UNCONFIGURED/site.pp
>   modulepath = /etc/puppet/UNCONFIGURED/empty-directory
>
> UNCONFIGURED/site.pp contains little more than a "fail"
statement.
>
> My external node classifier forces environment = UNCONFIGURED
> for any client that it doesn''t know about.
You''re not actually doing any work in this environment though are you?
>
> I found that setting manifestdir to something that did not exist
> caused puppet to create it.  I didn''t try /dev/null, but
I''d be
> afraid of puppet converting it from a device to a directory.
>
> --apb (Alan Barrett)
>
> --
> 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.
>
>


-- 
nigel

-- 
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 Tue, 15 Jun 2010, Nigel Kersten wrote:
> > UNCONFIGURED/site.pp contains little more than a "fail"
statement.
> >
> > My external node classifier forces environment = UNCONFIGURED
> > for any client that it doesn''t know about.
> 
> You''re not actually doing any work in this environment though are
you?
No.  The "fail" statement in site.pp causes an error message on the
client, and nothing more happens until the configuration is fixed.

--apb (Alan Barrett)

-- 
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 quick look in $libdir (/var/lib/puppet/lib) shows my custom types are
there.
>
> Sorry, I wasn''t quite clear. You need to make this accessible to
the
> libdir on the *server*.
>
> So whatever your puppetmasterd libdir is, you need to somehow ensure
> the types/providers are there. We do it with symlinks.
Perhaps we mean different things by "libdir"?

insyte$ /usr/sbin/puppetmasterd --genconfig | egrep ''^
+libdir''
    libdir = /var/lib/puppet/lib

The types/providers are definitely be sync''d into that directory.  I
can''t find any reference to any other libdir.

In my fileserver.conf, I don''t have a path in the [plugins] section,
as all of my plugins are in modules.

My original understanding was that the type had to be available in the
default environment.  To that end, I copied my custom type into the
"modules/custom/lib/puppet/{type,provider}" dir of the production
environment.  Still no dice.

-Ben

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

I had two problems.  Nigel and Daniel correctly identified one of them
and Jonathan contacted me off-list to point out that I can''t have my
custom type living in a subdir of "lib/puppet/type".  I moved
haddock.rb from lib/puppet/type/haddock/haddock.rb to
lib/puppet/type/haddock.rb, created a symlink to the production
environment, and it works!

Thanks, everyone.

-Ben

On Tue, Jun 15, 2010 at 2:27 PM, Ben Beuchler <insyte@gmail.com>
wrote:
>>> A quick look in $libdir (/var/lib/puppet/lib) shows my custom types
are there.
>>
>> Sorry, I wasn''t quite clear. You need to make this accessible
to the
>> libdir on the *server*.
>>
>> So whatever your puppetmasterd libdir is, you need to somehow ensure
>> the types/providers are there. We do it with symlinks.
>
> Perhaps we mean different things by "libdir"?
>
> insyte$ /usr/sbin/puppetmasterd --genconfig | egrep ''^
+libdir''
>    libdir = /var/lib/puppet/lib
>
> The types/providers are definitely be sync''d into that directory.
 I
> can''t find any reference to any other libdir.
>
> In my fileserver.conf, I don''t have a path in the [plugins]
section,
> as all of my plugins are in modules.
>
> My original understanding was that the type had to be available in the
> default environment.  To that end, I copied my custom type into the
> "modules/custom/lib/puppet/{type,provider}" dir of the production
> environment.  Still no dice.
>
> -Ben
>
-- 
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 Tue, Jun 15, 2010 at 12:41 PM, Ben Beuchler <insyte@gmail.com> wrote:
> I had two problems.  Nigel and Daniel correctly identified one of them
> and Jonathan contacted me off-list to point out that I can''t have
my
> custom type living in a subdir of "lib/puppet/type".  I moved
> haddock.rb from lib/puppet/type/haddock/haddock.rb to
> lib/puppet/type/haddock.rb, created a symlink to the production
> environment, and it works!
>
awesome. This is a bit difficult to get working, but things are looking good
for the next release... :)


>
> Thanks, everyone.
>
> -Ben
>
> On Tue, Jun 15, 2010 at 2:27 PM, Ben Beuchler <insyte@gmail.com>
wrote:
> >>> A quick look in $libdir (/var/lib/puppet/lib) shows my custom
types are
> there.
> >>
> >> Sorry, I wasn''t quite clear. You need to make this
accessible to the
> >> libdir on the *server*.
> >>
> >> So whatever your puppetmasterd libdir is, you need to somehow
ensure
> >> the types/providers are there. We do it with symlinks.
> >
> > Perhaps we mean different things by "libdir"?
> >
> > insyte$ /usr/sbin/puppetmasterd --genconfig | egrep ''^
+libdir''
> >    libdir = /var/lib/puppet/lib
> >
> > The types/providers are definitely be sync''d into that
directory.  I
> > can''t find any reference to any other libdir.
> >
> > In my fileserver.conf, I don''t have a path in the [plugins]
section,
> > as all of my plugins are in modules.
> >
> > My original understanding was that the type had to be available in the
> > default environment.  To that end, I copied my custom type into the
> > "modules/custom/lib/puppet/{type,provider}" dir of the
production
> > environment.  Still no dice.
> >
> > -Ben
> >
>
> --
> 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<puppet-users%2Bunsubscribe@googlegroups.com>
> .
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
>
>

-- 
nigel

-- 
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 Jun 15, 9:41 pm, Ben Beuchler <ins...@gmail.com>
wrote:
> I had two problems.  Nigel and Daniel correctly identified one of them
> and Jonathan contacted me off-list to point out that I can''t have
my
> custom type living in a subdir of "lib/puppet/type".  I moved
> haddock.rb from lib/puppet/type/haddock/haddock.rb to
> lib/puppet/type/haddock.rb, created a symlink to the production
> environment, and it works!
Hi Ben,

I following this thread because I have the same problem.  However I''m
very new to puppet and don''t really understand what the layout now
should be.  I see that the types and providers are synced to the
client.  However it says like in your case:

Jun 21 11:12:50 wopr puppetmasterd[26666]: Could not find resource
type vcsrepo at /etc/puppet/development/modules/collectd/manifests/
server.pp:50 on node puptest.ugent.be

Could you please tell me how you actually made the symlink?  What
points to where?  Thanks!

I want to setup the vcsrepo module in my development enviroment:

[main]
logdir=/var/log/puppet
vardir=/var/lib/puppet
ssldir=/var/lib/puppet/ssl
rundir=/var/run/puppet
factpath=$vardir/lib/facter
pluginsync=true
environment=production
libdir = $confdir/lib
modulepath=$confdir/common/modules
templatedir=$confdir/common/templates


[development]
manifestdir=$confdir/development/manifests
modulepath=$confdir/development/modules:$confdir/common/modules
templatedir=$confdir/development/templates:$confdir/common/templates

[production]
manifestdir=$confdir/production/manifests
modulepath=$confdir/production/modules:$confdir/common/modules
templatedir=$confdir/production/templates:$confdir/common/templates

[puppetmasterd]
certname=puppet.ugent.be
reports = store,log


The vcsrepo:

development/modules/vcsrepo/
|-- Modulefile
|-- REVISION
|-- lib
|   `-- puppet
|       |-- provider
|       |   |-- vcsrepo
|       |   |   |-- bzr.rb
|       |   |   |-- cvs.rb
|       |   |   |-- git.rb
|       |   |   |-- hg.rb
|       |   |   `-- svn.rb
|       |   `-- vcsrepo.rb
|       `-- type
|           `-- vcsrepo.rb
|-- manifests
|   `-- init.pp
`-- metadata.json




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