Now We’re Talking Squid!!

Victory is mine!!!

I’ve been running the Squid proxy server in the house for the past two+ years. In our house if you want to get to the Internet, you have to point your browser to the Squid proxy. Otherwise, no dice on the Internet access. I set this up so that I could keep a liberal policy on computer usage in our house while at the same time keeping an eye on the kids. On top of Squid I’ve been using MySAR for the reporting and it has been doing a very nice job, although the MySAR interface is getting old.

For the Blog, I had the router forward all the port 80 inbound web traffic to the web server. As long as I could run everything off a common Apache server, this setup worked just fine. For this blog I’ve been running¬† WordPress. I’ve been very happy with WordPress so far.

Lately I’ve been help my good friend, Dave, with some web site work. Eventually the websites will be hosted at a still undetermined hosting provider. But for now I needed to bring them up on my home server. At first I just needed to resolve the domains to the single Apache server. No problem. The home network can easily handle this.

Then things got a little more complicated, I also needed to bring up a wiki. For the wiki I wanted to stay with Confluence. I like the Confluence wiki. Its easy to setup and maintain. Even in large installations it is quick and runs on minimal hardware.

We wanted to have the primary domain, resolve to the Apache web server. But we wanted to resolve to the Confluence server. Home routers, while they provide a lot of functionality that 98% of the people don’t even know exists, they can’t perform layer 7 content switching. Initially to get the wiki up and running I had the home router forward port 8080 to the server running Confluence. If you typed www or, it would redirect to the wiki. Problem with that is the URL’s are ugly. Who wants to see “:8080” in the URL. Second issue was that any sub-domain under “*” would resolve to the wiki. Not clean and not elegant.

I looked on ebay for something that could provide the functionality that I needed, but the hardware was way to expensive. So I started to look for an Open Source software solution. The load balancing software solutions were complicated to setup and maintain. I was looking for a simple solution. Then I rediscovered Squid! The reverse proxy acceleration was exactly what we were looking for. All the traffic would be forwarded to the Squid server and I had to only open the single port 80 to the Internet. Squid would then proxy the requests to the correct backend server:port. This setup gave me an added bonus! It gave me positive control over the sub-domains and where they landed. It was relatively easy to get to resolve to the Confluence server on port 8080 and all the other web traffic, like or, to resolve on the Apache web server on port 80.

Here is the snipet of the Squid Config that performs the magic:

# Squid normally listens to port 3128
http_port 80 accel vhost

acl myhost dstdomain
acl myhost dstdomain
acl mywiki dstdomain

#setup cache peers for accelration
cache_peer parent 80 0 no-query originserver name=xenweb login=PROXYPASS
cache_peer parent 8080 0 no-query originserver name=xenshare

cache_peer_access xenweb deny mywiki
cache_peer_access xenweb allow myhost
cache_peer_access xenshare allow mywiki
always_direct deny myhost
always_direct deny mywiki

Eleven lines of configuration. It took the better part of three hours to get this config just right so that I can still use the Squid proxy to capture all the Internet bound traffic while at the same time perform the reverse proxy acceleration. The cache_peer and cache_peer_access lines setup the reverse proxy. The two last lines, always_direct, allows all the internally generated traffic to pass through the proxy to the outside world. I double checked the MySAR application after setting everything up and it was still processing all the logs just fine! So I can still monitor what the kids are up to on the Internet!!! VICTORY!!!

Philmont Shakedown Hike

We had our first Philmont shakedown hike last weekend. The whole Monmouth Council Contingent of 90 scouts, 20 advisor’s and more than 20 staffers travelled up to Stokes State Forest on Friday evening. On Saturday the boys packed up all the tents and loaded up our backpacks. Our crew was somewhere in the middle of all the crews in getting out of camp in the morning. It took the boys an hour and 15 minutes to break camp.

We hiked 10 miles up to theAppalachian trail and over to the fire tower. The boys did well physically. Most of the backpacks were in the 40lb range weight wise. Although the packs were not balanced correctly and there was a lot of loose gear on the outside. So we do have to work on the skills to pack a backpack. One of the games Frank & I were playing is to guess who would lose a piece of gear next.¬† Along the trail we had to stop several times to re-strap on someone’s sleeping bag or tent.

The crew really enjoyed getting to the fire tower. At the fire tower we had our lunch and enjoyed the overlooks. We saw a single hawk riding the thermals while we ate.

Getting back to camp, we were the second crew in. Both Frank and I were amazed. We didn’t think we hiked at a breakneck speed. Being 2nd into camp gave us time to setup the tents and relax before we had to start cooking dinner. All the food we ate was Philmont style food. That is to say it was dehydrated backpacking meals. For the most part the food was good.

Saturday night it rained like hell. One tent the scouts pitched in a small depression. All the rain water collected in their tent. Suffice it to say this is a self correcting problem. The scouts whose tent is was will definitely take more care in setting up their tents in the future.

Overall the shakedown was a success. The boys got a good taste for backpacking and what will be expected of them in the coming months. Next Sunday, 10/11 we’re going to take a day hike to get the crew together and stretch the legs.