I don't know if this has been responded to yet--I've been travelling and have yet to wade through all 500 mails I had waiting. But I'll give my thoughts.
Mark Constable wrote: > On Mon, 17 Dec 2001 06:42, Rick Matthews wrote: > > >>>Has anyone thought about a MySQL (or equiv) based back >>>end for squidGuard ? Any PHP monkey could know together >>> > >>I would really like to participate in an exchange of ideas on this. >>Could you elaborate on your target environment and the specific >>functionality that you see being built into this system? >> > > My thoughts are that it's so obvious to have the squidGuard > dbs embedded within an SQL server that there must be some > inherent reason, that I am not aware of, for _not_ doing so ? > If the only reason it's not done this way now is because no > one has made it so then... let's boogie, but someone really > familiar with the system might want to comment on why an SQL > server is not a good idea ? > > + I already have MySQL on all squidGuard servers > + updates into the SQL server would be available immediately > + squid does not have to be reloaded after db modifications > + millions of entries would be no problem > + researching the state of the db would be saner > + various scripting languages could easily interface to the db > > - I can't really think of any negatives - Speed. MySQL is fast for an SQL database server...but db is much faster for a SquidGuard like app. If performance is not a concern in your case, an SQL database will work fine. If performance matters--including latency on otherwise lightly loaded proxies--you'll find SQL is almost certainly too heavy. In fact, I'm betting you'll hit some pretty awful performance problems if you convert SquidGuard to a MySQL database. > Unfortuantely, kinda, I use the Debian packages for squid/sG > so I'm not that intimate with how it actually all works. I won't claim to be an expert on its underpinnings either...but I do know that using SQL is a pretty heavyweight way to address a data query problem. SquidGuard doesn't need relational database features, it needs speed and a lightweight and efficient implementation. That said...SQL could /certainly/ be used for a blacklist maintenence system, and should be. It's on my To-Do list, but it gets pushed back every time other projects come along that demand more immediate attention. Ideally, one could create a database that could export the right list for any situation, based on 'levels' of categories (where categories means 'porn', 'gambling', 'entertainment', 'warez', etc.). If in a relational database that has all of this data...an example database will help: ~~>Example SQL database url=www.porn-r-us.com category/level=porn/2 category/level=language/1 date confirmed=01/01/2001 confirmed by=rjc comments=Not suitable for children. Legal for adults over the age of 18. Adult language and content, but no scatological or legally questionable images. url=www.yahoo.com category/level=informational/0 date confirmed=05/01/2001 confirmed by=unconfirmed comments=none url=www.betting-your-life.com category/level=gambling/4 category/level=porn/2 date confirmed=01/01/2001 confirmed by=rjc comments=Received 'porn' rating due to 'strip poker' and other sources of pornographic imagery. <~~End Etc. Expanding it for company or school specific purposes also becomes very easy--and the custom list can be generated whenever the site admin desires, by pulling down the most recent additions to a public database and merging it with their own local database. These kinds of things are relatively trivial to automate...at least no more difficult than the current batch of scripts in existence today for handling SquidGuard This database could easily be polled by a very simple query (or GUI frontend with query capabilites) to get a list tailored just to one environments needs. I've written up a brief design of this concept (which has now been pretty well covered in this email!), but haven't had the time to get to work on implementation. If someone else does begin work in this direction, I'll be happy to help where I can. I'm also willing to host a public database as soon as our new server goes online at the beginning of the year (and provide the potentially gigabytes of bandwidth transfer required to make this useful for the whole community). Anyway, this is what I've been planning to implement in my Copious Free Time(tm) for about a year...And I reckon one of these days I'll actually do something about it. -- Joe Cooper <[EMAIL PROTECTED]> http://www.swelltech.com Web Caching Appliances and Support
