Paul Bryson wrote:
Tim Bates wrote:
* GUI - definately not needed. Waste of space. You can do a pseudo GUI
in text modes anyway (which I would suggest doing for initial config).
That was my thought too.
* I would personally suggest having a live-CD version with no disk
cache if possible. Some people may want to see how easy it is to work
before they commit a box to it. Obviously it won't cache (well, much)
if there's no disk, but as a demo it would work.
Having it run as a live-CD is fine, as long as it will also install into
a usable state.
* My choice of distro to base it on would be Debian (stable). They are
pretty solidly committed to security, and there's hundreds of mirrors
out there (with debian providing online lists you can query).
I don't know much about such things. Are there Debian based live CDs
that don't use X, have good hardware detection, install easily to
harddisk, and would be easy to integrate Squid installs for which there
are no official Debian packages?
Squid builds easily on Debian with only a few configuration settings in
recent squid. I wrote up the settings a while back:
http://wiki.squid-cache.org/SquidFaq/CompilingSquid#head-947a559d216b70700e568c757f1bb0cc96a97838
Luigi has been very prompt keeping the Debian unstable/testing
repositories up to the very latest official releases and fixes. So there
should be no trouble installing any recent versions.
* For post install configs, you could use the same interface as the
installer. Have the primary console run it via init (with askfirst so
it's not always running). You could additionally have a web interface,
running from a tiny HTTP server preferably.
Agreed.
Atamido
Amos
--
Please use Squid 2.6STABLE17+ or 3.0STABLE1+
There are serious security advisories out on all earlier releases.
