Slashdot Mirror
Apache 2.2.0 Released
ikewillis writes "According to an announcement on apache.org, Apache 2.2.0 has been released. From the announcement: 'This version of Apache is a major release and the start of a new stable branch. New features include Smart Filtering, Improved Caching, AJP Proxy, Proxy Load Balancing, Graceful Shutdown support, Large File Support, the Event MPM, and refactored Authentication/Authorization.' View the ChangeLog or check out the new feature list."
'apachectl graceful' not good enough for you?
You can also do this: apachectl -k restart
Since version 1.x you've been able to make config changes without a restart. Just edit your config files and then run "apachectl -k graceful" or send a USR1 kill signal to the parent Apache process. Apache reloads the config without restarting.
Slashdot: Failed Car Analogies. Amateur Lawyering. Anecdote Battles.
I'd suggest going with Squid 3.0 (beta, but very stable in my experience) acting as a caching reverse proxy instead of Apache.
/debian/ will be your debian mirror parent servers but everything else will be localhost:81, or whatever.
use cache_peer to setup multiple debian mirrors as parents and it'll share the load between them.
In my testing with squid 3.0 vs squid 2.5 vs apache 2.1.9 (the last beta version before 2.2.0), squid vastly outperformed apache when it came to this type of application.
I'm sure someone will explain to me that apache 2.2 is actually far faster than squid, but in my experience, it's not.
If you want to provide the mirror as a subdirectory of your current site, instead of giving it its own IP and domain, just set up squid to reverse proxy your entire site. You can configure different paths in the url to go to different parent servers, so
YMMV etc etc, but that's what I'd do.
this
FWIW there's a debian-specific solution in the form of apt-proxy, a program that runs on your server, then the clients point their /etc/apt/sources.list at you, etc. etc. I haven't used it, but I know it exists, so your mileage may/will vary. (At my last job I was responsible for setting up a large web cluster; one machine acted as sort of the "mothership" providing all sorts of network services to the web hosts and so on... I was just looking into apt-proxy when I ended up getting a better job elsewhere. ;))
http://apt-proxy.sourceforge.net/
Yes, Squid 3.0 can handle that easily using built in config options, and squid 2.5 can handle it with an external redirector script.
this
There are a couple of GUI frontends for configuration available, but I don't believe this release includes one "out of the box." If you're running Apache on Windows there are a number of commercial products available for GUI configuration. There's a whole bunch of free ones for Linux/Unix, webmin being one of my favorites since it has modules for just about everything under the sun (unix users & groups, samba shares, mysql, etc.) Although I've never had much trouble editing the text conf files by hand. We have a lot of sites and virtual hosts--it was much quicker and easier to set it all up in Apache via typing and cutting and pasting the relevant bits than when we used to run IIS.
Sounds like you want http://freshmeat.net/projects/http-replicator:
"HTTP Replicator is a general purpose, replicating HTTP proxy server. All downloads through the proxy are checked against a private cache, which is an exact copy of the remote file structure. If the requested file is in the cache, replicator sends it out at LAN speeds. If not in the cache, it will simultaneously download the file and stream it to multiple clients. No matter how many machines request the same file, only one copy comes down the Internet pipe. This is very useful for maintaining a cache of Debian or Gentoo packages."
I strongly suggest apt-proxy for Debian. It's drop-dead easy and Just Works great!
The tool's homepage http://gertjan.freezope.org/replicator/ has a nice list of similar tools, but is out of date with respect to apt-proxy, which is not a bash script anymore but is Python now (IIRC).
The only problem I can find with it is there's no RPM for it in CentOS. I'll get around to building one Real Soon Now...
Anyway, I guess the big question is, how many people will actually adopt 2.2.0. I still remember when 2.0 came out to mostly a yawn as most people kept using 1.3.x. Even today, most of the servers that I come across or administer are still using 1.3.x because unless you were running Windows, 2.x didn't really offer spectacular improvements over 1.3.x, and looking at the changes for 2.(1|2).x (anyone who's going to transfer a >2GB file over HTTP is crazy ;)), I have this feeling that we might see the same 1.3->2.0 inertia.
The change from 1.3 -> 2.0 was a very major one. The entire api was retooled; and for good reason, ap 1.3 had some rather serious deficiencies in the extensibility department (module load order significance, etc). 2.0 saw the birth of the exceedingly well designed APR (Apache Portable Runtime), a module-participation-driven abi ("hooks") and fast stack-unwinding i/o handling ("fitlers"). All good stuff, but slightly less able performance-wise on low-cpu-count hardware (extensibility always comes with a pricetag) and completely imcompatible with any module of even moderate complexity that had previously been written.
Times have changed though. The robustness of the abi design combined with the APR has led to some outstanding modules, such as extensive state awareness and dynamic load-balance adjustment without even USR1-style interruption. None of these capabilities are even remotely plausible under 1.3.
The point is: 2.2 is still the same core api design. Certainly, it contains some enhancements, but the bridge that must be crossed is miniscule in comparison to the 1.3/2.0 transition.
There is still much room for improvement (when isn't there?). For example, mpm looks like a good idea on paper, but how well does it really work in terms of abstracting the process/thread semantics into fairly "pluggable" components? How well can it really work? Thread-based design requires a completely different approach or the end result (treating threads like processes) simply nets you more "accounting" overhead and few significant gains to offset that (yes, I realize it wins on win32 which does not have a light-weight process model).
The point is not that you don't need to do it, it's that if you're using http to do it you're an idiot.
:)
Or maybe I just don't want to run a separate server (FTP/SSH/anything) to do large file transfers when Apache is perfectly capable. Reduceding admin time, effort, cost, load, exposure to risk, support needs and so-on. Pretty big idiot I feel right now.
Claiming that http servers need to support over 2gb is like claiming that DNS servers need to.
When was the last time you downloaded a file from a DNS server?
And show me a real reason to go for 64-bit on the desktop.
Sure, RAM. 3D work, CAD, video. What are you saying, 4gb should be enough for anyone?
In the mean time (ie, since the 2.0 release) we've changed the versioning model to the "odds are dev, evens are stable" model. So as soon as 2.2 released, development moved to the 2.3 branch, which will release as 2.4. So, yes, like Perl and Linux and many other things.
As for transferring >2GB files, this comes up many times every day on #apache, and fairly frequently on the mailing lists, so people do actually want to do this.
Folks that are still using 1.3 are missing out on enormous strides forward. The "it still works fine, why should I upgrade" crowd are completely welcome to remain where they are, and we're not going to compel to move, but they are going to miss out on all sorts of cool things, in the name of "it's good enough already." Their loss, not ours.
Apache guy, Open Source enthusiast, runner
Much of it delt with memory considerations. One person had a few hundred processes on his system, and since they each need a copy of data that's that same, that was a lot of extra overhead.
on a system that has init scripts like Red Hat's you can use /etc/init.d/httpd reload to have it reload the config file.
I think you could also do a killall -HUP httpd and this will also work.
The earth-shattering feature of Apache 2.2 is RFC 2817 SSL Upgrade. Basically, any HTTP connection can upgrade itself to HTTPS without reestablishing.
This means you can do SSL on virtual hosts without a dedicated IP address. This will greatly increase the penetration of SSL (plus free certs like CaCert) and encryption in general. The $5/mo webhosters will be able to offer SSL to clients. Ubiquitous encryption considered good.
This is, of course, a Catch-22 - there are no browsers with the capability yet (let's get Mozilla going...) but this is the necessary first step. Come back in a couple years and see how things are going.
Oh, and I'm happy about the Cookie proxying patches which I reported against 2.0 but were applied to 2.1. This is the only Apache feature I've ever had a hand in designing so I'm happy to see it available. Basically, anything you do with cookies (paths, domains) should be properly proxied now. I've been waiting for this for a long time. Yay!
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)