On Tuesday, October 28, 2014 12:32:48 PM UTC-5, Victor Danilchenko wrote: > > John, > > Sorry, I should have been more thorough -- this is Puppet 3.7 master, > running as root (so it has full access to everything). >
Actually, the master normally *shouldn't* run as root. Whether it does depends on how you start it, but Puppet packages I've seen typically set up the master to run under a for-purpose service account, typically named "puppet". The master has no need for privilege to perform its work, so good security practices dictate that it not have any. (The agent is a different matter.) Regardless of the user id of the puppetmaster process, there might be an access control issue involved. Even root is affected by some forms of access control (SELinux policy, server-enforced policy on remote network directories). Also, since you said you were upgrading, can you be sure that you don't have any bits lying around from an older Puppet version (or even a whole copy of another Puppet version)? That might happen if you performed multiple installs, such as a source install and an RPM / DEB install (and maybe even a gem install, too). It can happen in such cases that Puppet loads a mixture of bits from different versions, and then all manner of strange behavior can occur. > > Yes, 'puppet module > --modulepath=/etc/puppet/environments/production/modules list' also works > -- but I was under impression that supplying the environmentpath value in > puppet.conf, in the [main] section, was sufficient. > I think you have the right expectation, provided that Puppet is in fact reading the config file you think it's reading. My point was that your code excerpt specified a --confdir that appeared to in fact be a modulepath. > I can set the module.path explicitly in each environment.conf file, but I > am hoping to avoid that. > As indeed you should be able to do. > > Note BTW that calling 'puppet module --confdir=/etc/puppet list' does NOT > work: is results in the same error as in the OP -- Puppet simply finds no > modules. > > Fair enough. I'm still having difficulty spotting any problem in your config file, so I still think the problem is likely related to your directory layout, contents, or access controls. Do satisfy yourself about the integrity of your Puppet install, but that's a bit of a long shot. > My manifest directory is populated with a working manifest: this is the > environment I simply copied from our working Puppet 3.4 master installation > using explicitly configured environments. Both > environments/production/manifests and environments/production/modules > directories are properly populated (and yes, I need to use per-environment > manifests, not the global one). > > That's more or less the way I would have proceeded myself, but if you can "[copy] from [your] working Puppet 3.4 master installation" then does that mean that you have Puppet 3.4 and Puppet 3.7 installed at the same time on the same machine? If so, that's an uncertain proposition. I would recommend first upgrading from 3.4 to 3.7 (keeping your existing config file environments), then, separately, moving to directory environments. 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/c2c3f410-1006-443b-80a6-01a503237f60%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
