tom_newton

Sorry - should be clearer... when I say "we fixed it" I mean smoothwall. I've not run censornet in a while

..and if you've had bad experiences with support I need to know! TBH, we have had to add a few bodies, because we don't like to have the phone answered by people who can't fix stuff this occasionally leads to waiting, but you should get stuff sorted when you get there.

Don't be sorry, just coz we sponsor the place, doesn't mean we get to be irritated by negative comment. I must say i'm disappointed though - I am sure we can make it work a whole bunch better - talk to me monday - my DDI is in the 'sig... And I don't know who told you it won't work on a VM.. it will, but the VM needs a LOT of grunt under it.

For ww2? You're a mite late

IME TMG doesn't do a great job of being education focussed, but I'd certainly be wary of continuing surf control in these days of austerity.

You might need to ensure your censornet is right bang up-to-date - sounds like an issue with Win7's tighter security settings, we solved it in an update and I am 99% sure the lads from bristol did too.

Amber, shouldn't need anything too flash for 20 pupils - go for at least 2Gb of RAM, but 50-100Gb of HD space is fine, I don't envisage a lot of logs from those 20 pupils. 2 processor cores, and you should be ok.

The wife drove the first four (Lambo, Ferrari, Porsche, Aston) at a driving day, and said the cheapest car (the porsche) was by far the most fun to drive.

Always heard good things about positive internet, depends how "full service" you want to get I suppose... I know some decent colo/shared server places. Edit: Now seems positive do some inexpensive managed hosting too. Hmm. Certainly a decent bunch when I last encountered them, but it wasn't today or yesterday

Yeah - seems ok now. Be obviously got act together. Think they had peering issues. We never use ISP DNS here anyway in case we need to fail to somewhere else, so it wasnt a dns thing (in any case, the resolver was rapiiid)

We run all our test gear on virtualbox here in Leeds (as it's easier than VMware to stick on straight ubuntu) - but I don't know if there's any potential trouble with performance. Can't see why there should be.

Also having issues with BE Rebooting the modem gave 2 mins respite, but was probably fluke.

FindUtils for Windows <-- if you're a fan of 'find' on *nix, this will be right up your street. It's worth noting that 'find' is a king among utilities.

Xen isn't *officially* supported but it has been seen to work ok as long as it is full virtualisation (as opposed to para-).

Thanks riffleman - but I don't want to raise the expectations here - right now I would class smoothie on Hyper-V as a "curiosity" not suited for production use. Unfortunately we can't get the performance right - partly due to lack of linux support from the guys at microsoft, partly due to an older kernel. We *hope* to have something out before summer that might work to a decent level. Worth noting that web filtering is a heavy duty task though, and not always a suitable candidate for virtualising as it has a nasty habit of wanting all your resource

@piqueaboo: Looking at standard JTR rules would indeed be a better way to infer "strength" (against that attack at any rate) - maybe I was not clear - yes, an all-lc password (especially a dictionary based one like your example) is more likely to be bruteforced, but if you look at the algorithm used in the site we're talking about, it directly judges strength based on addition of a letter/number/etc. which makes naive assumptions that all attackers will brute passwords in just the same way. I was using lower/upper as just a "first example" here of the quality of the result On a more general level, I would suggest that "brute force" attacks are extremely rare, and as such, a measure of a password's security against brute force is not far from measuring a nation's security by its ability to repel an army of clowns riding unicycles. "Not having been typed into an arbitrary website" would be a good starting point for a metric. IMO password entropy between a user's passwords is more important than entropy within. Vik: Length? Matters up to a point, but once it's long enough, the rest is just showboating. Interestingly the usual measure of long enough is given as "just over 6" (characters)

Read the source. Author is a div. For example, adding entropy to your password does not necessarily make it stronger - the possibility of the existance of uppercase (forcing the attacker to use a larger seachspace) is more important than their actual use, for example. So the password's strength can't be determined by the password alone. Simplistic nonsense. Grr.

Avaya certainly started out non-SIP.. I never liked their kit. Wether they have transferred to using SIP like cisco did I dont know

Snom phones usually ok and not too pricy. Don't really cheap out - you will regret it. OTOH, the Aastra units we use at the office may be a bit rich for home use but they are great.

I'll have to take a look. They always do well in vb100 Virus Bulletin : VB100 award - latest comparative tho this time they seem to have slipped a bit (or rather some of the competition have picked up!) and I have some internal to sunbelt stats that show decent performance (ie speed) which I can share on a 1:1 basis if anyone wants a squizz, PM me.

Relatively. I "rule of thumb" 25% cacheability in a school environment.

Spot on. It's actually remarkably difficult to saturate a modern NIC in all but the most network heavy of scenarios. Some interesting corner cases arrive when you've lots of little packets though (say heavy heavy voip users - we're talking carrier grade stuff here).

When we used it we found it decent, but a little heavy. When we changed to VIPRE we also realised that Kaspersky's management tools weren't up to those standards. Not a bad old thing though.

Admittedly most of the systems I see have filtering - which will discourage saturation of the NIC, but I have seen one of synetrix's squid test boxes. They have quality Gig network cards, but the throughput was limited by other aspects - which is why each box has a couple of top end xeons and a bunch of solid state storage and 10s of gigs of RAM. For this reason, it is generally the case that cache/filter boxes end up clustered before you do anything with the >1 NIC. Additionally, of course, in larger networks, a cluster gives resilience. The only recent >1 NIC install we have done teamed 2 NICs for failover, not performance - this was in a large cluster already.

Unless it was a transaction (unlikely) - no. If it was a bunch of inserts you might be able to delete the data, but if some of it should have been there... no good. Backup or bust i think.