There’s a lot of fear floating around right now about the hash collision DoS vulnerability which pretty much every web application platform out there (except for Perl, which fixed the vulnerability way back in 2003!) is open to. http://thehackernews.com/2011/12/web-is-vulnerable-to-hashing-denial-of.html
And yeah, it’s a pretty big deal – if you’re vulnerable, any PHP script that so much as touches $_POST or $_GET will be vulnerable. What none of these pages seem very inclined to tell you is exactly HOW to test for vulnerability – and, what may have already made this problem a non-issue for you. Spoiler: if you’re running a current LTS version of Debian or Ubuntu and you installed the LAMP stack during boot or by using tasksel install lamp-server, you’re probably fine. The Suhosin patch gets in the vulnerability’s way in the default configuration it uses on Squeeze and Lucid, and the Debian-style LAMP installation gives you Suhosin, so you’re good to go.
But what if you DIDN’T get your LAMP stack that way, or you just aren’t sure if you’re running Suhosin – or the right configuration of Suhosin – and you want to check? First, dump this little PHP script somewhere that you can access it – for most people, /var/www/hashtest.php will work fine:
Note: it’s that useless line accessing $_POST that makes this script potentially vulnerable – without that line, this script wouldn’t actually be vulnerable to the attack, because PHP builds the super-array for $_POST and $_GET lazily. You don’t access it… PHP doesn’t create it. Anyway, now make sure that you can actually access that script using wget, like this: wget -O – http://127.0.0.1/hashtest.php
You should get a quick HTML output that says “test passed!” – which isn’t true, because we didn’t actually test it – but now you know the script will actually execute. Now, wget -qO /tmp/hashcollide.txt http://jrs-s.net/hashcollide.txt – this gives you a “payload” file with a nice set of really nasty hash collisions that will confuse a PHP application badly. Finally, you’re ready to test it out – wget -O – –-post-file /tmp/hashcollide.txt http://127.0.0.1/hashtest.php[/b] and you’re off to the races. If you’re lucky, you’ll get this:
If you’re not lucky, you get a nice long wait (max_execution_time in php.ini, 30 seconds by default) followed by this:
me@locutus:/var/www$ wget -O - --post-file /tmp/hashcollide.txt http://127.0.0.1/hashtest.php
Connecting to 127.0.0.1:80... connected.
HTTP request sent, awaiting response... 500 Internal Server Error
2011-12-29 16:10:14 ERROR 500: Internal Server Error.
In my testing so far, FreeBSD (all versions), Ubuntu Hardy, Ubuntu Oneiric, and Debian Lenny are vulnerable. Ubuntu Lucid and Debian Squeeze were not. Again, this assumes you’ve installed the LAMP stack in the default manner; “cowboy installs” may or may not be vulnerable. Suhosin appears to be the key factor determining whether a particular machine will or will not fall prey to this vulnerability. The fix, if you are vulnerable – upgrade your OS to a current LTS version, upgrade all packages, and make sure you’re running Suhosin – then make sure you actually set the Suhosin variable suhosin.post.max_vars to 1000 or less.
In the following example, we discover that a stock Oneiric workstation is vulnerable, and then we fix it:
me@locutus:/var/www$ wget --post-file /tmp/hashcollide.txt -O - http://127.0.0.1/hashtest.php
--2011-12-30 10:27:43-- http://127.0.0.1/hashtest.php
Connecting to 127.0.0.1:80... connected.
HTTP request sent, awaiting response... 500 Internal Server Error
2011-12-30 10:28:43 ERROR 500: Internal Server Error.
For some damn reason, even though Oneiric indicates that suhosin.post.max_vars should be set to 1000 by default, and even though the Suhosin project says they have it default to 200… in actuality, on Oneiric, it defaults to unset. If you uncomment the statement already in suhosin.ini as I did above, though, then restart Apache – you’re set.
Note: the “payload file” referenced above was lifted from https://github.com/koto/blog-kotowicz-net-examples/tree/master/hashcollision .
I’ve started to build what I’ve dubbed “medium iron” virtualization servers: 12-24 cores, up to 128GB RAM, etc etc. For this particular task, AMD is the bang-for-the-buck king; they can’t touch Intel right now on per-core performance, but if what you want are tons and tons of cores and lots of memory address capability for cheap, they can’t be beat.
One problem: the new Socket C32 CPUs, such as the Opteron 4180/4184/418x, don’t come with a cooler… and there are only two coolers AT ALL on the market that specifically state they support Socket C32 – the Noctua NH-12DO, which is a fine, quiet, lotsa-air-flow cooler but very pricey at typically $80 or so (and rather hard to find), and some Dynatron that everybody and their brother warns sounds like a drill press even at idle (and isn’t cheap either). Making matters worse, the Noctua is an unusually large, super-tall design that just plain won’t work in a lot of cases.
If you dig further, you’ll find some hardware enthusiasts mentioning that the Socket C32 “should accept most Socket F coolers”, going further to mention that they’ll need to be a certain “pitch” – which usually isn’t specified on the cooler’s details page.
Well, as a public service announcement, here’s your specific inexpensive alternative for Socket C32 cooling: the Thermaltake A4022 (sometimes aka the “TR2-R1”). At under $20 retail, it’s somewhere south of 1/4 the price of the Noctua cooler; it’s also much easier to find, and it’s a standard low-profile design that fits in a lot more places.
With two of the A4022 coolers installed, my dual Opteron 4180 system idles at about 40C and runs about 65C when running 12 instances of K7Burn to maximize thermal output. Better yet, this was a deliberately low precision installation: I put a small dab of generic thermal grease on top of each CPU, and did not remove the thermal tape stripe from the bottom of each cooler (which generally will give you lower temps, if you properly grease the CPU/cooler interface). So, no “overclocker tricks” required – these coolers, in my testing, “just work” perfectly well.
ASUS has entered the Android tablet market with a compelling new contender – the Eee TF-101 “Transformer.” Featuring an Nvidia Tegra dual-core CPU at 1.0GHz, the device feels “snappier” than most relatively high-end desktop PCs – nothing lags; when you open an app, it pops onto the screen smartly. If you’re accustomed to browsing on smartphones, you’ll feel the performance difference immediately – even notoriously heavy pages like CNN or ESPN render as quickly as they would if you were using a high-end desktop computer.
I first got my hands on a TF101 that one of my clients had purchased, sans docking station. After I’d played with it for a few minutes, I knew I wanted one, but that left the $150 question – what will it be like when it’s docked? The answer is “there’s a lot of potential here” – but there are problems to be worked through before you can give it an unqualified “hey, awesome!”
CNET complains that the TF101 feels cheap, with poorly-rounded corners and a flimsy backplate. After a week or so of ownership and something like 20 hours of active use, I do not agree on either issue. I find the tablet nicely balanced, easy to grip, and solid feeling. It weighs in at 1.6 pounds (tablet only) and 2.9 lbs (tablet and docking station), which puts it pretty much dead center in standard weight for both tablets and netbooks. However, while the weight of the docked TF101 is an ounce heavier than the weight of my Dell Mini 10v, the TF101 feels much less cumbersome – probably because even though it’s slightly heavier, it’s much, much slimmer.
Docking the tablet feels easy and intuitive; line up the edges of the tablet with the edges of the docking station, and you’re in the right position for the sockets to mate. Pressing down first gently, then firmly produces good tactile feedback for whether it’s lined up properly, and whether it’s “clicked” all the way in. The hinge itself is very solid and doesn’t feel “loose” or sloppy at all – in fact, it’s stiff enough that most people would have trouble moving it at all without the tablet already inserted. Undocking the tablet is easy; there’s a release toggle that slides to the left (marked with an arrow POINTING to the left, which is a nice touch); the release toggle also has a solid, not-too-sloppy but not-too-stiff action.
The docking station offers more than just the keyboard. There are also two USB ports (a convenience which is missing on the tablet itself), a full-size SD card slot, and an internal battery pack, roughly comparable to the battery in the tablet itself. The extra battery life is a great feature; the tablet itself gets 9 hours or so of fully active use, and the docking station roughly doubles that. In practical terms, most people will be able to go away for a long weekend with a fully-charged TF101 sans charger, use it for 4 hours a day without ever bothering to turn it off, and come home with a significant fraction of the battery left – especially if they’ve taken the time to set the “disconnect from wireless when screen is off” option in the Power settings. I used the docked tablet 2 to 4 hours a day for a full seven-day week, playing games, emailing, and browsing; at the end of the week I was at 15% charge remaining.
Polaris Office, the office suite shipped with the TF101, was a pleasant surprise – a client asked if I could display PowerPoint presentations on the tablet, and the answer turned out to be “yes, I certainly can.” I’ve only tried a few of them, none of which had any particularly fancy animations; but 40MB slideshows load and display just fine. Paired with an HDMI projector, the TF101 should make a pretty solid little presentation device, particularly since it feels just as “fast” running slideshows as it does browsing and playing games from the Market.
Moving on to the docking station itself, I quite liked the way the touchpad is integrated into the Android OS – instead of an arrow cursor, you get a translucent “bubble” roughly the size of a fingertip press, which felt much more intuitive to me. With the arrow, I tend to try to be just as precise as I would with a mouse – which can be frustrating. The “fingertip bubble” made it easier for me to relax and just “get what you want inside the circle” without trying to be overly finicky. Sensitivity for both tracking and tapping was also very good; the touchpad feels slick and responsive to use.
The keyboard, unfortunately, is a mixed bag – it’s better-suited to large hands than many netbook keyboards, but you won’t ever mistake it for the full-size keyboard on your desk. The dimensions are almost exactly the same as the keyboard on my Dell Mini 10v; but I find that it feels significantly more cramped and awkward – probably because ASUS elected to go the trendy new route of “raised keys with space between them”, where the Mini’s keys are literally edge-to-edge with one another. This should make the TF101 less likely to collect crumbs, skin flakes, and other kinds of “yuck” than the Mini 10v, but I personally would rather deal with more cleaning than less roominess.
Several applications don’t really play well with the keyboard – ConnectBot, which I use as an SSH client to operate remote servers, becomes completely unusable due to handling the shift key wrong – you can’t type anything from ! through + without resorting to re-enabling the onscreen keyboard. In the Android Browser, typing URLs in the address bar works fine, but if you do any significant amount of typing in a form – for example, writing this post in the TinyMCE control WordPress uses – the up and down arrow keys frequently map to the wrong thing. Sometimes up/down arrow would scroll through the text I was typing, sometimes they would tab me to different controls on the page, and some OTHER times they would simply scroll the entire page up and down.
In Polaris Office (the office suite shipped with the TF101), the keyboard itself worked perfectly – but the touchpad was too sensitive and placed too closely. It was difficult to type more than one sentence at a time without the heel of my hand brushing the touchpad and registering as a “tap”, causing the last half of a sentence to appear in the midst of the sentence before it.
Can these problems be mitigated? Probably. The ConnectBot issue was solved pretty simply by Googling “connectbot transformer”, which immediately leads you to a Transformer-specific fork of ConnectBot – after uninstalling the original ConnectBot, temporarily enabling off-Market app installation, and downloading and installing the fork directly from GitHub, my shift-key problems there were solved. Presumably either Google or ASUS will eventually deal with the arrow key behavior in the Android Browser. I tried using the Dolphin HD Browser in the meantime, but had no better luck with it – it is at least consistent in how it handles arrow key usage, but unfortunately it’s consistently wrong – it always scrolls the entire page up and down when you press up or down arrow keys, no matter where the focus on the page is. Finally, you can toggle the touchpad completely on or off by using a function button at the top of the keyboard – but it would be nice to simply change the sensitivity instead, or automatically disable it for half a second or so after keypresses, the way you can on a traditional (non-Android) netbook.
In the end, though, you can’t really fix all the problems by yourself with “tweaking”; some of the frustrations with the poor integration of the physical keyboard into the Android environment are going to keep ambushing you until Google itself addresses them. ASUS and individual app developers can and likely will continue working to mitigate these issues, but it will be a never-ending game of whack-a-mole until Android itself takes adapting to the “netbook” environment more seriously.
Final verdict: The tablet looks, feels, and performs incredibly well; in most cases it “feels faster” than even high-end desktop computers. Even though my Atom-powered Dell Mini 10v has a Crucial C300 SSD (Solid State Drive), the TF101 spanks it thoroughly in pretty much every performance category possible and sends it home crying. Battery life is also phenomenal, at 9-ish active hours undocked or 18-ish hours docked. It looks and feels, on first blush, like it would make a truly incredible netbook when docked – but Android 3.2 and its apps clearly haven’t come to the party well-prepared for a physical keyboard – and it shows, which knocks the initial blush well off the device as a netbook competitor. If you really need physical keyboard and conventional data entry, this is probably not going to be the device for you – at least, not until the rest of the OS and its apps evolve to support it better.
If you want a tablet, I can recommend the TF-101 without reservation. If you want a netbook, though, you should probably give the TF-101 a pass unless and until Google starts taking the idea of “Android Netbooks” seriously.
I have been looking for a user-friendly, AJAX-y web application to allow easy sharing of arbitrarily large files for YEARS. Finally, FINALLY, I found one – Relay.
Relay was a “dead project” that hadn’t been updated in several years, but my testing finds it perfectly functional. It was very difficult to actually find the code for it, because the web’s full of links to the original page, which is long since defunct. However, if you are persistent enough in your Googling, you eventually find that a Google Project was created for it several years ago – which was uploaded by someone with a now-defunct Google Code account. Luckily, I managed to get ownership of the project at Google Code transferred to me; so Relay is now available for download – and actively seeking interested developers to address a couple of issues I’ve addressed on the project page.
As a proof-of-concept for USC computer science labs, I set up eight Windows 7 VMs on the same physical host in the Windows Server demonstration below, and recorded firing them up simultaneously and doing some light web browsing, etc. on several of them. Performance is pretty solid; you could probably cram double this many guests on that host and still have as good or better performance than the typical physical lab workstation.
update: replaced video with somewhat more watchable version, with all eight guests tiled on one screen.
Aside from good performance and a single box to maintain, this setup offers some fairly compelling advantages over the traditional computer lab: the host also has a 2TB conventional drive in it, which is where a “gold” image of the Win7 guests is maintained. It only takes about 10 minutes total to reset all of the guests to the “gold” standard; and it would be just as easy to keep multiple gold images on the conventional drive for different classes – Linux images for one class, Windows images with Office for a basic class, Windows images with Visual Studio for another, Solaris for yet another… you get the idea.
Also, the time to “reset” the guests could be substantially faster than that, even, with a little tweaking – using .qcow files instead of whole LVM volumes would allow you to use rsync with the –inplace argument and only have to write over the (relatively few) changed blocks, for example; or in a more advanced layout a separate FreeBSD machine with a large RAIDZ array and iSCSI exports could be used to store the images. There’s still plenty of room for improvement and innovation, but even the simple proof-of-concept (which I put together in roughly half an hour) looks pretty compelling to me.
I’ve been surprised and pleased at just how well Windows Server 2008 runs virtualized under Debian Squeeze. I first started running virtual Windows Servers purely for the disaster recovery and portability aspects, expecting to pay with a drop in performance… but what I found was that in a lot of cases, Windows 2008’s performance is actually somewhat better when running virtually. In particular, the ever-annoying reboot cycle gets cut to a tiny, tiny fraction of what it would be if running on “the bare metal.”
It’s also pretty nice never, ever having to play “hunt-the-driver” – the virtual “hardware” is all natively supported by Windows, so a virtual install “just works” the moment it’s done, no fuss no muss. But what about that performance?
Smokin’! Which exposes yet another reason to think about virtualization: being able to take advantage of Linux’s highly superior kernel RAID capabilities. The box shown above is running four Crucial C300 128GB solid state drives connected to SATA-3 6Gbps ports on an ASUS board; the Debian Squeeze host has them set up in a kernel RAID10. The resulting 250GB or so of storage is on a performance level that just has to be seen to be believed.
Note that while this IS a really “hot” machine, it’s still just one machine, running on commodity hardware – there’s no $50,000 SAN lurking in the background somewhere; that performance is ALL coming from a single machine with a price tag of WELL under $10K.
One of the things that I’ve missed on the Linux desktop is simple audio tone control in the sound volume applet. It particularly annoys me that Gnome allows you to set cruddy little reverb profiles (wow, all my audio sounds like a dog barking now… uh… thanks…), but if your speakers need a little help in the bass or treble department, you’re out of luck. Well, now you’re not!
The PulseAudio System-Wide Equalizer is available from its own Ubuntu PPA, and it is a thing of absolute beauty. I particularly like the fact that the bottom slider is centered at 50Hz – where you want it to add a crisp punch to capable speakers – rather than at the more common 80Hz or even 100Hz, which is more immediately audible but also muddies up the sound rapidly.
Another consultant emailed me a .evt file recently for review. Which is great, except I frequently go days now without sitting in front of a Windows workstation – or at least, not one that isn’t broken and in need of fixing. So, I needed to find a Windows Event Log viewer.
There isn’t currently one in the Debian or Ubuntu repositories, but I did find a free-as-in-beer tool at TZWorks, LLC which did the trick nicely. It’s currently available for download in Windows, Linux (i386), and Mac versions – I haven’t tested the Mac version, but the Windows and Linux versions both run fine and do the job well, both for the older .evt and the newer .evtx (Vista and up) formats.
Note: the Linux binary provided is currently 32-bit only, so if you’re running a 64-bit system you’ll either need to install ia32-libs (apt-get install ia32-libs on Debian or Ubuntu), or just run the Windows version under WINE.
EDIT, September 2014: you can’t tell from looking at the download page, but this app now costs $228 for a single copy of it. So, uh, keep moving if you want a reasonable tool to look at Event Viewer logs with, sorry. >=\
Bad Behavior has blocked 758 access attempts in the last 7 days.