Puppet users - Jul 2013 - puppet apply --hiera_config --> Error: Could not find class

Hi there,

I''m running into an problem which I can resolve. It is bugging me for 
couple of days now.
Goal: CentOS 6.4 freshly installed incl puppet 3.2.3 and I want to install 
puppet master, puppetdb, mod_passenger & apache with "puppet
apply". So
when this is complete, I should have an puppet master server running so I 
can create new hosts etc.

So this is the command and error:
[root@vserver-151 ~]# puppet apply --hiera_config /etc/puppet/hiera.yaml 
--modulepath=/etc/puppet/modules/management/ /etc/puppet/manifests/site.pp 
--environment management  --debug
Info: Loading facts in 
/etc/puppet/modules/management/staging/lib/facter/staging_http_get.rb
Info: Loading facts in 
/etc/puppet/modules/management/concat/lib/facter/concat_basedir.rb
Info: Loading facts in 
/etc/puppet/modules/management/stdlib/lib/facter/puppet_vardir.rb
Info: Loading facts in 
/etc/puppet/modules/management/stdlib/lib/facter/root_home.rb
Info: Loading facts in 
/etc/puppet/modules/management/stdlib/lib/facter/facter_dot_d.rb
Info: Loading facts in 
/etc/puppet/modules/management/stdlib/lib/facter/pe_version.rb
Info: Loading facts in 
/etc/puppet/modules/management/postgresql/lib/facter/postgres_default_version.rb
Info: Loading facts in 
/etc/puppet/modules/management/firewall/lib/facter/iptables_version.rb
Info: Loading facts in 
/etc/puppet/modules/management/firewall/lib/facter/iptables_persistent_version.rb
Info: Loading facts in 
/etc/puppet/modules/management/firewall/lib/facter/ip6tables_version.rb
Info: Loading facts in 
/etc/puppet/modules/management/puppet/lib/facter/etckepper_puppet.rb
Debug: hiera(): Hiera YAML backend starting
Debug: hiera(): Looking up classes in YAML backend
Debug: hiera(): Looking for data source Nieuwegein/base
Debug: hiera(): Found classes in Nieuwegein/base
Debug: hiera(): Looking for data source 
Nieuwegein/management/vserver-151.dj-wasabi.nl
Debug: hiera(): Found classes in 
Nieuwegein/management/vserver-151.dj-wasabi.nl
Debug: hiera(): Looking for data source Nieuwegein/management
Debug: hiera(): Data retrieved from 
/etc/puppet/hieradata/Nieuwegein/management.yaml is not a Hash, setting 
defaults
Debug: hiera(): Looking for data source Nieuwegein/common
Debug: hiera(): Looking for data source common
Debug: hiera(): Data retrieved from /etc/puppet/hieradata/common.yaml is 
not a Hash, setting defaults
Error: Could not find class users for vserver-151.dj-wasabi.nl on node 
vserver-151.dj-wasabi.nl
Error: Could not find class users for vserver-151.dj-wasabi.nl on node 
vserver-151.dj-wasabi.nl
[root@vserver-151 ~]#

To give some information about the hiera files:
[root@vserver-151 ~]# cat /etc/puppet/hiera.yaml 
---
:backend:
  - yaml
:hierarchy:
  - %{location}/base
  - %{location}/%{environment}/%{fqdn}
  - %{location}/%{environment} 
  - %{location}/common
  - common
:yaml:
   :datadir: ''/etc/puppet/hieradata''

"My location" file
[root@vserver-151 ~]# cat /etc/facter/facts.d/location.yaml 
---
location: Nieuwegein

base file:
[root@vserver-151 ~]# cat /etc/puppet/hieradata/Nieuwegein/base.yaml 
---
classes: [ ''users'', ''puppet::agent'' ]

puppet::agent::puppet_server: vserver-151.dj-wasabi.nl
puppet::agent::puppet_server_port: 8140
puppet::agent::puppet_run_interval: 30

common file:
[root@vserver-151 ~]# cat /etc/puppet/hieradata/Nieuwegein/common.yaml 
---

nagios_server = 192.168.1.222

# nrpe stuff
nrpe_config_dir: /etc/nrpe.d
nrpe_scripts_dir: /usr/lib64/nagios/plugins/contrib

My site.pp
[root@vserver-151 defines]# cat /etc/puppet/manifests/site.pp 
node default {
   hiera_include(''classes'','''')
}

Configuration file for this host:
[root@vserver-151 Nieuwegein]# cat 
/etc/puppet/hieradata/Nieuwegein/management/vserver-151.dj-wasabi.nl.yaml 
---
classes: [''ruby'', ''puppet::master'',
''puppetdb'', ''apache'' ]

puppet::master::storeconfigs: true
puppet::master::autosign: true
puppet::master::puppet_passenger_port: 8140
puppet::master::storeconfigs_dbserver: vserver-151.dj-wasabi.nl

puppet_server_environments:
  production:
    modulepath: /etc/puppet/modules/production/
    manifest: /etc/puppet/manifests/site.pp
  development:
    modulepath: /etc/puppet/modules/development/
    manifest: /etc/puppet/manifests/site.pp
  management:
    modulepath: /etc/puppet/modules/management/
    manifest: /etc/puppet/manifests/site.pp
[root@vserver-151 Nieuwegein]#

Overview of the ''management modules'' directory:
[root@vserver-151 ~]# ls -l /etc/puppet/modules/management/
total 80
drwxr-xr-x 8 root root 4096 Jul 27 20:43 apache
drwxr-xr-x 6 root root 4096 Jul 27 20:43 apt
drwxr-xr-x 4 root root 4096 Jul 27 20:43 bin
drwxr-xr-x 6 root root 4096 Jul 27 20:43 concat
drwxr-xr-x 5 root root 4096 Jul 27 20:43 firewall
drwxr-xr-x 5 root root 4096 Jul 27 20:43 inifile
drwxr-xr-x 7 root root 4096 Jul 27 20:43 mrepo
drwxr-xr-x 8 root root 4096 Jul 27 20:43 mysql
drwxr-xr-x 7 root root 4096 Jul 27 20:43 nrpe
drwxr-xr-x 6 root root 4096 Jul 27 20:43 ntp
drwxr-xr-x 5 root root 4096 Jul 27 20:43 passenger
drwxr-xr-x 8 root root 4096 Jul 27 20:43 postgresql
drwxr-xr-x 8 root root 4096 Jul 27 20:43 puppet
drwxr-xr-x 6 root root 4096 Jul 27 20:43 puppetdb
drwxr-xr-x 5 root root 4096 Jul 27 20:43 ruby
drwxr-xr-x 8 root root 4096 Jul 27 20:43 staging
drwxr-xr-x 6 root root 4096 Jul 27 20:43 stdlib
drwxr-xr-x 6 root root 4096 Jul 27 20:43 sudoers
drwxr-xr-x 4 root root 4096 Jul 29 19:49 users
drwxr-xr-x 5 root root 4096 Jul 27 20:43 vcsrepo
[root@vserver-151 ~]#

The ''users'' module:
[root@vserver-151 manifests]# pwd
/etc/puppet/modules/management/users/manifests

init.pp:
#
class users {
  import ''defines/*.pp''

  include users::users
  include users::system
  include users::apps
}
[users.pp: 
#
class users::users {

  @adduser { ''wdijkerman'':
    ensure   => present,
    uid      => ''1001'',
    comment  => ''Werner Dijkerman'',
    groups   => [''admin''],
    key      => ''<--SNIP_very_long-->'',
    key_type => ''ssh-dss'',
  }

# Adding the groups
  @addgroup { ''admin'':
    ensure => present,
    gid    => ''1100''
  }

  Addgroup <| title == ''admin'' |> ~> Adduser <|
groups == ''admin'' |>
}

system.pp:
#
class users::system  {

  @adduser { ''root'':
    ensure   => present,
    uid      => ''0'',
    gid      => ''0'',
    comment  => ''root user'',
    home_dir => ''root'',
    #password => ''$1$wSKXXILm$SQCCXItlRgNzm.YSGtbNb0'',
    password => ''$1$9HZ.fRew$Ar1SICNBOVrMKOCBtEEay.'',
  }

Adduser <| title == ''root'' |>
}

apps.pp file:
# Will contain app users.
class users::apps {
  @adduser { ''puppet'':
    ensure   => present,
    uid      => ''2001'',
    comment  => ''Puppet user'',
    shell    => ''/bin/false'',
    home_dir => ''/var/lib/puppet'',
  }

  @adduser { ''puppetdb'':
    ensure   => present,
    uid      => ''2002'',
    comment  => ''puppetdb user'',
    shell    => ''/bin/false'',
    home_dir => ''/usr/share/puppetdb'',
  }

  @adduser { ''bind'':
    ensure   => present,
    uid      => ''2003'',
    comment  => ''Bind user'',
    shell    => ''/bin/false'',
  }

  @adduser { ''postgres'':
    ensure   => present,
    uid      => ''2004'',
    comment  => ''postgres user'',
    shell    => ''/bin/false'',
    home_dir => ''/var/lib/pgsql'',
  }
}

So when I edit the file /etc/puppet/hieradata/Nieuwegein/base.yaml and 
remove the ''users'' with just the
''puppet::agent'' only mentioned in classes,
it will continue with the ''puppet apply'', so something
isn''t correct with
the users module.
The ''users'' module also an define, which I''ve
uploaded.

Both Selinux & iptables are disabled.

What am I not seeing right now...

-- 
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+unsubscribe@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.
For more options, visit https://groups.google.com/groups/opt_out.

On Monday, July 29, 2013 1:53:04 PM UTC-5, Werner Dijkerman
wrote:
>
> Hi there,
>
> I''m running into an problem which I can resolve. It is bugging me
for
> couple of days now.
> Goal: CentOS 6.4 freshly installed incl puppet 3.2.3 and I want to install 
> puppet master, puppetdb, mod_passenger & apache with "puppet
apply". So
> when this is complete, I should have an puppet master server running so I 
> can create new hosts etc.
>
> So this is the command and error:
> [root@vserver-151 ~]# puppet apply --hiera_config /etc/puppet/hiera.yaml 
> --modulepath=/etc/puppet/modules/management/ /etc/puppet/manifests/site.pp 
> --environment management  --debug
> Info: Loading facts in 
> /etc/puppet/modules/management/staging/lib/facter/staging_http_get.rb
> Info: Loading facts in 
> /etc/puppet/modules/management/concat/lib/facter/concat_basedir.rb
> Info: Loading facts in 
> /etc/puppet/modules/management/stdlib/lib/facter/puppet_vardir.rb
> Info: Loading facts in 
> /etc/puppet/modules/management/stdlib/lib/facter/root_home.rb
> Info: Loading facts in 
> /etc/puppet/modules/management/stdlib/lib/facter/facter_dot_d.rb
> Info: Loading facts in 
> /etc/puppet/modules/management/stdlib/lib/facter/pe_version.rb
> Info: Loading facts in 
>
/etc/puppet/modules/management/postgresql/lib/facter/postgres_default_version.rb
> Info: Loading facts in 
> /etc/puppet/modules/management/firewall/lib/facter/iptables_version.rb
> Info: Loading facts in 
>
/etc/puppet/modules/management/firewall/lib/facter/iptables_persistent_version.rb
> Info: Loading facts in 
> /etc/puppet/modules/management/firewall/lib/facter/ip6tables_version.rb
> Info: Loading facts in 
> /etc/puppet/modules/management/puppet/lib/facter/etckepper_puppet.rb
> Debug: hiera(): Hiera YAML backend starting
> Debug: hiera(): Looking up classes in YAML backend
> Debug: hiera(): Looking for data source Nieuwegein/base
> Debug: hiera(): Found classes in Nieuwegein/base
> Debug: hiera(): Looking for data source Nieuwegein/management/
> vserver-151.dj-wasabi.nl
> Debug: hiera(): Found classes in Nieuwegein/management/
> vserver-151.dj-wasabi.nl
> Debug: hiera(): Looking for data source Nieuwegein/management
> Debug: hiera(): Data retrieved from 
> /etc/puppet/hieradata/Nieuwegein/management.yaml is not a Hash, setting 
> defaults
> Debug: hiera(): Looking for data source Nieuwegein/common
> Debug: hiera(): Looking for data source common
> Debug: hiera(): Data retrieved from /etc/puppet/hieradata/common.yaml is 
> not a Hash, setting defaults
> Error: Could not find class users for vserver-151.dj-wasabi.nl on node 
> vserver-151.dj-wasabi.nl
> Error: Could not find class users for vserver-151.dj-wasabi.nl on node 
> vserver-151.dj-wasabi.nl
> [root@vserver-151 ~]#
>
>
"Could not find class" probably means more or less what it says. 
Supposing
that the class''s manifest is present where it''s supposed to be
(as you
indicate that it is), It may indicate a permissions or ownership problem 
with one of the files or directories in the users module.  You could try 
setting permissions on the manifests to mode 0644, and on the directories 
to mode 0755 to test that.  If puppet then finds the class that confirms an 
access control issue.  (Note that if the filesystem on which these reside 
is remote, e.g. NFS, then the local root user may not have privileged 
access to the files.)

It would also be worthwhile to ensure that Puppet is using the correct 
module path.  Adjust your data so that "puppet apply" works, then
modify
one of the classes in the expected module path to Notify or otherwise 
signal you.

I would expect additional messages to be logged if Puppet found the users 
class but failed to parse it.  Nevertheless, it might be worthwhile to 
check out the implementation of that class, and maybe of the others in its 
module.  There are a couple of oddities, which I discuss below.

  
>
> The ''users'' module:
> [root@vserver-151 manifests]# pwd
> /etc/puppet/modules/management/users/manifests
>
> init.pp:
> #
> class users {
>   import ''defines/*.pp''
>
>   include users::users
>   include users::system
>   include users::apps
> }
>

The ''import'' statement in that class is very suspicious.  The
function has
very few legitimate uses, with almost all of its historic uses having long 
since been taken over by the autoloader.  Moreover, the placement makes me 
think you have the wrong expectations.  Using ''import'' inside
a class body
has no different effect from using the same statement outside the class 
body in the same manifest.  In particular, ''import'' in a class
body does
NOT put the imported declarations into the scope of that class.

 
> [users.pp: 
> #
> class users::users {
>
>   @adduser { ''wdijkerman'':
>     ensure   => present,
>     uid      => ''1001'',
>     comment  => ''Werner Dijkerman'',
>     groups   => [''admin''],
>     key      => ''<--SNIP_very_long-->'',
>     key_type => ''ssh-dss'',
>   }
>
> # Adding the groups
>   @addgroup { ''admin'':
>     ensure => present,
>     gid    => ''1100''
>   }
>
>   Addgroup <| title == ''admin'' |> ~> Adduser
<| groups == ''admin'' |>
> }
>
> system.pp:
> #
> class users::system  {
>
>   @adduser { ''root'':
>     ensure   => present,
>     uid      => ''0'',
>     gid      => ''0'',
>     comment  => ''root user'',
>     home_dir => ''root'',
>     #password => ''$1$wSKXXILm$SQCCXItlRgNzm.YSGtbNb0'',
>     password => ''$1$9HZ.fRew$Ar1SICNBOVrMKOCBtEEay.'',
>   }
>
> Adduser <| title == ''root'' |>
> }
>
> apps.pp file:
> # Will contain app users.
> class users::apps {
>   @adduser { ''puppet'':
>     ensure   => present,
>     uid      => ''2001'',
>     comment  => ''Puppet user'',
>     shell    => ''/bin/false'',
>     home_dir => ''/var/lib/puppet'',
>   }
>
>   @adduser { ''puppetdb'':
>     ensure   => present,
>     uid      => ''2002'',
>     comment  => ''puppetdb user'',
>     shell    => ''/bin/false'',
>     home_dir => ''/usr/share/puppetdb'',
>   }
>
>   @adduser { ''bind'':
>     ensure   => present,
>     uid      => ''2003'',
>     comment  => ''Bind user'',
>     shell    => ''/bin/false'',
>   }
>
>   @adduser { ''postgres'':
>     ensure   => present,
>     uid      => ''2004'',
>     comment  => ''postgres user'',
>     shell    => ''/bin/false'',
>     home_dir => ''/var/lib/pgsql'',
>   }
> }
>
>
I suppose the ''adduser'' and ''addgroup''
defined types are among those you
expect the import statement to pick up.  In fact, that probably works, but 
it''s the wrong way to do it.  Instead, you should put the definitions
into
their module''s namespace, and let the autoloader find them.

The autoloader works just the same for defined types as it does for 
classes.  For example, if you attempt to declare a resource of, say, 
defined type users::adduser, then the autoloader looks for its definition 
in a manifest file users/manifests/adduser.pp relative to the directories 
in your module path.  Note that, just like classes, defined types in 
modules should have namespaced names.

 
> So when I edit the file /etc/puppet/hieradata/Nieuwegein/base.yaml and 
> remove the ''users'' with just the
''puppet::agent'' only mentioned in classes,
> it will continue with the ''puppet apply'', so something
isn''t correct with
> the users module.
> The ''users'' module also an define, which I''ve
uploaded.
>
> Both Selinux & iptables are disabled.
>
> What am I not seeing right now...
>
 
If it''s not something I touched on above, then I''m not sure
what it is.  In
that case I would start trimming down the problem: cut back to the minimum 
set of classes that produce the issue, and simplify the remaining classes 
and modules as much as you can while continuing to reproduce the problem.  
If you do not discover the problem for yourself during this process then 
what''s left will be a lot easier for the rest of us to analyze.


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+unsubscribe@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.
For more options, visit https://groups.google.com/groups/opt_out.

Hi John,

Thanks for your answer. This will help me a lot. I already had some doubt 
if this module was good enough and already had some ideas about how to go 
on. But that will take some time and I had an small hope that this issue 
was very simple to solve. So, I''ll continue the
''users::adduser'' way.. :-)
The main reason for doing this way, was that I only have 1 place with all 
users with their uids. (And found somewhere on the internet)

Kind regards,
Werner

-- 
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+unsubscribe@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.
For more options, visit https://groups.google.com/groups/opt_out.