But 'sticky' isn't 'zero affinity', is it?
So what you really want it what the original poster suggested, a SSL-speaking proxy (eg Squid in SSL accellerator mode) that terminates the SSL session and forwards the request inside it to a cluster of non-SSL webservers (using RRDNS perhaps, or LVS if you want a 'smarter' solution).
The downside there is your squid proxy is doing a lot of work, so you probably want to have a backup one and use something like heartbeat to fail-over to it if there's a problem with the first one.
> They can catch the scumbags that get the
> cablemodem and then nat their entire apartment
> building, or the neighborhood but they will never
> catch a single family dwelling doing it.
In other words, someone has convinced them that the only real use of NAT routers is to connect a whole building up through a single shared connection.
Which isn't so bad in itself since a NATed connection isn't a real internet connection (unless you've ignored the FBI warning and still have UPNP on your NAT device, most services won't function on a computer behind it) but it does mess up the economics of cable companies being able to provide a connection that bursts up to the 1Mb/s rates while charging what they would for a business to have a fully-used 32kb/s or so.
The real solutions to this problem are:
a) raise the cost of a 1.5Mb/s cable connection to similar to a T1 line, then let users share it out how they want and saturate it all day.
b) strictly traffic-shape each cable connection to the expected average rate instead of allowing higher 'burst' rates.
c) introduce a traffic 'cap', after which the user is either cut off for the rest of the month or forced to pay penalty rates.
option a is clearly impractical as most cable users just wouldn't pay.
option b is almost as impracical as users won't want to pay the premium over dial-up access when they find they can only, on average, download things 2-3x as fast. (thought Telecom NZ's 128k shaped RADSL service is moderately successful)
which leaves c as a reasonable way of providing a high-speed service at an affordable price. But then just look at how the users on Slashdot scream whenever it's mentioned that their cable or DSL connections are no long unlimited-usage (even when the cap is right up in the 10Gb/month range)
So, instead of actually admitting that all they really want to do is get average traffic usage down so their expensive upstream internet feed isn't saturated so much, they add more and more extra terms and conditions to their connection plans aimed at forcing their users into the usage pattern that will produce it.
So, in order to stop silliness like 'no NAT on our network' cable (and to some extent DSL) users first need to accept that cheap, high-speed access means either traffic-shaping or traffic-caps (or both), the ISPs will contract to provide you with exactly what burst and transfer limits they can afford for your $50/month and you can happily use that and share it out as you want.
What bothers me most when I hear this 'all or nothing' attitude is that telcos and cable companies being the slow-moving giants that they are are very likely to opt for the 'nothing' option and then you won't get any broadband at all.
It's already possible to get connections you're allowed to saturate 24/7, but then people like you complain what it costs compared to a similar amount of bandwidth via a cable modem. Well, guess what: That's why!
The current broadband system is really neat in that you can get a connetion that gives you similar interractive performance to a commercial T1 line without having to pay for the 90-95% of the time it would spend idle if you just did a bit of web surfing, etc.
(I would agree that it'd be better still if they advertisted up-front what % utilisation they expected and let you pay more for higher usage, but dropping the 'unlimited' from the ads would scare off so many customers that the price for the same service would have to go up:P)
You might think that the only good connection is truely unlimited, but I like the option of being able to buy a 512kbit connection and just stay under 10Gb/month usage instead of being stuck with a 32kbit 'unlimited' connection for the same price.
Yeah, you'd think that the average user would appreciate that point too. But from experience running a few lists on majordomo, then ezmlm (VERP is a Good Thing!), then finally giving in and using Mailman, vs complicated web interface vs the 'simple' ezmlm one results in less email to the list owner complaining they can't subscribe/unsubscribe, etc.
> You don't have to use maildir; I used it fine with mbox style files.
True. But once you've seen how much quicker pine can scan through a moderately-sized mailbox stored as Maildir format vs the same thing in traditional mbox format, you'll never to back to storing your mail in single flat files again.
In an ideal world, then any admin who's the owner of an open relay would be happy to be notified he's got a problem and work quickly to solve it.
In the real world, many SysAdmin's egos just can't cope with others telling them how to run their system. So, they react by doing stupid things like attacking the blacklist maintainers.
And then if your blacklist maintainer has a similar ego problem instead of shrugging off the insult, they make it worse by blacklisting systems that have done nothing wrong except piss them off.
Admittedly the split-up of the blacklists into 'really open relays', 'maybe open relays' and 'not open relays, but they annoyed me' at least made it possible for those of us who don't buy into the ego trips on either side to at least make some use of the first list.
Maybe not now... but just wait until their anti-spam measures include voluntarily submitting all their customer IPs to MAPS to include on their DUL 'anti spam' list (the DSL ISPs here all do that to force you to pay extra for a static IP if you want to sent mail yourself)
Yes, that would work. But it would also prevent you from using mydomain.com in email addresses as rfc2821 requires all CNAMES are cannonicalised in email headers before delivery.
And if mydomain.com is a CNAME you can't add any other kind of records for it (eg MX, NS, RP, etc.)
In short, this isn't what CNAME records are for, it's a very bad idea, and don't do it.
Also, I fail to see why anything is breaking, so long as your ISP has matching A and PTR records that associate that IP with some hostname, then it shouldn't matter what other A records you create referring to that IP as tcpwrappers (and probably most other services) works like this:
* Find the IP address that's just connected.
* Look up the PTR record for that address in DNS
* For every name that's returned, look up the A records for that name.
* If at least one of the IP addresses returned matches the on that's connecting now, allow the connection.
(which isn't to say that convincing your ISP to delegate the PTR for your IP to you, or at the very least enter a custom record in their DNS, isn't nice... and it does look really cool on IRC... just that it shouldn't horribly break things if they don't)
That's because the DCC module doesn't take into account the non-standard extensions that mIRC uses to do DCC resume. The problem is mIRC's implementation of the protocol (ie, ircII hacked to support DCC resume has the same problem). It breaks one of the 'rules' in rfc1459 (clients should never send an automatic response to a NOTICE) and is much more difficult to support than the original DCC. I tried once, using the spec on mIRC's homepage, but eventually gave up and went back to using ftp to share files.
Slashdot Mirror
But 'sticky' isn't 'zero affinity', is it? So what you really want it what the original poster suggested, a SSL-speaking proxy (eg Squid in SSL accellerator mode) that terminates the SSL session and forwards the request inside it to a cluster of non-SSL webservers (using RRDNS perhaps, or LVS if you want a 'smarter' solution). The downside there is your squid proxy is doing a lot of work, so you probably want to have a backup one and use something like heartbeat to fail-over to it if there's a problem with the first one.
Except the original question asked for a 'zero affinity' solution. Or does that imply that LVS' 'ip affinity' is actually no affinity?
> They can catch the scumbags that get the
> cablemodem and then nat their entire apartment
> building, or the neighborhood but they will never
> catch a single family dwelling doing it.
In other words, someone has convinced them that the only real use of NAT routers is to connect a whole building up through a single shared connection.
Which isn't so bad in itself since a NATed connection isn't a real internet connection (unless you've ignored the FBI warning and still have UPNP on your NAT device, most services won't function on a computer behind it) but it does mess up the economics of cable companies being able to provide a connection that bursts up to the 1Mb/s rates while charging what they would for a business to have a fully-used 32kb/s or so.
The real solutions to this problem are:
a) raise the cost of a 1.5Mb/s cable connection to similar to a T1 line, then let users share it out how they want and saturate it all day.
b) strictly traffic-shape each cable connection to the expected average rate instead of allowing higher 'burst' rates.
c) introduce a traffic 'cap', after which the user is either cut off for the rest of the month or forced to pay penalty rates.
option a is clearly impractical as most cable users just wouldn't pay.
option b is almost as impracical as users won't want to pay the premium over dial-up access when they find they can only, on average, download things 2-3x as fast. (thought Telecom NZ's 128k shaped RADSL service is moderately successful)
which leaves c as a reasonable way of providing a high-speed service at an affordable price. But then just look at how the users on Slashdot scream whenever it's mentioned that their cable or DSL connections are no long unlimited-usage (even when the cap is right up in the 10Gb/month range)
So, instead of actually admitting that all they really want to do is get average traffic usage down so their expensive upstream internet feed isn't saturated so much, they add more and more extra terms and conditions to their connection plans aimed at forcing their users into the usage pattern that will produce it.
So, in order to stop silliness like 'no NAT on our network' cable (and to some extent DSL) users first need to accept that cheap, high-speed access means either traffic-shaping or traffic-caps (or both), the ISPs will contract to provide you with exactly what burst and transfer limits they can afford for your $50/month and you can happily use that and share it out as you want.
But that's far too obvious, isn't it?
What bothers me most when I hear this 'all or nothing' attitude is that telcos and cable companies being the slow-moving giants that they are are very likely to opt for the 'nothing' option and then you won't get any broadband at all.
:P)
It's already possible to get connections you're allowed to saturate 24/7, but then people like you complain what it costs compared to a similar amount of bandwidth via a cable modem. Well, guess what: That's why!
The current broadband system is really neat in that you can get a connetion that gives you similar interractive performance to a commercial T1 line without having to pay for the 90-95% of the time it would spend idle if you just did a bit of web surfing, etc.
(I would agree that it'd be better still if they advertisted up-front what % utilisation they expected and let you pay more for higher usage, but dropping the 'unlimited' from the ads would scare off so many customers that the price for the same service would have to go up
You might think that the only good connection is truely unlimited, but I like the option of being able to buy a 512kbit connection and just stay under 10Gb/month usage instead of being stuck with a 32kbit 'unlimited' connection for the same price.
Yeah, you'd think that the average user would appreciate that point too. But from experience running a few lists on majordomo, then ezmlm (VERP is a Good Thing!), then finally giving in and using Mailman, vs complicated web interface vs the 'simple' ezmlm one results in less email to the list owner complaining they can't subscribe/unsubscribe, etc.
> You don't have to use maildir; I used it fine with mbox style files.
True. But once you've seen how much quicker pine can scan through a moderately-sized mailbox stored as Maildir format vs the same thing in traditional mbox format, you'll never to back to storing your mail in single flat files again.
In an ideal world, then any admin who's the owner of an open relay would be happy to be notified he's got a problem and work quickly to solve it.
In the real world, many SysAdmin's egos just can't cope with others telling them how to run their system. So, they react by doing stupid things like attacking the blacklist maintainers.
And then if your blacklist maintainer has a similar ego problem instead of shrugging off the insult, they make it worse by blacklisting systems that have done nothing wrong except piss them off.
Admittedly the split-up of the blacklists into 'really open relays', 'maybe open relays' and 'not open relays, but they annoyed me' at least made it possible for those of us who don't buy into the ego trips on either side to at least make some use of the first list.
Maybe not now... but just wait until their anti-spam measures include voluntarily submitting all their customer IPs to MAPS to include on their DUL 'anti spam' list (the DSL ISPs here all do that to force you to pay extra for a static IP if you want to sent mail yourself)
Yes, that would work. But it would also prevent you from using mydomain.com in email addresses as rfc2821 requires all CNAMES are cannonicalised in email headers before delivery.
And if mydomain.com is a CNAME you can't add any other kind of records for it (eg MX, NS, RP, etc.)
In short, this isn't what CNAME records are for, it's a very bad idea, and don't do it.
Also, I fail to see why anything is breaking, so long as your ISP has matching A and PTR records that associate that IP with some hostname, then it shouldn't matter what other A records you create referring to that IP as tcpwrappers (and probably most other services) works like this:
* Find the IP address that's just connected.
* Look up the PTR record for that address in DNS
* For every name that's returned, look up the A records for that name.
* If at least one of the IP addresses returned matches the on that's connecting now, allow the connection.
(which isn't to say that convincing your ISP to delegate the PTR for your IP to you, or at the very least enter a custom record in their DNS, isn't nice... and it does look really cool on IRC... just that it shouldn't horribly break things if they don't)
That's because the DCC module doesn't take into account the non-standard extensions that mIRC uses to do DCC resume. The problem is mIRC's implementation of the protocol (ie, ircII hacked to support DCC resume has the same problem). It breaks one of the 'rules' in rfc1459 (clients should never send an automatic response to a NOTICE) and is much more difficult to support than the original DCC. I tried once, using the spec on mIRC's homepage, but eventually gave up and went back to using ftp to share files.