All-
I'm using puppet (open source) 3.7.5 on our master (RHEL6.6, x86_64) and all clients (RHEL 5.x, RHEL 6.x, RHEL 7.x). I'm refreshing the hardware on our puppet master, and wanted to take the opportunity to switch the master to RHEL 7 (and therefore new Ruby and some ruby libraries). I'm sticking with puppet 3.7.5 during the hardware/OS refresh. I've been through upgrades on the puppet master before, and have found the "Option 1: spin up a temporary master" section of https://docs.puppetlabs.com/guides/install_puppet/upgrading.html to be very useful. After copying /etc/puppet (including our version-controlled modules) and /var/lib/puppet/ssl from the production RHEL 6 master to the replacement RHEL 7 master, and starting puppet on the new master as recommended: puppet master --no-daemonize --verbose I've gone through every one of our puppet clients and run puppet agent --test --noop # against current production puppet agent --test --noop --server new-master Both the old master and the new master return identical catalogs for every client ... except one. On one client, it appears that the *client* may be closing the connection very shortly after supplying facts to the new master. I've run both the new master and the client with --debug, and there's no obvious error messages or output that would indicate what the source of the problem is. The client only says: $ sudo puppet agent --test --noop --server new-server Info: Retrieving pluginfacts Info: Retrieving plugin Info: Loading facts Error: Could not retrieve catalog from remote server: Broken pipe Warning: Not using cache on failed catalog Error: Could not retrieve catalog; skipping run This client happens to be our largest, as far as # of resources (about 1700, mostly because of a bunch of web proxy lines added to a httpd config file via a define() and concat). The old master takes a while to compile the catalog (so much so that I sometimes have to specify --configtimeout=300 on the client when communicating with the old master), but it does reliably compile and deliver the catalog. The communication between the client and the new master breaks very quickly (within a few seconds), so it's not the same timeout causing the issue. Any suggestions for how I proceed with debugging this issue? I can provide the output from --debug for both the new master and the client, if anyone is interested in looking through it. Thanks, Tim -- Tim Mooney tim.moo...@ndsu.edu Enterprise Computing & Infrastructure 701-231-1076 (Voice) Room 242-J6, Quentin Burdick Building 701-231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164
