On Tuesday, October 28, 2014 3:00:38 PM UTC-5, Riley Shott wrote: > > Hm. I wonder if this is related, but I suspect if it was you would get > complaints instead of catalog runs that succeed, albeit empty. >
That catalog runs are succeeding but yielding empty catalogs is a good reason to consider access control issues. We've had to symlink modules with custom types and providers in all > environments to /etc/puppet/modules so that pluginsync will work. > That sounds strange. Is there a bug report on file for this? If not then you should file one. > AFAIK this is a issue with Ruby's containment and namespace capabilities > (part of the reason they're re-writing Puppet 4 in Clojure). > Those details really ought not to be much relevant to pluginsync. There are namespace and containment issues, but as far as I know they relate to which plugin components the master will *load*, itself, not which ones it will sync. > Your master's /var/lib/puppet/lib is where is its agent stores all the > plugins, and it's also where it distributes them from. > To the best of my knowledge, only the first part (that /var/lib/puppet/lib is where pluginsync drops plugins) is strictly true. I am inclined to think that only the first part is true at all. > What this means is that the Puppet master needs to run in order to sync > any new plugins before it can distribute them. > > Let's save this for when it's relevant. Victor needs to get environments working at his master before any of those details begin to matter. > Your config look correct now since you've changed default_manifests to > './manifests'. > The default_manifests setting is a red herring, given that Victor has a 'manifests' directory in each environment. Moreover, the setting he started with is the one recommended by the documentation. './manifests' is the default value for the setting, specifying that is equivalent to not specifying the property at all (which is in fact a reasonable thing to do). > Try changing the modulepath value in your environment.conf to this: > > I think Victor said he would prefer not to use environment.conf files, and as long as he uses the standard environment layout he shouldn't need to do. Better to keep environment.conf out of the picture entirely until basic function is achieved. In fact, better to keep modulepath out of the picture until basic function is achieved, too. It should be enough to focus on the manifest directory of one environment, and to expand from there once that's sorted. 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/ece2092b-9f12-4016-b21a-5439dee7ef35%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.