yes, a bunch of older clusters were affected by this. They included an intermediate of USERTrust that was signed by AddTrust, clients that didn't check for alternate chains would then fail. We pushed the new chain (which now only includes the server cert and the Sectigo RSA cert), and dynamically reloaded the TLS listener in RabbitMQ, it should have solved it for most ppl, email [email protected] if it didn't for you. We're sorry we didn't pushed this earlier. We were aware that the AddTrust would expire during the life time of the server certificate, but we assumed that all TLS client would find the valid chain regardless, that assumption was obviously wrong.
Where is the sole number used for authentication? We got the same number in Sweden but the number is not secret, you need it combination with something else like an ID, signature, digital signature etc.
Thanks for pointing that out! We would, of course, love to have female speakers on the summit. We had an open call for talks, which was promoted on the web, Twitter, newsletters etc., but there were only male speakers applying, unfortunately.
In the talks committee, Dormain Drewitz (who leads Product Marketing at Pivotal) and Lovisa Johansson (Marketing Manager / Software Developer at CloudAMQP), two female professionals highly experienced in RabbitMQ, was participating in choosing the speakers. In terms of the panel discussion, it will be lead by Dormain.
Lovisa is very skilled in RabbitMQ, and has written ebooks, technical documentation and tons of blog posts on the topic. However, she couldn’t participate as a speaker or in the panel discussion since she will have other commitments during the summit.
Diversity is a high priority for us, and we have a lot of females working behind the scenes as project leaders managing the summit.
> This initial approach, at least, does not cache the intermediate CNAMEs nor does it care about the CNAME TTL values.
That's a total violation of the standard and will break A LOT of things. Example: my.domain.com -> CNAME ec2-1-2-3-4.aws.com 30s TTL -> A 1.2.3.4 30days TTL.
So Firefox will now cache my.domain.com to 1.2.3.4 for 30 days? When you update the record for my.domain.com the change today will be applied in 30s, but with this flawed heuristic it won't expire until after 30 days.
Setting up Dovecot (with master-master replication) and Postfix (+ spamassassin, dmarc, SPF) isn't too bad. There's a lot of dated guides out there though. Stick to the man pages as far as possible.
10k/s is no problem for RabbitMQ, even on aws t2 machines. Where did you get that from? 50k msgs/s is no problem on an aws c3.xlarge instance (single queue, auto-ack and transient messages).
Finally, it's crazy that they've haven't implemented this earlier, and why isn't it enabled by default, like on GCE? We've had for a long time an app that just polls the ec2 api and looks for impaired instances and then automatically restarts them. We have about 2-10 impaired/scheduled-for-reboot/on-deprecated hardware-instance per month so that app is quite a time-saver.
No, if I choose Sequel (http://sequel.jeremyevans.net) I want to use all the power it gives me, not some lowest common denominator.. Also not all projects needs models, you know, there's other data access patterns..