I started using it after getting frustrated with Gitlab's install process on RHEL (a year ago), and I used Gitolite before that. Gitblit has been refreshingly simple to deal with. Am I missing something other than the standard JVM hate?
Cloudwatch does what you're referring to as well. It's more of a basic server monitoring system that happens to integrate with the load balancer.
You get a set of basic VM level metrics, and you can feed it custom metrics from your app, or log files. All of which can be configured to alarm. I don't think it's possible to run advanced statistics on the metrics for alarming (eg, standard deviation from 30 minute exceeds N), but it may be. Usually it's just an event count, like more than N 500 errors over X time.
I do agree you need to think deeper than basic health checks though, 'broken server' is always a hard boolean to nail down.
I think the problem is clustering is still very much a duct-tape situation in postgresql with no real clear consensus on how to build out a cluster.
Postgres-XL looks great for scale out, but you need 4 independent types of servers. Even with all those moving parts, it doesn't provide availability. If you want fail-over, you need pacemaker for the data nodes with traditional sync replication, and something like VRRP for your balancer, and something else to failover the coordinator. Several of these pieces can be tricky to set up in a cloud provider.
BDR looks nice, but it looks like there could be lots of gotchas for consistency in there. Maybe it is a magic bullet though... I don't know much about it yet.
Contrast with something like rethinkdb, mysql-galera, cassandra, etc, you start up enough nodes for quorum, tell them about each other, and you're pretty much done. The clients can handle the balancing, or you can use a pooler/balancer.
In my perfect world, I'd install postgresql-awesome-cluster-edition on 3 nodes, add the 3 IPs (or turn on multicast discovery, if my env can support it), and away we go for read scalability and availability. I do this today for mysql-galera, and other than the fact it's mysql, it's awesome. For writes, if you add 4 or more nodes, there should be some sort of shard system like XL has.
That said, postgresql is still clearly the best SQL and even noSQL single node server out there, it's a really great piece of software.
So you think recompiling OpenSSL from scratch, in doing so, deviating from the upstream vendor's supported binaries, and the dependency problems with updates it will cause, just to support a mostly smoke and mirrors standard is a good idea? I'd don't really think that's a best practice in commercial or government IT.
"So at this moment we cannot say whether mod_ssl is going to be a valid crypto module in FIPS mode under RHEL-6 although this is the intent."
That may have changed, and contradict other sources on redhat.com. There are a lot more KB articles on FIPS since the last time I really dug into it over a year ago.
Edit, yes, it looks like it was mod_nss only until the release of RHEL 5.9 last Jan. RHEL-6 was ongoing, but it looks like they claim mod_ssl will work now in other places in the knowledge-base.
FIPS is just one area where it seems like there's a lot of contradictory information for federal IT. After doing the FedRAMP dance, and reading things to the letter, we stopped working towards it and partnered with one of the vendors that got it first. Their remote access was plain text VNC, 8 character password max. I would say I was surprised the paperwork matters more than real security, but I wasn't.
I'm your counterpart at another agency. I'm glad to see other agencies are not doing FIPS on their websites (Which would be RHEL with mod_nss only). I'm a bit confused though, last I looked FedRAMP still required it. Have the mandates been changed?
So in other words, become a FB/Twitter/Play/App store and put yourself at the top of the pyramid. Now you get to be the company changing the API and banning users, but we still haven't actually solved the problem for the users of web services.
I just posted a similar comment above. It seems like the time is right for an open source advanced chat server. Maybe there already is one, I just don't know of it yet.
Are any of these available for companies that can't ship all their internal conversations and files to the cloud? Are XMPP/IRC and overpriced 'enterprise' suites still the go to for private chat?
I must be missing something, but it seems like CoreOS is just etcd and vanilla docker. I do like the idea of etcd, but is there some sort of API to control docker with it?
Entire groups of people at MS have clearances. Their software runs large chunks of the DOD, they can and do put consultants on site in secured locations when needed. Who else is going to fix an exchange cluster that has been mis-configured by a lowest bidder tech?
It's not knowing about them, it's being able to defend them. A gray area loophole is much safer to exploit if you have a large legal team to back up your interpretation.
I'm not going to comment on the security of giving somebody an ssh key to your root account... But it's a good idea to look at something like puppet to do this.
I started using it after getting frustrated with Gitlab's install process on RHEL (a year ago), and I used Gitolite before that. Gitblit has been refreshingly simple to deal with. Am I missing something other than the standard JVM hate?