At Sun we have a corporate firewall which does not do transparent web proxying to the outside world. All traffic is directed through traditional proxy servers.
For many years, I've run my own proxy server, deployed on recent versions of
Solaris, and always on x86 or x64 based hardware. Most recently this has been
on a 2-cpu Opteron Server. When it works well, a couple of dozen people use it,
although I've always wanted to have more users.
The early years: Squid
Since the early days (ok, 1999), I ran the Squid
proxy cache. Frankly, I'm fed up with Squid: it is hard to make the right choices at compile time, hard to make the right choices at run-time, has many bugs, and just doesn't feel like a very modern piece of software.
From Squid to Apache
Last week I attempted to replace Squid with Apache 2.2.0's mod_proxy and mod_cache subsystems. However, we started seeing a lot of Apache core dumps (> 150 per day), and have hit problems in which Apache serves up .css (style sheet) content as text/plain instead of text/css. Unfortunately, firefox doesn't like that, and so sites like sun.com fail to render properly. I posted to apache's users alias but received no help. I spent some time trying to track down the core dump problem, but I just don't have time to debug this to root cause.
So what other proxy servers are there? I surveyed what was available on freshmeat but had no luck finding anything that
seemed to fill my list of requirements:
- Provides Caching
- Web correctness (see apache above, which fails on this point)
- Scales to many users
- Easy (at least sort of) to configure and administer
- Open Source
- Helpful Community
From Apache to Sun's Proxy
Finally I decided to try my own company's product: Sun Java System Web
Proxy Server 4.0
. I had avoided this in the past, because it did not run on x86. Thankfully, that has now been corrected. Also it is definitely the proxy with the biggest (and silliest) name. But is it useful? Unlike the other proxies, it is not Open Source, which as far as I'm concerned is a negative. But from my limited testing thus far it scores well on my other requirements: it was simple to set up, and appears to be pretty robust. Hopefully it will someday be released into open source, since as you'll see, it's pretty nice, and I think a lot of folks would find this a nice project to hack on.
Sun Java System Web Proxy Server 4.0
to use, as long as you don't want support. You can download it from Sun's website. It is available for Solaris (x86, x64 and SPARC), Linux, and Windows. The download interface is a bit clunky-- but hey, it's free. The download is about 130MB, which seemed like a lot to me, but it carries with it various patches you need. Once you have it downloaded, you can use
a graphical installer provided you have an X server. In this example, I'll be installing onto a machine called "webhop", and I unpacked the provided .zip file
myhost $ xhost + webhop
webhop # export DISPLAY=myhost:0
webhop # cd /sunproxy/java_es_05Q4_webproxy
webhop # cd Solaris_x86
webhop # ./installer
This popped up the installer GUI on my machine "myhost". Unlike many programs,
the installer is polite if can't remotely display the GUI:
webhop # ./installer
Unable to access a usable display on the remote system.
Continue in command-line mode?(y/n)
I briefly examined the command line installer and wasn't too impressed, but the
graphical one is nice. Here's a sequence of images from my installation:
There were a couple of nice features here which I appreciated: I could enter some basic configuration settings at installation time, and I felt that I wasn't asked many esoteric questions.
One hiccup I did hit was that the proxy didn't install itself as an SMF service.
Hopefully in the next version that will be fixed. Also, in the final panel, the
wizard offered to load me up some additional documentation (a nice touch), but that didn't seem to work for me.
It would have been nice if the installation GUI could have reminded me, at the end of installation, of the URL I would need to configure the server. In this case. But I soon worked out that it was port 8888 on my server. Logging in there, I used the "admin" account and the password I had supplied earlier. At this point, a rather slick looking web based interface launched itself. Here are some of the pages I looked at:
With a little unguided fiddling, I was able to get the proxy to listen on the
port of my choice, with a cache sized the way I wanted. There are definitely
some rough edges but overall I was usually able to find the features I wanted.
Here are some things we could do better:
- One rather obvious improvement would be to the Reporting section, which
produces a textual summary of cache usage-- surely some charts would make
a big difference here. The good news is that with configurable log files,
it should be easy to reuse an existing package such as AWStats to roll my own. The default
log file looks pretty much like apache's.
- I'll also need to work on an SMF service conversion so that if the proxy does
crash, it is automatically restarted (it does seem to have a "watchdog" process
which fulfills that function but at some point in my testing the watchdog itself
- The proxy server outputs a fairly pedestrian message to client browsers when it can't find some host you've typed in. Isn't this an opportunity for branding?
- I was surprised that my connection to the administration GUI for the server was insecure by default. There is a complex "security" section which allows the installation of certificates, but I couldn't make heads or tails of it. There
should be a basic security mode enabled by default.
- "Expert" mode and "Simple" mode-- My configuration isn't very complex, so
an administration mode which guides me through the configuration would really help.
- Integrated status display: it would be nice to have a single "console" which had basic statistics, server status, errors, etc. all integrated together on a single
panel. Something to tell you at a glance how things were going. This should be the default view.
- The proxy includes a GUI for generating a proxy autoconfiguration file, which web browsers can utilitize-- but unfortunately this didn't seem to work for me.
- I had trouble convincing the proxy to use the cache directory I wanted-- it took me a lot of digging to understand that the cache was made up of "partitions." In my opinion, modern filesystems like ZFS eliminate the need for this sort of thing (i.e. spreading your cache out across multiple filesystems), so it would be nice to not see this complexity if it is not required.
- It is often important to restart the server to get configuration changes to be applied. Sometimes the GUI doesn't seem to notice that the restart has succeeded, and so you need to reload it.
Anyway, nits aside, I am surprised by and impressed with this product. So far we've served 55,000 requests, and it has "just worked" to a degree which has surprised me. Nice work, Sun Java System Web Proxy Server (urp) team!
Technorati Tag: Solaris