Sean Bannister's questions

Amazon Route 53 supports both "SPF Records" and "TXT Records". Most documentation I read tells me to list my SPF Record as a TXT Record. I understand that the SPF Record is a newer standard. Is it therefore correct for me to duplicate my SPF Records so they're listed as an SPF Records and a TXT Record to ensure backwards compatibility while also following the new standard? I'm unfamiliar with DNS so not sure if this would cause any problems or if I should even bother duplicating them?

My records are as follows:

"v=spf1 include:_spf.google.com include:amazonses.com -all"
"spf2.0/pra include:_spf.google.com include:amazonses.com -all"

I have an EC2 instance running mysql, the problem is every time an ec2 instance reboots it gets new local IP address. So I was wondering if I could just set bind-address in my.cnf to listen on all local interfaces which would allow it to work after a reboot.

I know could specify 0.0.0.0 but I'd prefer to only listen on local if possible, even though the firewall doesn't allow external connections.

I know that Amazon's Cluster GPU Instances have ECC memory as mentioned on their blog but there's no mention of other instance types. There's a forum post from back in 2007 that went unanswered. Does anyone know if they're running ECC?

Just been looking into Elastic Load Balancers. As I understand it they just do round robin, evenly distributing connections to the servers behind them. So what happens if you have different size instances behind an ELB? Does it send more connections to the larger instance or does it continue to evenly distribute the connections, which would mean you really shouldn't use different size instances.

I was reading the MongoDB install instructions and noticed they have a private repository that the instructions tell you to add. I'm wondering if this is really needed because MongoDB is also in the Ubuntu repository (Ubuntu 12.04). I was thinking maybe its easier for them to publish to their own repo compared to Ubuntu's? But I'm really not sure. Was just wondering if someone could shed some light on this.

I was just reading the GELF spec as I'm integrating it into our system. I was just wondering if an additional/custom field can contain a JSON object as the spec doesn't mention it:

So my GELF output (in particular the _request field below) would look something like:

{
  "version": "1.0",
  "host": "www1",
  "short_message": "Short message",
  "full_message": "Backtrace here\n\nmore stuff",
  "timestamp": 1291899928,
  "level": 1,
  "facility": "payment-backend",
  "file": "/var/www/somefile.rb",
  "line": 356,
  "_request": {
      "ip": "123.123.123.123",
      "url": "example.com/dir/file.ext",
      "method": "get",
      "referer" "example.net"
}

I've been thinking about data integrity, I currently backup about 2tb of data and always have one backup of data from a year ago.

My concern is if a file became corrupt on our production file server no one would notice because some files aren't accessed for many years and if corruption occurred I'd be backing up a corrupted file.

I'm not sure how I should handle this problem, is there a way to detect data corruption? Or is the only solution to store older backups in case something becomes corrupted and isn't noticed?

Short overview: Is Alert more severe than Critical.

RFC 5424 briefly defines syslog severity levels and gives a short description. Each syslog level is given a code 0 - 7. It was my understanding that 0 (Emergency) was most severe and 7 (Debug) was least.

However I'm questioning 1 (Alert) and 2 (Critical). The definitions in RFC 5424 are:

• Alert: action must be taken immediately
• Critical: critical conditions

However on this site they give a longer description (which is obviously personal opinion) but define them as:

• Alert: Should be corrected immediately - notify staff who can fix the problem - example is loss of backup ISP connection
• Critical: Should be corrected immediately, but indicates failure in a primary system - fix CRITICAL problems before ALERT - example is loss of primary ISP connection

This seems backwards as it implies that Critical is more severe than Alert even though the RFC 5424 seems to place Alert as more severe. I was just wondering if there's an official stand on this or any best practices?