Hi all, I have a curious problem that I'd appreciate help/guidance on.
We are running puppetserver 2.6.0 (puppetmaster.domain.ca) with cobbler 2.6.11 as our ENC. All our servers/nodes are centos 7.3 On the puppet client (node.domain.ca) when running the puppet agent we receive the following output/error: [[email protected] ~]# Redirecting to /bin/systemctl stop puppet.service Info: Caching certificate for node.domain.ca Info: Caching certificate_revocation_list for ca Info: Caching certificate for node.domain.ca Info: Using configured environment 'ops' Info: Retrieving pluginfacts Info: Retrieving plugin Info: Loading facts Error: Could not retrieve catalog from remote server: Error 500 on SERVER: Server Error: Could not find class users::opsusers for node.domain.ca on node node.domain.ca Info: Using cached catalog from environment 'ops' Info: Applying configuration version '1487721491' Notice: /Stage[main]/Puppet::Agent/Service[puppet]/ensure: ensure changed 'stopped' to 'running' Info: /Stage[main]/Puppet::Agent/Service[puppet]: Unscheduling refresh on Service[puppet] Error: /Stage[main]/Main/Selinux::Audit2allow[zabbix_bug]/File[/etc/selinux/local/zabbix_bug/messages]: Could not evaluate: Could not retrieve information from environment ops source(s) puppet:///modules/node2.domain.ca/messages.zabbix Notice: /Stage[main]/Main/Selinux::Audit2allow[zabbix_bug]/Exec[semodule -r localzabbix_bug; rm -f localzabbix_bug.*; audit2allow -M localzabbix_bug -i messages && semodule -i localzabbix_bug.pp]: Dependency File[/etc/selinux/local/zabbix/messages] has failures: true Warning: /Stage[main]/Main/Selinux::Audit2allow[zabbix_bug]/Exec[semodule -r localzabbix_bug; rm -f localzabbix_bug.*; audit2allow -M localzabbix_bug -i messages && semodule -i localzabbix_bug.pp]: Skipping because of failed dependencies Notice: /Stage[main]/Legato/File[/nsr/tmp/sec/nsr_shutdown.pid]/seluser: seluser changed 'unconfined_u' to 'system_u' Notice: /Stage[main]/Legato/File[/nsr/tmp/sec/services]/seluser: seluser changed 'unconfined_u' to 'system_u' Notice: /Stage[main]/Tools/Exec[check_presence]/returns: executed successfully Info: Stage[main]: Unscheduling all events on Stage[main] Notice: Applied catalog in 48.03 seconds The problem is that despite the agent claiming to retrieve the catalog for the `ops` environment it throws two errors where its not able to find class /retrieve information. The strange part is that the class `users::opsuser` is only defined under the ops/classes directory for that environment. The second error is thrown by module `selinux::audit2allow` module and claims that the environment `ops` can not find source puppet:///modules/node2.domain.ca/messages.zabbix BUT this path is ONLY defined in the production environment's site.pp. The site.pp for the environment 'ops' has the following source defined for this message file for the selinux::audit2allow module: puppet:///modules/selinux/messages.zabbix This says to me that the agent is relying on some default `production` environment values but it is not clear to me how/where this is happening. Here's a snippet of the tree output for the /etc/puppetlabs/code directory on puppetmaster with key files shown listed: [root@puppetmaster /etc/puppetlabs/]# tree -L 6 code code ├── environments │ ├── ops │ │ ├── classes │ │ │ └── node.domain.ca │ │ │ ├── files │ │ │ └── manifests │ │ │ └── init.pp │ │ ├── environment.conf │ │ ├── hieradata │ │ ├── manifests │ │ │ └── site.pp │ │ ├── modules │ │ │ ├── selinux │ │ │ │ ├── files │ │ │ │ │ └── messages.zabbix │ │ │ │ ├── manifests │ │ │ │ │ ├── audit2allow.pp │ │ │ │ │ └── init.pp │ │ │ ├── users │ │ │ │ ├── files │ │ │ │ ├── manifests │ │ │ │ │ ├── init.pp │ │ │ │ │ └── opsusers.pp │ │ │ └── zabbix │ ├── node.rb │ └── production │ ├── classes │ │ ├── node2.domain.ca │ │ │ ├── files │ │ │ │ └── messages.zabbix │ │ │ └── manifests │ │ │ └── init.pp │ ├── environment.conf │ ├── hieradata │ ├── manifests │ │ └── site.pp │ ├── modules │ │ ├── selinux │ │ │ ├── files │ │ │ │ └── messages.zabbix │ │ │ ├── manifests │ │ │ │ └── audit2allow.pp │ │ ├── users │ │ │ ├── files │ │ │ └── manifests │ │ └── zabbix ├── hiera.yaml └── modules The 'ops' environment.conf file has these 2 lines defined: modulepath = ./modules:./classes:$basemodulepath manifest = ./manifests The `production` environment.conf has the following: modulepath = ./modules:./classes:$basemodulepath # manifest = (default_manifest from puppet.conf, which defaults to ./manifests) The `/etc/puppetlabs/puppet/puppet.conf` : [main] environmentpath = /etc/puppetlabs/code/environments basemodulepath = /etc/puppetlabs/code/modules:/opt/puppetlabs/puppet/modules/ node_terminus = exec external_nodes = /etc/puppetlabs/code/environments/node.rb [master] vardir = /opt/puppetlabs/server/data/puppetserver logdir = /var/log/puppetlabs/puppetserver rundir = /var/run/puppetlabs/puppetserver pidfile = /var/run/puppetlabs/puppetserver/puppetserver.pid codedir = /etc/puppetlabs/code server = puppetmaster.domain.ca storeconfigs = true storeconfigs_backend = puppetdb node_terminus = exec external_nodes = /etc/puppetlabs/code/environments/node.rb ON the client (node.domain.ca), we run the agent like so: [[email protected] ~]# service puppet stop && puppet agent -o -v --server puppetmaster.domain.ca --environment ops --no-daemonize AND on that node the /etc/puppetlabs/puppet/puppet.conf file has the following defined in it: server = puppetmaster.domain.ca report = false runinterval = 7200 environment = ops Maybe I'm missing something trivial, but if anyone has ideas as to what that might be or why the puppet agent suggests that files/sources from the `production` environment are being retrieved as opposed to what clearly should be the `ops` envrionment, I'd be very happy to have your input. -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/bb370cac-3fc9-46c8-9d21-0a380800d12d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
