On Friday, 6 July 2012 10:19:10 UTC+1, Martin Alfke wrote:On 06.07.2012, at 11:09, Martinus wrote:
There is nothing to clean, as "puppet cert --list" or "puppet cert --list
--all" does not have an entry for those 3 particular servers.
Deleting the client side ssl* makes no difference either. The client will
recreate the ssl (good) and the same error pops up, without anything
showing up on the master (puppet cert --list).
And that is why I thought there is a communication problem. But here is
the tcpdump output to show that they are talking:
09:01:57.812646 IP my_client.46516 > my_server.8140: Flags [S], seq
1288389639, win 14600, options [mss 1460,sackOK,TS val 1052151283 ecr
0,nop,wscale 4], length 0
09:01:57.812700 IP my_server.8140 > my_client.46516: Flags [S.], seq
300735116, ack 1288389640, win 14480, options [mss 1460,sackOK,TS val
38287565 ecr 1052151283,nop,wscale 4], length 0
09:01:57.814298 IP my_client.46516 > my_server.8140: Flags [.], ack 1, win
913, options [nop,nop,TS val 1052151283 ecr 38287565], length 0
09:01:57.814686 IP my_client.46516 > my_server.8140: Flags [P.], seq
1:175, ack 1, win 913, options [nop,nop,TS val 1052151283 ecr 38287565],
length 174
09:01:57.814715 IP my_server.8140 > my_client.46516: Flags [.], ack 175,
win 972, options [nop,nop,TS val 38287566 ecr 1052151283], length 0
09:01:57.815226 IP my_server.8140 > my_client.46516: Flags [P.], seq 1:8,
ack 175, win 972, options [nop,nop,TS val 38287566 ecr 1052151283], length 7
09:01:57.815378 IP my_server.8140 > my_client.46516: Flags [F.], seq 8,
ack 175, win 972, options [nop,nop,TS val 38287566 ecr 1052151283], length 0
09:01:57.816686 IP my_client.46516 > my_server.8140: Flags [.], ack 8, win
913, options [nop,nop,TS val 1052151284 ecr 38287566], length 0
09:01:57.816884 IP my_client.46516 > my_server.8140: Flags [F.], seq 175,
ack 9, win 913, options [nop,nop,TS val 1052151284 ecr 38287566], length 0
09:01:57.816894 IP my_server.8140 > my_client.46516: Flags [.], ack 176,
win 972, options [nop,nop,TS val 38287566 ecr 1052151284], length 0
As an additional note, when I stop apache and start puppetmaster with its
inbuilt web server, then these 3 clients are happy.
Are the client working after you have enabled them using webrick
puppetmaster?
We are working with nginx and passenger and we needed the following in
puppet configuration [master]:
ssl_client_header = HTTP_X_CLIENT_DN
ssl_client_verify_header = HTTP_X_CLIENT_VERIFY
Martinus.
On Friday, 6 July 2012 09:46:38 UTC+1, Martin Alfke wrote:On puppet master:
puppet cert --clean <fqdn>
on client:
rm -fr /var/lib/puppet/ssl/*
puppet agent --test
check on master for signing request:
puppet cert --list
On 06.07.2012, at 10:25, Martinus wrote:
Martin,
Right.
Time is good (NTP) on all 3 clients and server. And I double checked
just now with ntpq -p (largest offset was -20). There are different time
zones, but then so has the working systems different time zones.
Ruby version on all 3 clients and server: ruby 1.8.7 (2011-06-30
patchlevel 352)
The SSLDir line looks like this: "ssldir = /var/lib/puppet/ssl" on all
systems (config file is copied across systems). I checked, and the
standard set of directories are there and owned by Puppet.
However, crl.pem is not present like on the working systems.
Martinus.
On Friday, 6 July 2012 09:07:46 UTC+1, Martin Alfke wrote:Hi,
- check time on client and server
- check ruby version on the 3 server which fail
- check SSLDir configuration in /etc/puppet/puppet.conf on the 3 systems.
Martin
On 06.07.2012, at 09:57, Martinus wrote:
I have a problem on 3 out of ~40 servers that gives the following error:
err: Could not request certificate: SSL_connect returned=1 errno=0
state=unknown state: sslv3 alert handshake failure
From previous posts, I made sure that SSLVerifyClient is set to
optional. I also cleared /var/lib/puppet/ssl/ client side, not that it
should make any difference as this error is on the first run of Puppet.
When I try to run Puppet from either of these 3 servers, there is
nothing noted in /var/log/apache2/* server side. I have confirmed
networking is ok with telnet and also checked that there is traffic with
tcpdump.
Puppet server is at 2.7.11 and client is also at 2.7.11 both from Ubuntu
repositories.
Any help would be appreciated to find why these 3 particular servers is
giving me problems.
--
You received this message because you are subscribed to the Google
Groups "Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/mzcj4gN-AWQJ.To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en. --
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/ksgzsaL9g1MJ.To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en. --
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/NsecfOnGBsgJ.To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en. You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
