On Wednesday, August 26, 2015 at 9:22:05 PM UTC-5, Chuck Amadi wrote: > > Hi I Setup a Open Source Puppet Master and a Puppet Agent client on Linux > CentOS release 6.6, Puppet 3.8.1 on two separate servers. > > Have successfully setup communications between both servers (cert > list/sign/fingerprint etc etc and telnet 8140, disabled SELinux and added > iptables 8140 rule) and I have created and run "puppet apply site.pp" > node.pp and a init.pp/class no errors. >
You don't necessarily need to disable SELinux to use Puppet, though you may need to add appropriate SELinux policy. In any case, if SELinux were interfering with Puppet then you would see failure diagnostics in Puppet's log / console output. Also, it is atypical for one site to use both 'puppet apply' and 'puppet master' / 'puppet agent' to obtain and apply catalogs. If you are going to operate a puppet master, then it is more usual to run the agent service on the master than to use 'puppet apply' there. > > Thus run "puppet master --verbose --no-daemonize" on the PM and "puppet > agent -t --debug" on the client and I do not receive any errors when I run > # puppet apply site.pp or node.pp etc or see any issues when I run tail on > the masterhttp.log file. > > Perhaps you are confused about the nature of the master / agent setup. Since you keep bringing up the 'apply' face, I wonder whether you are under the impression that the agent serves to synchronize Puppet manifests (.pp files), which could later be used with 'puppet apply'. This is not the case. In an agent / master setup, the master is responsible for compiling digested "catalogs" for each agent based on manifest files and data residing on the master and node-specific facts provided by each agent. The agent receives these catalogs from the master and applies them. In contrast, 'puppet apply' compiles catalogs from local manifests, data, and facts, and applies the result. The 'apply' and 'agent' faces are alternatives, not complements. > Test files specified in site.pp and node.pp are created on the Puppet > Master but do not replicate to the Node ? > > Puppet node does not pick any changes from master's catalogs when I > forcibly restart puppet client or run puppet agent instead of waiting 30 > mins, even though the "Info: Applying configuration version '1440626773'" > number changes accordingly. Further information below: > > # puppet master --verbose --no-daemonize > > Info: access[/file_metadata]: adding authentication any > Info: Inserting default '/status' (auth true) ACL > Info: Caching node for chat.client.com > Info: Caching node for chat.client.com > Notice: Compiled catalog for chat.client.com in environment production in > 0.04 seconds > > # puppet agent -t --debug > > Debug: Creating default schedules > Debug: Loaded state in 0.00 seconds > Info: Applying configuration version '1440626773' < changes > > Debug: Finishing transaction 69904202860300 > Debug: Storing state > Debug: Stored state in 0.03 seconds > Notice: Finished catalog run in 0.13 seconds > Debug: Using cached connection for https://puppet.master.com:8140 > Debug: Caching connection for https://puppet.master.com:8140 > Debug: Closing connection for https://puppet.master.com:8140 > > Any help or advice to troubleshoot on why Puppet node does not pull any > changes from master's site.pp and node.pp manifest. I'm ignoring the Module > classes I have created for now. > > It appears that the catalog received by the agent contains no out-of-sync resources. Given the timing, it may contain no resources at all. If you changed the site manifests after starting the master, then you may be experiencing a caching issue. Restart the master after making manifest changes to ensure that the new version of the manifest is used. Also, consider providing a 'default' node block with distinctive resources / behavior. That could help you verify that you are getting the right node block. And consider declaring Notify resources at strategic places in your manifests, such as at top scope and within each node block. Applying these emits the specified message into the agent's log output, so they can serve in Puppet's version of debugging via print statements. It may also be that the master is not looking for its manifest files in the same place that 'apply' did when run on the same machine, especially if you ran 'apply' as an unprivileged user. 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/5a7e3241-3671-4017-ba94-963c47d0e065%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
