Puppet users - May 2013 - POssible incompatibility between puppet agent 3.0.1 and puppet master 3.0.2

Dear All,

I am using puppet agent v3.0.1 (On FreeBSD), trying to connect to a puppet 
master v3.0.2 (On Ubuntu) and the puppet agent hangs with the following 
debug output:

*puppet agent --debug --no-daemonize*
...
Debug: /File[/var/puppet/ssl/private_keys]: Autorequiring 
File[/var/puppet/ssl]
Debug: /File[/var/puppet/ssl/private]: Autorequiring File[/var/puppet/ssl]
Debug: /File[/var/puppet/ssl/private_keys/zg-3.XXXX.ch.pem]: Autorequiring 
File[/var/puppet/ssl/private_keys]
Debug: /File[/var/puppet/ssl/public_keys/zg-3.XXXX.ch.pem]: Autorequiring 
File[/var/puppet/ssl/public_keys]
Debug: Finishing transaction 17214983260
[hangs.. and a minute os so later reports..]
Error: Could not request certificate: execution expired
Error: Could not request certificate: execution expired

These is no indication of a connection being made on the puppet master.

1. I have checked with netcat & telnet and confirmed that I able to 
initiate a connection from the agent to the server and exchange data.

2. The same puppet master has worked correctly with a different FreeBSD 
agent running Puppet v3.0.2

3. Running tcpdump during the agent run shows that some packets are going 
back and forth between the agent and server

4. I have run truss on the (FreeBSD) puppet agent command and saw that the 
agent is getting the following error (twice):

  read(6,0x80711c3c6,1854)                         ERR#35 ''Resource 
temporarily unavailable''

File handle 6 is from a ''connect'' to the puppet master, with
the correct IP
address and port number (8140)

5. I suspect an agent/master compatibility issue, or perhaps an sl library 
compatibility. I don''t think it''s an SSL certificate (no
certificate
related errors) or time synchronization problem (both systems run NTP).

Any hints on how to debug this? 

Thanks in advance,

Alan Hodgkinson

P.S. Please ask for any (config) information necessary to help diagnose the 
problem.

-- 
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+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

SOLVED: The problem was caused by small MTU size on the puppet
master''s ethernet port. The solution was to reduce the MTU size to
1400, with the command:

  ip link set eth0 mtu 1400.

The server was behind a firewall and communicated with outside world
through a Cisco ADSL Router, which had an MTU size of 1492.

We caught the problem by trying to scp a file of approx. 1500 bytes
from the puppet server to the client. The scp created an empty file
and then hung. This enabled us to eliminate puppet as the problem
source. Strangely other servers in the same zone also have MTU zone 1500 and
work fine.

-- 
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+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.