I'll be sure to when I get to the data center next week and am able to get my hands on the angry switch in question. I do love how it just sat there quietly for two weeks w/o doing anything and then decided randomly to just start blasting out 20 Gbit.. sigh.. hardware..
Actually all browsers send the Accept-Encoding HTTP header, which AVG does not.. if you look at the rule you'll see that it checks for the existence of that head and only blocks if it doesn't exist.
That's the problem, once we can get a native v6 feed from Savvis we'll have v6 versions of the sites. The idea of running these sites via 6to4 makes me cringe.
It is correct. The Databases servers can go to another Quad Core in about 15 minutes however. For the most part, at least with Slash, the Databases are more i/o bound than CPU.
Yes, all machines have hardware RAID cards, even the webservers. The reason for RAID 5 vs 6 was purely a performance thing. Some sites choose to use RAID 10, some RAID 5+spare.
Ding, we/used/ to use them as layer 3 routers, but they couldn't keep up after the years and alas, they've been relegated to dumb layer 2 switches now. The poor cpu's can't keep up with anything else. We do have OOB serial management on them like you mentioned however.
Yes, all our servers are at least RAID1, as for email, this article was Slashdot specific machines only. There are quite a few shared systems, including the outgoing mail relay.
Actually many of our sites do use a CDN, however the/. devs long ago decided against it for some reason or another. Heck it's still even all setup for them.
We use a combination of CentOS and RHEL. The reason we chose CentOS over say debian is because it is basically identical to RHEL, we end up with a "single" platform that we have to deploy, test, and build packages for regardless of support. Depending on the system we will deploy either RHEL or CentOS accordingly based on support requirements.
The average monthly bandwidth usage for/. is around 40-50mbit/sec, which is relatively small. As for cost, you can contact your local ISP for a guesstimate, we get fairly deep discounts since we push quite a bit more with all the sites consolidated.
Deployment date. The Redhat 9 machines were deployed 3 years ago and just haven't needed to be reinstalled yet. BSD, not so much.. we have a team of great linux admins, introducing another variable isn't likely to happen.
Actually the callbacks we do are completely SMTP compliant with the RFC. This is a simple problem on Google's side where some of their MXs are failing causing our callbacks to fail, which in turn causes us to reject the message.
- Incoming MX's (exim)
- Spam checking
- sender verification
- greylisting
- route mail to the IMAP stores
- IMAP stores (exim plus maildir + dovecot)
- break out people on different servers (a = imap-1, b = imap-2, etc..) trivial to do w/ exim and dovecot, also break out the maildirs by letters/var/maildir/f/foo/)
- LDAP/Mysql
- some kind of directory to store username, passwords, which imap store, etc.. on.
- outgoing MX's (postfix)
- postfix queue handling can't be beat
- smtp auth for users outgoing mail.
The biggest reason that APT for RPM hasn't caught on is it's complete ignorance of bi-arch systems. Using apt-rpm on something like x86_64 is basically impossible.
I'll be sure to when I get to the data center next week and am able to get my hands on the angry switch in question. I do love how it just sat there quietly for two weeks w/o doing anything and then decided randomly to just start blasting out 20 Gbit.. sigh.. hardware..
Am I being picky today or is English the author's second language?
Yes it is, iirc he's from Finland.
Actually all browsers send the Accept-Encoding HTTP header, which AVG does not.. if you look at the rule you'll see that it checks for the existence of that head and only blocks if it doesn't exist.
if { ![HTTP::header exists "Accept-Encoding"] {
For anyone that happens to run a site behind an F5 BigIP, here's a nice little IRule to nuke this horrible crap from orbit.
rule IRULE_block_avg-prefetch { ::avg_useragents [list \
when HTTP_REQUEST {
set
"Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)" \
"Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1;1813)" \
"User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)" \
"User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1;1813)" \
]
if { ![HTTP::header exists "Accept-Encoding"] } {
if { [matchclass [HTTP::header User-Agent] equals $::avg_useragents] } {
reject
}
}
}
That's the problem, once we can get a native v6 feed from Savvis we'll have v6 versions of the sites. The idea of running these sites via 6to4 makes me cringe.
Savvis, not Equinix.
Mostly... all the data centers in California are at or close to power / space constraints.. that's one of the driving reasons for moving outside Cali.
Aside from that.. moving away from fault lines definitely helps
Most of the old hardware is exactly that.. really old hardware.. some will be repurposed.. but most will be scrapped.
It's really alot more in response to the availability of space and power.
It is correct. The Databases servers can go to another Quad Core in about 15 minutes however. For the most part, at least with Slash, the Databases are more i/o bound than CPU.
Yes, all machines have hardware RAID cards, even the webservers. The reason for RAID 5 vs 6 was purely a performance thing. Some sites choose to use RAID 10, some RAID 5+spare.
On the Web servers, the specs are
Dual Quad Core Intel E5345 with RAID 1 of 2xSATA drives
On the Database boxes
Single Quad Core Intel E5345 with RAID 5 of 7xSAS drives w/ a hot spare
All machines are 2xGigE connected to cabinet switches which are 10G connected to our cores and our Dual 10G uplinks
Ding, we /used/ to use them as layer 3 routers, but they couldn't keep up after the years and alas, they've been relegated to dumb layer 2 switches now. The poor cpu's can't keep up with anything else. We do have OOB serial management on them like you mentioned however.
Yes, all our servers are at least RAID1, as for email, this article was Slashdot specific machines only. There are quite a few shared systems, including the outgoing mail relay.
Lemme know how that works out for you, considering they're doing layer 2 only and don't have an IP address.
Indeed it is, sir. And it must have been my Dual PII 400, I've never owned a Celeron.
Actually many of our sites do use a CDN, however the /. devs long ago decided against it for some reason or another. Heck it's still even all setup for them.
Of course we do offsite backups, but also we're currently preparing building a new primary data center in Chicago away from Earthquake land.
We use a combination of CentOS and RHEL. The reason we chose CentOS over say debian is because it is basically identical to RHEL, we end up with a "single" platform that we have to deploy, test, and build packages for regardless of support. Depending on the system we will deploy either RHEL or CentOS accordingly based on support requirements.
The average monthly bandwidth usage for /. is around 40-50mbit/sec, which is relatively small. As for cost, you can contact your local ISP for a guesstimate, we get fairly deep discounts since we push quite a bit more with all the sites consolidated.
Deployment date. The Redhat 9 machines were deployed 3 years ago and just haven't needed to be reinstalled yet. BSD, not so much.. we have a team of great linux admins, introducing another variable isn't likely to happen.
Actually the callbacks we do are completely SMTP compliant with the RFC. This is a simple problem on Google's side where some of their MXs are failing causing our callbacks to fail, which in turn causes us to reject the message.
Um... that's the Direct Rendering Manager not Digital Rights Management.
Split everything.
/var/maildir/f/foo/)
- Incoming MX's (exim)
- Spam checking
- sender verification
- greylisting
- route mail to the IMAP stores
- IMAP stores (exim plus maildir + dovecot)
- break out people on different servers (a = imap-1, b = imap-2, etc..) trivial to do w/ exim and dovecot, also break out the maildirs by letters
- LDAP/Mysql
- some kind of directory to store username, passwords, which imap store, etc.. on.
- outgoing MX's (postfix)
- postfix queue handling can't be beat
- smtp auth for users outgoing mail.
- IMAP proxy's (perdition)
- http://www.vergenet.net/linux/perdition/
The biggest reason that APT for RPM hasn't caught on is it's complete ignorance of bi-arch systems. Using apt-rpm on something like x86_64 is basically impossible.