On 6/10/05, Jason Williams <jwilliams@xxxxxxxxxxxxxxxxxxxx> wrote:
> After a long hard fought battle, I finally have received permission to
> run squid on our network. I've always run squid on my home network (with
> great success) and now im looking to do it in the corporate world. With
> that, I was hoping to get some type of idea on hardware needs and
> possible some suggestions on where to buy/get my hardware.
Your choice of hardware will be dictated to a great extent by your choice
of operating system, and might also be influenced by your budget and
your employer -- in my case, corporate purchasing mandates that we
we buy from Dell, so I use the Dell PE1850 for "smaller" critical boxes.
With just 70 employees, even the lowly PE750 would be overkill.
My first recommendation for the "corporate world" is to plan on purchasing
two identical machines and operate either behind a load-balancer or with
a reliable failover solution -- if you use Proxy Automatic Configuration (PAC)
instead of transparent proxy, you can even have the clients themselves do
both load-balancing and failover in the PAC script.
> I know squid uses more memory than CPU power. what about disks? SCSI?
> IDE? does it matter? Obviously, I would like good performance,
A server built with Ultra-320 SCSI using 15KRPM drives will give insanely
good drive performance, plus SCSI drives can offer enhanced reliability,
longer warranties, and hot-swap.
While a SCSI-based server may be considerably more expensive than
IDE or SATA, take into consideration that they also tend to be higher-end
all around, with dual power supplies, lights-out data center features, etc.
> ... but prefer security over performance.
My solution to get the utmost security (at the cost of performance) is to
run Squid on OpenBSD under "systrace". This restricts the system calls
the Squid app can make. Systrace is also available for other OSes:
http://www.systrace.org/
> Ok. Company is around 70 people currently. Growth is very real possibility.
You mentioned the number of employees, but not the available bandwidth
or the current average and peak traffic volumes for desktop web browsing.
It'd help to have an idea of the current and historical browser activity, in
terms of requests-per-second and bytes-per-second. Having statistics will
also be useful in proving how the savings in time and bandwidth that come
from serving cached content, and from blocking undesirable content.
Plus management likes colorful easy to read graphs. Think "USA Today".
> Coupled with using squid, I will also be using:
> http://dansguardian.org/ For web content filtering. (And won't I come
> out smelling like roses when I show them we don't have to pay $15k for a
> web content system!)
I personally would *NOT* be comfortable using dansguardian to block
web browsing in a business setting, but that's just me. I suppose if you
were to take logs of your current traffic and whitelist all the domains which
look like they have any possibility of being important to your employees
getting their jobs done, dansguardian *might* be acceptable. Maybe.
Kevin Kadow
