tom_newton

@chrisrowlands our support has been slightly a victim of our success in recent months, but we're back to fairly snappy response times, and still aiming for a lot of improvement - especially in the turnaround of cases with "quick answers" like the one you describe with another organisation. Edit: also should point out that direct support is manned by people on a sort of voluntary basis - which is why you find me lurking on here on a Friday night... you wouldn't be able to pay me to do that

The very latest update has these features: released yesterday. So new that we have to turn on the full suite of applications manually still

I will see if I can get the lowdown on how exactly it should be done, it is as well to bother me about this, that way I will be reminded to dig it out! :-) Back in the office tomorrow so hopefully have chance to collar the right person

Have confirmed - there IS a workaround which was tested today - ask support and quote bug ref 5825

The same report is available on smoothwall, but will give different answers depending on login methods (eg. Ntlm would tell you only from the time a user started browsing)

It's slated to be in the early june release, i'm not PO on that project, but AFAIK it's on track and in beta with some customers @robk included.

Those methods tend to be horribly unreliable. We get the username passed to Smoothwall from the client somehow - proxies are allowed to ask for NTLM and kerberos auth, and windows & mac domain PCs can use the trusted 3rd party (AD) to make sure the conversations are kosher. Otherwise it's either some form of clientside software asking for a password (maybe once, maybe every logon) or a captive portal. The new option RobK speaks of leverages 802.1x logins to a wifi system, so we pull the username from there then go to AD for group membership.

Yes, we used to have bread clips like that in uk. Also, if you're tired of extension cords unplugging, move to the UK, where mains electrical devices are feared and respected, especially by the barefoot

...or wait for the June updates...

Sounds like your LEA has got the keys to the smoothwall policies - first stop is check with them that your students do have games blocked. Meanwhile, if you could email me the list of games sites you have so far, I will have someone ensure they're correctly classified, and teach the content filter to catch others like them.

Hmm, one option if you can do this by IP is just to set up a different auth method per IP address or range (web filter/auth/policies) - wouldn't solve the wonky app problem though. Which app was it?

Probably myIPAddress() == "10.0.1.1" would do it - isinnet is just a shortcut to make it easier to describe networks. Out of interest why are you doing this?

As long as you're not doing forms based auth the smoothie UTM should cover those bases...

Thanks for the feedback Rob, we're really grateful for the effort you went to to accommodate our developers for a day or so

Squid authentication is a well known minefield of difficulty. Sometimes virtual machines suffer clock drift; if there's a differential between squid, the AD, and your clients, things will not work. I should also mention that Smoothwall is an alternative to the "DIY" route: we do an all-in one appliance including Squid and (proprietary software) Dansguardian3 that will make your life a bunch easier, at the cost of a few pictures of presidents drop me a PM/email if you want a quote. Tom

You could try Kerberos: like NTLM only better (if, by better, you mean Java doesn't work with it). Kerberos is more modern/secure and MS aren't trying to get rid of it like they are NTLM.

Oh. Dear. This is going to be a major time-sink. I loved settlers on the Amiga, and settlers 2... might have to give this a go.

I think some of what i'd term "over easy bricking" is due to developers not expecting to be left without input devices... think about how most of the guys writing 'phone software cut their teeth: probably developing s/w for a PC. It goes wrong, you've got a whacking great display, some disgustingly standard input devices (keyboard, mouse) which have support at BIOS level, 30-years-worth of PC engineering, and a handful of ways (CD, network, USB) to get data back on to the device. Now give said developer a device that has very few of these advantages, and I will show you some software that "bricks too easy". I've seen similar challenges here at Smoothwall: when we started making hardware devices (our first products were all "install on your own tin") we ran into a number of issues we just didn't expect - oh the disk check needs keyboard input sometimes? No surprise, it was written for a server OS (the abundance of IP KVM/ILO should tell you a lot about the real headless nature of servers) - well there's no keyboard now, whatcha gonna do? We now have to work extra hard to avoid these sort of problems: sometimes this means putting twice the engineering effort in for the same feature. So in answer to the original question: I think "bricking" will get more difficult. Granted, some of the suppliers have no impetus to make it harder (specifically those having their s/w replaced with someone elses), but as we get more embedded developers coming through the ranks who think like true embedded devs, I think we'll see improvement.

Hi san - if you need to talk Smoothwall, get in touch with our Australian office (details here): https://www.smoothwall.net/contact-us/ and they will put them in touch with a local partner. Of course I will endeavour to answer any questions you have on here too. Tom

Not quite that simple... though I believe there is a test string that's always blocked somewhere in the blocklists.

Making stuff work in all browsers *is* still a PITA, but perhaps less than it used to be. OTOH, back in the day "it works in IE" == "it works", now you have much more to think about. We only really test IE and FF hard - but we fix reported bugs for many many more.

Hm - what's wrong with sox - last I looked you could poke samples at it on teh commandline

Happy birthday Chris!

That's *really* looking like dead disks. A file-by-file copy like rsync is your best option (other than mounting the drive in a PC), then replace those drives.

If you have input/output errors your disks may well be hosed. you want rsync in any case - it's not difficult to use, and serverside needs no more setup than you have right now.