Sypher

I meant to use the term 'reverse proxy' to refer to the system as a whole rather than the equipment and software performing said process. There isn't really much more to the system than that... Are these the same type of load balancers that occasionally decide to fail to load balance the HTTP proxy servers correctly at LGfL? I have no idea what LGfL use. One visible router. Now I don't doubt I have a slightly blinkered view of the network infrastructure beyond my local CLEO router (Something I could resolve by sufficient poking around I suppose). However it is my understanding that there is a lack of redundancy in the links between the various schools and the upstream links to CLEO/LGfL/Lancs Uni/JANet/whatever. Therefore, no matter how great the 'reverse proxy' might be, the rest of the system lets it down. Your main SPOF is the link between you and the rest of Preston. However, that is equally valid whether you're presenting your VLE to the world through the reverse proxy or whether you're using a global IP on the server itself. So why single the reverse proxy (as the specific boxen or as the wider service) out for introducing a SPOF (which it doesn't) when your main SPOF is actually your single uplink?

We don't because we are treated like mushrooms Us mushrooms don't know that - do we have any SLA thats says this will happen - who gets fired if it doesn't? I think it's fairly widely recognised that neither LEA nor RBC is the best at communicating stuff to schools (having just had a poke around the CLEO site, I couldn't find any published info along those lines. Maybe I'm missing something, but I doubt it.) Sadly, all that is done at a different level -- we just implement. But if you don't *know* then why say that it is? As for firing, there aren't enough of us to fire any I can do some neat reconfiguration tricks with an AP in 10 mins if my DHCP server goes down - but only on a good day, with a following wind so don't try and blow us off with your support skills are better than yours routine. It's not about support skills. We *know* how much the schools rely on a lot of the services we provide (like Moodle, the reverse proxy, etc) being available, and we know how much disruption is caused when they're not. In the case of data-less servers like the reverse proxies, dns servers, etc, it's actually quicker for us to rebuild a server from scratch than to find the appropriate backup tapes -- we've put an *awful* lot of time and effort into building a system for doing exactly this, which we're hoping to be able to release as Free Software when we've done a bit more polishing. Translate - stay in your kiddies playground and leave it to the grownups to sort things out Again, nope. My point isn't the quatity relative to what we look after (sorry if it came across like that) but rather that the reverse proxy really isn't the major single point of failure there; even if Geoff has multiple Moodle servers backing each other up, there are plenty of other SPOFs between him and the world, whereas the proxy is actually resilient. Welcome to our club What I object to though, is the automatic assumption that the proxies are crap, and the fact that something that simply isn't true is presented as gospel without knowledge and without checking. Now, I don't mind constructive comments, either here or via your LEA support. We are more than open to suggestions and questions; is it too much to ask for people to check their facts? Thanks

Drifting gently off-topic here, but how do you know the reverse proxy is a single point of failure? In actual fact there are two CLEO reverse proxies (they are provided by your RBC, not your LEA), and they will fail over. In the event of hardware failure of one proxy, the other will take over. Since this is a data-less service, further proxies can be installed onto fresh hardware, (providing we have hardware, of course) in about 20 minute from bare metal to fully-functioning proxy. This situation will be improved still further when the load balancers go live on this service. Now, how many Moodle web / database / file servers to do you have? How many 'net feeds? How many routers at the border into CLEO? Etc...

Sounds like an interesting idea... On the purely financial side, when you consider what commercial services like URL blacklist charge, you only need to multiply that by a small number of schools before creating an open list begins to look attractive. As localzuk says, bandwidth isn't expensive on the NEN -- that's part of what it's for. Given sufficient people contributing, you'd end up with an effective list which reacted very quickly to the types of sites causing problems within schools, including proxy bypass sites -- it only takes one school, monitoring their logs, to pick up on a bypass site and it would be blocked for all schools the next time they pulled the lists (assuming they subscribe to and block that category, of course). As far as the legal implications go, I'd be interested to hear more about that. I certainly doubt any sane provider of lists offers things like indemnity to schools should they be sued if undesirable content gets through. Anyone know otherwise?

Given CLEO offer a resilient, backed-up hosted service, where you don't have to worry about upgrades etc, and they have plans in the future for full load-balancing across multiple sites, as well as single-sign-on integration and account population, I'd be interested to hear the reasoning behind this? Yes, you could do it yourself, but then you have to buy, manage and run the hardware, backup all your data, and spend a lot of time playing with it -- since CLEO does this free, what are the advantages? What major things do you feel are missing, that you would be willing to pay for (which is essentially what you're doing when you run your own)