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 support@cloudamqp.com 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.
I simply do not believe it was not possible to make a panel including women with relevant things to say.
You should research “manel” .... you’ll find “no women applied to speak” is almost always the excuse and it’s really inadequate and just a way to try to literally excuse the outcome. You have a much greater obligation than to just wait for applicants and then shrug and say “wel no women applied”.
It’s very silly to say you value diversity with a panel of all men, whilst pointing to the people who organized the conference to say that’s your diversity. “All the brainy men are doing the talking and being smart while all the assistants and helpers and organizers and running around helping them”. Ugh. I’d advise you to put that line of argument in the nearest garbage bin... it is not going to lead to people thinks “oh yes they employ women, that is an excellent and inclusive diversity strategy and shows deep commitment to diversity”. That’s like saying “hey I have a mother, that’s my diversity strategy”.
If you want to save your conference from possible cancellation then it’s in your interest to replace 2 of those men with at least 2 women before the internet gets wind of this.
And when asked, don’t make the lame excuse you gave me.... you should say “yes that’s a terrible mistake we handled it badly and were fixing it fast.” It sounds stupid to say “we couldn’t get any women”.
And it sounds doubly stupid and deeply patronizing to say “we deeply value diversity, look at all our helper women”.
Frankly sir you seem to lack wisdom.
And you’re in for a big shock if you think you’ll get to the end of this conference with only me raising the issue.
If I were you I’d take all information regarding the panel offline and say you’re revising it, until you fix it properly. That might save you.
> 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).
> 10k/s is no problem for RabbitMQ, even on aws t2 machines
Sending them from themselves to themselves you can do even better than that. Loopbacks aren't useful metrics for message passing. http://bravenewgeek.com/tag/rabbitmq/ is the most recent attempt to benchmark the various solutions (that I have found) and my own testing results in slightly less than the results shown...which I can only attest to unfamiliarity with RMQ, Kafka, etc. In the end, ease of maintenance only speaks to the weaknesses of solutions that need tweaking for specific topologies.
Yeah aware of ElephantSQL but the concern is lack of SLA and lack of big company backing. If you guys disappear, what happens to my databases since they run on your subscription, not mine. Hence why having an IBM backed Postgres on Azure is attractive - even though big companies can be frivolous, there's a comfort in knowing they're less likely to go out of business.
Yes, I've talked to them and nearly ended up going the wire transfer route. But using a credit card and reimbursing myself ended up being easier and cheaper.
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.
