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