Graham Donaldson <[EMAIL PROTECTED]> wrote at 15:44 on 2008-06-06: > Steffan Davies wrote: > > Graham Donaldson <[EMAIL PROTECTED]> wrote at 11:37 on 2008-06-06: > > > > I've just tested it out - for recent versions all you need to do is add > > the "transparent" keyword to squid's config. Other than that it's just a > > matter of redirecting the packets using whatever firewall/router you > > have in place. > > It would require the developer to re-engineer their cache solution. Seems > excessive.
To work with every current or future application whose developer isn't able or willing to implement proxy support? Seems quite a nice tick-list feature to me, though I suppose it depends how technical an audience you're marketing to. > Engineer a whole new way of doing filtering based on DNS? You'll forgive me > if I pass on that. You have (or your vendor has) already engineered one based on URLs - the DNS case is actually probably simpler. The ongoing difficulty lies in getting your list of things-to-block and keeping it up to date, which you've already done. Again not a bad additional feature, it seems to me. > > Fair, though that sort of inflexibility is one reason why I've come to > > dislike the "appliance" model of computing. Probably pretty much > > unavoidable in a school environment though, I suppose. > > It's pretty much unavoidable in any environment that is interested in > running properly managed, stable IT services. Changing the entire way you > proxy and filter an environment because some application developers are > lazy/inept is poor IT management policy. I think we may be talking at cross purposes here, unless you mean to say that it's impossible to run properly managed, stable services without buying lots of pre-configured boxes. Some of the most irritating problems I've worked on as a sysadmin have been with such devices when their design assumptions don't quite match reality. (Much, in fact, as the Kontiki platform's design assumptions don't match a school/corporate network topology). Your second point I absolutely agree with in principle but in practice as you've mentioned lots of apps will break in a proxied environment. I don't expect that situation to improve much overnight, for exactly the reasons of developer laziness/ineptitude you cite. > Problem is, if you don't make a fuss, developers get away scott free, whilst > administrators have to work on more hacks for their networks. More hacks > almost always equals wasted time, money and less stability. iPlayer must > have a significant audience in schools, the defacto standard for access is > HTTP proxy; not direct, and not transparent proxy. Again, I quite agree. In the case of the iPlayer it'd certainly be nice to see proxy support, though I'd imagine fixing some of the problems it causes for typical NATed home users will be more of a priority. > > A friend of mine came up with a nice approach to this sort of problem a > > while back which involved using an image-aware packet sniffer* at the > > network gateway and displaying the results on a large plasma screen in > > reception. Probably not appropriate in a school environment though ;-) > > Given some of the stuff the kids search for, let's say it would "interesting". The mists are clearing, and dimly I see a Daily Mail front page forming... S - Sent via the backstage.bbc.co.uk discussion group. To unsubscribe, please visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html. Unofficial list archive: http://www.mail-archive.com/[email protected]/
