1,147 karma · joined August 22, 2013
Here's a picture of a native session running (on sdf.org)
https://pbs.twimg.com/media/DG0_h-eU0AEFy_7?format=jpg&name=...
https://en.wikipedia.org/wiki/Qmail#Security_reward_and_Geor...
Never seen my IP show up anywhere but it's generally not very interesting to begin with :P
These are managed devices and you can't really approach them as you'd approach a traditional standalone AP or router.
My assumption is that it's the editor's implementation, but I found it interesting that the use of these fonts (or at least, proper implementation thereof) seems to lean heavily towards Javascript.
Or am I missing something here?
(FWIW I'm a fan of italics for comments - here's what my setup looks like https://imgur.com/a/jTXHIo2)
I also have piracy.
On the front end I have two 1Gbit circuits (AT&T and Google) going into an OPNSense instance doing load-balancing and IPS running on a Dell R320 with a 12-thread Xeon and 24GB of RAM
Services are hosted on a Dell R520 with 48GB RAM and two 12-thread Xeons running Ubuntu and an up-to-date ZFS on Linux build.
Media storage handled by two Dell PowerVault 1200 SAS arrays.
Back-end is handled by a Cisco 5548UP and my whole apartment is plumbed for 10Gbit.
It's worth pointing out that AWS Elasticsearch is not simply the open distro - and a lot of things you see in the open distro are not currently available on AWS Elasticsearch. Beyond that, many features are simply forcibly disabled in Amazon's offering, just as many cluster settings and APIs are untouchable in the AWS service (even read-only ones that would be super helpful).
I still can't touch any of the rebalancing settings on my clusters and everything looks forcibly disabled. If rebalancing worked as expected, the whole blue-green thing shouldn't be necessary, and over time, I wouldn't generally end up with a single full data node while every other node in the cluster has 300GB free. Am I missing something?
None of the CloudWatch alarms you linked to have much relevance to the issues in the article (Other than the ClusterIndexWritesBlocked alarm which will only start firing after everything breaks). As of the last time I looked, you cannot monitor disk space on individual nodes in CloudWatch, only the cluster as a whole. Alerting on a single node starting to fill up is basically the one alert that would let me know things are about to be in a bad state.
Their service seems to work well for small implementations that use EBS-backed storage, and I bet that's what most of their customers are using, but I'm running 60+ node clusters and the problems only seem to be worse as capacity goes up.
Someone in the comments here mentioned they destroy and rebuild their cluster weekly just to keep the shards balanced. How ridiculous is it for that to be the best option offered?
That said, it's worth pointing out that EBS is the default data store in AWS Elasticsearch, and for people without a ton of data it might actually end up working "as intended"
It's also worth mentioning that newlines are significant in TCP syslog (for batching log messages) but not in UDP syslog (because of frame size limits)