On Monday, November 18, 2013 3:40:46 AM UTC-6, Patricia Jung wrote:
>
> Dear John and all,
>
> Am 15.11.2013 um 15:47 schrieb jcbollinger:
> >
> > On Thursday, November 14, 2013 5:32:50 AM UTC-6, Patricia Jung wrote:
> >
> > http://docs.puppetlabs.com/puppet/3/reference/lang_defined_types.htmldoes
> > not suggest to me that nested parametrized defines would be forbidden
> >
> >
> > You are correct. Defined type bodies may declare resources of any type,
> including defined types.
> >
> >
> > , hence I expected the following code to work:
> >
> > add_to_ssh_authorized_keys.pp:
> > --------
> > define a::ssh_keys::add_to_ssh_authorized_keys($homebasedir="/home",
> $targetuser="root", $keyowner, $keyownername, $state="present" ) {
> >
> >
> > To be clear, that should appear in <module
> path>/a/manifests/ssh_keys/add_to_ssh_authorized_keys.pp in order for the
> autoloader to be able to find it.
> Yes, this is true: it's located in
> /etc/puppet/modules/a/manifests/ssh_keys/add_to_ssh_authorized_keys.pp
> >
> >
> >
> > it_services_admins.pp:
> > ---------
> > define a::ssh_keys::it_services_admins($user='root'){
> >
> >
> > Likewise, that should appear in <module
> path>/a/manifests/ssh_keys/it_services_admins.pp
> This file is located in
> etc/puppet/modules/a/manifests/ssh_keys/it_services_admins.pp
> >
> >
> >
> >
> > censhare::ssh_keys::add_to_ssh_authorized_keys{ "$user-blah":
> Sorry, my fault, the line above reads
> a::ssh_keys::add_to_ssh_authorized_keys{ "$user-blah":
> >
> > targetuser => "$user",
> > keyowner => 'blah',
> > keyownername => 'blah',
> > }
> > }
> >
> > ---------
> >
> > class file:
> >
> >
> > I suppose you mean that this is the file of the module main class,
> <module path>/<module_name>/manifests/init.pp
> >
> >
> Not necessarily init.pp, and it's outside the a module, e.g.:
> /etc/puppet/modules/c/manifests/nodes/saas.pp. Perhaps this is the
> problem?
>
Ah, ok. I understand now.
No, it should not be a problem for instances of your defined type to be
declared by classes from other modules or even no module at all. Besides,
the declaration in c::nodes::saas is not the locus of the problem.
> > ------------
>
> class c::nodes::saas{
> a::ssh_keys::it_services_admins{ 'b':
> user => 'b'
> }
> a::ssh_keys::it_services_admins{ 'root':
> user => 'root'
> }
> }
>
> The error message reads:
>
> Invalid resource type a::ssh_keys::add_to_ssh_authorized_keys at
> /etc/puppet/modules/a/manifests/ssh_keys/:7"
>
>
>
"Invalid resource type" for a defined type, supposing that it's not
altogether a red herring, means that Puppet does not recognize the type as
a native one (which it isn't), and cannot find a definition for that name.
There are a few alternatives for why it might not find the definition,
among them
- The definition does not appear in the file the autoloader expects to
find it in. You report, however, that it does appear in the correct file.
- The definition is not declared with the expected name. The definition
should use the correct fully-qualified name, as indeed you show it to do.
If there were some mixup, however -- say the file defined censhare::...
when it should have declared a::... -- then you would probably get an error
such as you report.
- The Puppet master cannot read the file, or perhaps cannot read some
directory in the path to it. Unlike the Puppet agent, the master can and
normally does run as an unprivileged user, often named "puppet". If file
permissions, ownership, SELinux context, ACLs, or some other access control
mechanism prevents the Puppet master process from reading the file, then
you might get an error such as you describe.
- As a special case, it is conceivable (though unlikely) that UTF-8
encoded file names containing characters above U+00FF might cause trouble
if they appear in the same directory as the definition's file.
- The contents of the file containing the definition are not parsed
successfully. I would actually expect a more localized error in this case,
but if for some reason none was emitted then the error you report would be
a likely fallback outcome. You can test this by running "puppet parser
validate <manifest file>" on the file containing the definition.
If the problem is not one of the above then I'm stumped.
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 view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/5f3f7e9d-ca6e-4575-a1fc-d20d53cb89a0%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
