#mcollective

[mcollective-sshkey-security] bobtfish opened pull request #7: Add additional flexibility to handling ssh keys (master...env_variables_for_client_config) http://git.io/n7s9vg

[mcollective-sshkey-security] bobtfish opened pull request #8: Cache known hosts file to improve performance when you have 1000s of hosts. (master...cache_known_hosts) http://git.io/_BZT5A

are you aware of a problem that rabbitmq on EL6.5 does not work with the puppet ssl certs? https://ask.puppetlabs.com/question/14264/getti...

and is there a solution for that? Besides activemq or patching rabbitmq (acutally erlang)

duritong_: tried 2.6.1 and specifying protocols

without seeing the output from the rabbitmq logs it's impossible to say exactly what the problem is, but typically it's that openssl is using an incompatible set of ciphers

and we have a handle for that now. https://docs.puppetlabs.com/mcollective/referen...

looks like I need to fix some markdown there. oopos

almost certainly ciphers

duritong_: ran into this myself the other week. Short answer is generate your puppet certs using an older master that doesn't support SHA256 (e.g. 2.7 worked for me)

optiz0r: that option will let you upgrade your stomp gem now

_rc: sweet!

_rc: is that in 2.6.1?

plugin.rabbitmq.pool.1.ssl.ciphers = ALL:!SSLv2:!SSLv3:!MD5:!SHA256

yes

it'll be something like that, but you need to experiment

lovely, thanks :)

and once you know what it is please drop by for future users

[marionette-collective] richardc pushed 1 new commit to master: http://git.io/IGhdqA

marionette-collective/master c69a219 Richard Clamp: maint - add missing url to connector_rabbitmq...

optiz0r: actually I've just remembered what your issue was, so that may not be the fix for you. I had you and fubada crossed in my brain.

optiz0r: it *might* be a mechanism that fixes it for you by disabling sha256-using ciphers, but it may still come down to the cert that is issued

I have a strange (to me) issue. Running ubuntu 12.04, mcollective 2.6.0-1puppetlabs1. When I use a fact filter (mco ping -F fact=foo) and logging is set to info, nodes do not respond. If I change logging level to debug, they do. I have switched back and forth on 2 different nodes and it is perfectly reproducible.

To be clear, changing logging level to debug in server.cfg

so if you switch one and not the other do you get one response?

Correct. Also, it holds true whether I run mco ping from the systems themselves, or a third machine.

can you shhare logs and config.

Config: http://pastebin.com/KfxK0xmb LOG: http://pastebin.com/X1L7iM5Y

and with it not at debug?

also please check the rabbitmq logs

it could simply be the facter factsource being terrible

Info level log: http://pastebin.com/YByVvBCW

There's nothing in the info log when the ping happens, just the startup blurb.

well no, unless it errors that's just going to be at debug level so that's fine

try sending it a USR2 twice