Thanks for the reply John, The issue still persists unfortunately.
I've ensured that Selinux isn't enforcing on both the server side and client and then restarted the Puppet service on the master server. The server logs whilst running the agent read as follows: 10.20.25.83 - - - 27/Sep/2019:16:06:43 +0000 "GET /puppet/v3/node/lhcadvdeveye05.fixnetix.com?environment=production&transaction_uuid=4d2c88b1-2aec-45a5-bc7e-407c2ad8229e&fail_on_404=true HTTP/1.1" 200 13535 10.20.25.83 10.20.25.83 8140 109 10.20.25.83 - - - 27/Sep/2019:16:06:43 +0000 "GET /puppet/v3/file_metadatas/pluginfacts?environment=production&links=follow&recurse=true&source_permissions=use&ignore=.svn&ignore=CVS&ignore=.git&ignore=.hg&checksum_type=md5 HTTP/1.1" 200 220 10.20.25.83 10.20.25.83 8140 25 10.20.25.83 - - - 27/Sep/2019:16:06:43 +0000 "GET /puppet/v3/file_metadatas/plugins?environment=production&links=follow&recurse=true&source_permissions=ignore&ignore=.svn&ignore=CVS&ignore=.git&ignore=.hg&checksum_type=md5 HTTP/1.1" 200 224 10.20.25.83 10.20.25.83 8140 16 10.20.25.83 - - - 27/Sep/2019:16:06:44 +0000 "GET /puppet/v3/file_metadatas/locales?environment=production&links=follow&recurse=true&source_permissions=ignore&ignore=.svn&ignore=CVS&ignore=.git&ignore=.hg&ignore=%2A.pot&ignore=config.yaml&checksum_type=md5 HTTP/1.1" 200 224 10.20.25.83 10.20.25.83 8140 20 2019-09-27 16:06:44,620 INFO [puppetserver] Puppet Compiled catalog for lhcadvdeveye05.fixnetix.com in environment production in 0.10 seconds 10.20.25.83 - - - 27/Sep/2019:16:06:44 +0000 "POST /puppet/v3/catalog/lhcadvdeveye05.fixnetix.com?environment=production HTTP/1.1" 200 612 10.20.25.83 10.20.25.83 8140 249 10.20.25.83 - - - 27/Sep/2019:16:06:45 +0000 "PUT /puppet/v3/report/lhcadvdeveye05.fixnetix.com?environment=production& HTTP/1.1" 200 9 10.20.25.83 10.20.25.83 8140 92 Unfortunately, I don't see anything untoward here nor anything helpful that contributes to resolving the issue. Thanks, Dan. On Friday, September 27, 2019 at 2:21:32 PM UTC+1, jcbollinger wrote: > > > > On Friday, September 27, 2019 at 7:20:51 AM UTC-5, Dan Crisp wrote: >> >> Please see below. Apologies, there is a lot of detail here: >> >> Debug: Using settings: adding file resource 'confdir': >> 'File[/etc/puppetlabs/puppet]{:path=>"/etc/puppetlabs/puppet", >> :ensure=>:directory, :loglevel=>:debug, :links=>:follow, :backup=>false}' >> > > [...] > > If the (elided) log messages presented were *all* the log messages > emitted, then they depict the agent applying an empty catalog, which is of > course consistent with not changing anything. All the resources shown are > generated locally by the agent. You should be able to confirm that by > looking at the catalog itself, which you will find, by default, in a file > in /opt/puppetlabs/puppet/cache/client_data/catalog. > > If you're making changes to your manifest set but not seeing any effect at > the agent then there are several possibilities, but the most likely issue > is server-side caching. Before tweaking the cache configuration, however, > the easiest way to test this hypothesis is to flush the cache by restarting > the puppetserver service on the master. (That's not the only way, but it's > quick and easy, and you don't need to learn anything new to do it.) > > If that indeed solves the problem then you'll want to adjust the > environment_timeout > <https://puppet.com/docs/puppet/latest/configuration.html#environmenttimeout> > configuration setting on the master. For the time being, I would suggest > setting it to 0 to disable caching altogether. This is also supposed to be > the default if the setting is not explicitly specified, however. > > --- > > If that doesn't turn out to be the issue, then do have a look at the > master's logs. You should confirm that it is logging catalog requests from > the agent in question (else they must be going to a different master), and > you should look for any messages providing a clue about the issue. It may > be helpful to turn up puppetserver's log level to get more detailed > information. > > If that's also unavailing then my last suggestion would be to confirm that > the puppetserver process can successfully access everything in the > environment directory. Check file ownership, mode, ACLs, SELinux context, > and anything else that affects whether the puppetserver can read the files > and traverse (all) the directories. I would pay special attention to your > one manifest file, because that's the most likely one to be messed up in > this regard. > > > 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/558c4849-87b4-41d9-b5a7-97e3e7e0896c%40googlegroups.com.