search

olopez32 / ganeti

Automatically exported from code.google.com/p/ganeti
0 stars 0 forks source link

gnt-backup SSL3_CHECK_CERT_AND_ALGORITHM:dh key too small #1104

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
What software version are you running? Please provide the output of "gnt-
cluster --version", "gnt-cluster version", and "hspace --version".

gnt-cluster --version
gnt-cluster (ganeti v2.12.4) 2.12.4

gnt-cluster version
Software version: 2.12.4
Internode protocol: 2120000
Configuration format: 2120000
OS api version: 20
Export interface: 0
VCS version: (ganeti) version v2.12.4

hspace --version
hspace (ganeti) version v2.12.4
compiled with ghc 7.6
running on linux x86_64

What distribution are you using?

lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:    Debian GNU/Linux 8.1 (jessie)
Release:    8.1
Codename:   jessie

What steps will reproduce the problem?
1. gnt-backup export -n <node> <instance>

What is the expected output? What do you see instead?
The Instance should be exported.

I see:
gnt-backup export -n <host> <instance>                                          

Tue Jun 16 20:02:23 2015 Shutting down instance <instance>
Tue Jun 16 20:02:38 2015 Creating a snapshot of disk/0 on node <host>
Tue Jun 16 20:02:39 2015 Starting instance <host>
Tue Jun 16 20:02:40 2015 Exporting snapshot/0 from <host> to <host>
Tue Jun 16 20:02:43 2015 snapshot/0 is now listening, starting export
Tue Jun 16 20:02:52 2015 snapshot/0 sent 0M, 0.0 MiB/s
Tue Jun 16 20:02:57 2015  - WARNING: export 
'export-disk0-2015-06-16_20_02_44-3TsJoI' on <host> failed: Exited with status 1
Tue Jun 16 20:02:58 2015 snapshot/0 failed to send data: Exited with status 1 
(recent output:   DUMP: Date of this level 0 dump: Tue Jun 16 20:02:45 2015\n  
DUMP: Dumping 
/dev/mapper/vgData-9e7bc76b--e91d--4c59--a95b--1a57055a232b.disk0.snap-1 (an 
unlisted file system) to standard output\n  DUMP: Label: none\n  DUMP: Writing 
10 Kilobyte records\n  DUMP: mapping (Pass I) [regular files]\nsocat: E 
SSL_connect(): error:14082174:SSL routines:SSL3_CHECK_CERT_AND_ALGORITHM:dh key 
too small\n  DUMP: mapping (Pass II) [directories]\n  DUMP: estimated 2094960 
blocks.\n  DUMP: Volume 1 started with block 1 at: Tue Jun 16 20:02:57 
2015\ndd: dd: error writing 'standard output': Broken pipe\n  DUMP: Broken 
pipe\n  DUMP: The ENTIRE dump is aborted.)
Tue Jun 16 20:02:58 2015 Removing snapshot of disk/0 on node <host>
Tue Jun 16 20:03:00 2015  - WARNING: Aborting import 
'import-disk0-2015-06-16_20_02_40-K1OqMQ' on 
6d8500c2-9921-44b4-a5e5-a445a6f691ac
Tue Jun 16 20:03:02 2015  - WARNING: import 
'import-disk0-2015-06-16_20_02_40-K1OqMQ' on <host> failed: Exited due to 
signal 15
Tue Jun 16 20:03:02 2015 snapshot/0 failed to receive data: Exited due to 
signal 15 (recent output: socat: W exiting on signal 15)
Tue Jun 16 20:03:02 2015  - WARNING: Some disk exports have failed; there may 
be leftover data for instance <instance> on node <host>
Failure: command execution error:
Export failed, errors in export finalization, disk export: disk(s) 0

Thanks
Thomas

Original issue reported on code.google.com by lordot...@gmail.com on 17 Jun 2015 at 11:54

GoogleCodeExporter commented 9 years ago

Original comment by hel...@google.com on 17 Jun 2015 at 2:21

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
This workaround breaks connections between nodes and ganeti itself:
# gnt-instance list
Timeout while talking to the master daemon. Jobs might have been submitted and 
will continue to run even if the call timed out. Useful commands in this 
situation are "gnt-job list", "gnt-job cancel" and "gnt-job watch". Error:
Connect timed out

restarting services/nodes didn't help

Original comment by anatoliy...@gmail.com on 20 Jun 2015 at 5:10

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
I can confirm that the workaround works, but I didn't need to restart any 
daemons.

Original comment by serverha...@gmail.com on 22 Jun 2015 at 8:30

GoogleCodeExporter commented 9 years ago 
I tried it on Scientific Linux 7.1 and it failed (as I wrote before).
Maybe I do something wrong:
- Do you generate dhparams.pem on master node only or do you do it on each node 
(and as the result server.pem becoming unique on every node)?
- Does it matter where you save dhparams.pem - can it be any directory?

Original comment by anatoliy...@gmail.com on 22 Jun 2015 at 8:39

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
Because of logjam attack(https://weakdh.org/) - there must be generated dh 
params file:

On master node:
openssl dhparam -out dhparams.pem 2048
and then added to server.pem on master node:
cat dhparams.pem >> /var/lib/ganeti/server.pem

And then duplicate it to every node.
Restart was not needed, but i restarted cluster too to confirmation.

Original comment by andrzejd...@gmail.com on 22 Jun 2015 at 2:10

GoogleCodeExporter commented 9 years ago 
This is how it looks in logs when new server.pem is on all nodes: 
==========================
ganeti-luxid: No voting RPC result from [“node2”,”node1”]
ganeti-wconfd: Error in the RPC HTTP reply from 'Node {nodeName = “node2”, 
nodePrimaryIp = “xxxxxx”, nodeSecondaryIp = “xxxxx”, 
nodeMasterCandidate = True, nodeOffline = False, nodeDrained = False, nodeGroup 
= “yyyyyyy”, nodeMasterCapable = True, nodeVmCapable = True, nodeNdparams = 
PartialNDParams {ndpOobProgramP = Nothing, ndpSpindleCountP = Nothing, 
ndpExclusiveStorageP = Nothing, ndpOvsP = Nothing, ndpOvsNameP = Nothing, 
ndpOvsLinkP = Nothing, ndpSshPortP = Nothing, ndpCpuSpeedP = Nothing}, 
nodePowered = True, nodeCtime = Tue May 19 14:36:24 CEST 2015, nodeMtime = Tue 
May 19 14:36:24 CEST 2015, nodeUuid = “zzzzzzz”, nodeSerial = 1, nodeTags = 
fromList []}': CurlLayerError "code: CurlCouldntConnect, explanation: Failed 
connect to xxxxxx:1811; Connection refused"
ganeti-luxid: Error in the RPC HTTP reply from 'Node {nodeName = “node2”, 
nodePrimaryIp = “xxxxxx”, nodeSecondaryIp = “xxxxxxx”, 
nodeMasterCandidate = True, nodeOffline = False, nodeDrained = False, nodeGroup 
= “zzzzzzzz”, nodeMasterCapable = True, nodeVmCapable = True, nodeNdparams 
= PartialNDParams {ndpOobProgramP = Nothing, ndpSpindleCountP = Nothing, 
ndpExclusiveStorageP = Nothing, ndpOvsP = Nothing, ndpOvsNameP = Nothing, 
ndpOvsLinkP = Nothing, ndpSshPortP = Nothing, ndpCpuSpeedP = Nothing}, 
nodePowered = True, nodeCtime = Mon May 18 12:05:29 CEST 2015, nodeMtime = Mon 
May 18 12:05:29 CEST 2015, nodeUuid = “zzzzzzzzz”, nodeSerial = 1, nodeTags 
= fromList []}': CurlLayerError "code: CurlSSLCACertBadFile, explanation: "
==========================

CurlLayerError "code: CurlSSLCACertBadFile" - I guess something wrong with new 
server.pem format.
It looks like:
# grep '\----' server.pem
-----BEGIN PRIVATE KEY-----
-----END PRIVATE KEY-----
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----
-----BEGIN DH PARAMETERS-----
-----END DH PARAMETERS-----

Original comment by anatoliy...@gmail.com on 23 Jun 2015 at 12:09

GoogleCodeExporter commented 9 years ago 
Hi!

I have been trying to look into why the workaround does not work for you, 
especially because it seems like the correct solution to the problem, and one 
we would like to deploy if it does not break people's clusters.

Could you tell me anything about the versions of the following: Ganeti, PycURL, 
OpenSSL, and GnuTLS? I will assume the packages are the same as in RHEL.

Cheers,
Riba

Original comment by r...@google.com on 23 Jun 2015 at 2:15

GoogleCodeExporter commented 9 years ago 
Hi,

Thanks for the help!

openssl.x86_64                        1:1.0.1e-42.el7_1.8          
openssl-libs.x86_64                   1:1.0.1e-42.el7_1.8         
gnutls.x86_64                         3.3.8-12.el7                 
python-pycurl.x86_64                  7.19.0-17.el7

# gnt-cluster version
Software version: 2.12.4
Internode protocol: 2120000
Configuration format: 2120000
OS api version: 20
Export interface: 0
VCS version: (ganeti) version v2.12.4

Ganeti packages are from http://jfut.integ.jp/linux/ganeti/7/x86_64/

Original comment by anatoliy...@gmail.com on 24 Jun 2015 at 9:12