mån 2003-03-03 klockan 15.09 skrev Joe Maimon:
> I have a hard time seeing that scaling well. I have seen some efforts to
> this end, but we are talking about parsing out a SquidGuard config from
> an sql db - ( not a simplistic task I would think ) - aside from Berkely
> DB updates. Each time this config changes due to new
> sources/acl/destination all squidguards need to be hupped. Now that can
> be a large hit. As we are trying to take the configuration to a highly
> distributed ( many admins in many orgs) level, this would probaly make
> the whole thing fall down. And users hate latency on config changes.
Moving runtime block lists into a MySQL database is one thing. Moving
the whole configuration is a different beast and several magnitudes more
complex as it most likely involves major rewrite of how SquidGuard
internally manages it's configuration to be driven by the SQL database,
not only how it looks up a well defined acl..
> I actualy practice this concept for my named.conf files. It wasn't
> simple for that and lost some flexibility there as well.
>
> That being said, your advice merits some consideration.
In any event it is a good startingpoint and sufficient for testing and
developing the backend administrative tools. You can then successively
migrate to a more SQL driven runtime approach if needed.
If you go for runtime MySQL queries then you should probably consider
having the MySQL database replicated locally..
-- Henrik Nordstrom <hno@squid-cache.org> MARA Systems AB, SwedenReceived on Mon Mar 03 2003 - 08:51:05 MST
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 17:13:53 MST