My upgrade is actually a clean install on a new system -- I am, of course, not touching the production puppetmaster while I am putzing around with the upgrade. In the process of installing Puppet 3.7, I blow away all the RPMs and directories, and install Puppet from scratch (I have a script that's supposed to bootstrap it).
Anyway, see my post above -- apparently it was the 'certname' value that was causing 'puppet module list' to fail, which is exceedingly weird. On Tuesday, October 28, 2014 4:37:37 PM UTC-4, jcbollinger wrote: > > > > 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/7079fefb-ab17-4610-918c-6833d646e54f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
