Tom Limoncelli (yes, that Tom) recently wrote a blog post that came to my attention by way of Twitter in which he lamented his bank's scheduled downtime and the implications of routine "weekend work" in terms of an organization's respect for the time and work-life balance of its sysadmin staff.
This was posted the "Rants" section of his blog and is obvisouly ment to be taken as slightly tongue-in-cheek alongside the idea that every sysadmin in geekdom's creation would really rather be watching the Star Wars movie, but it's broadly representative of an attitude I've seen emerging more and more in our profession: That sysadmin work should be viewed as a 9-to-5 gig. I in turn ranted a little bit about that on Twitter, but I think it merits following up with a longer form discussion, so let's have a blog post before the end of the year!
Redirecting a deep desktop link to a mobile home page is BAD AND WRONG If I grab my iPhone and go to http://www.example.com/store/shinywidget I damn well want the page about shiny widgets.
Please don't redirect me to http://m.example.com/ with your crappy designed-for-a-mid-1990s-Blackberry "Mobile site" home page.
Corollary: If I'm using a modern smart phone don't EVER send me to your crappy designed-for-a-mid-1990s-Blackberry "Mobile site"!
Crippling your site and trying to force me to download your "Mobile App" is STUPID. Again, I'm using a modern smartphone. The web page looks great and loads fast.
Your app? It SUCKS. It takes 5 seconds to load (splash screens are the work of Satan), crashes all the time, and it's harder to navigate than the website. Plus I know my way around the website - I use it EVERY DAY on my desktop and I just want to check that one item quick on my phone.
Let's not make this hard, OK? (Every website out there that uses "TapTalk"? I'm looking at you right now and I'm NOT smiling.)
Giant interstitial ads make me not want to use your site anymore Scott called out Forbes on this (and they're a MAJOR offender - I cringe every time I want to read a Forbes article), but so many sites do this.
Corollary: Modal ads that pop up after 30 seconds are even worse!
Corollary: Interstitial or Modal ads that play obnoxious sounds merit the death penalty.
Only being able to click the checkbox, not the label? Why do you hate me?! Do some of these web developers know how small checboxes are on modern monitors? In Safari they're actually decent-sized, but the label is still so much bigger and easier to stick my mouse over and click on. (CMS and "web application in a box" vendors - If your form labels aren't clickable you best be fixing that shit!)
Breaking Links Is Bad Nuff said? Yeah - I think so too.
"Click the flag that represents your language"? How about you just auto-detect it you lazy shit. Seriously.
Corollary: GeoIP has been a thing for over a decade. Please don't make me tell you what country I'm in. (But DO let me override it if you get it wrong)
Using width and height to make the browser resize images is WRONG I'll allow a little fudge-factor here - you can scale down by 10% and I won't hate you.
If you're taking a 6 megapixel image and trying to scale it down to a 3-inch-by-3-inch box on your web page? No. Not acceptable. You can resize that on the server and not waste all my bandwidth, ThankYouVeryMuch.
By the way you're the one paying for this bandwidth - your users on consumer cable modems and FiOS can suck as much data as they want for a flat fee, but when you get featured on reddit and a million people are downloading that 4-meg JPEG image of your cat you better believe your ISP is gonna be charging you for all the extra transfer.
This is going to be one of my rambling sysadmin-y entries talking about stuff that's probably of little general interest. Fair warning given.
There are two components that I would consider essential to proper system administration: GOOD Monitoring and Issue/Incident Tracking. It is imperative that you know when a problem arises (preferably before anyone else notices) and that you keep track of the problems you have encountered in order to spot troublesome systems and redesign them to stop bugging you.
Those of you who have worked with me know I have my prejudices in both of these areas, and that for the last few years I've settled on two pieces of software to fill these roles: InterMapper for monitoring and RT for issue tracking.
The major caveat of this pairing is that the two have no formal integration: InterMapper will happily send emails, and RT will happily accept emails and turn them into tickets, but RT doesn't know when InterMapper is telling it about the same problem twice, or that a previous issue has been cleared. The end result of this lack of integration is that you have a bunch of RT tickets for the same issue which need to be manually merged and resolved, and this manual bit bugged me enough that I actually took the time to fix it!
While I usually read El Reg for teh lulz occasionally they come up with an interesting nugget, like their article on a "severe" OpenSSL vulnerability (quotes theirs). This vulnerability comes to us courtesy of the University of Michigan, and is tied to a simple oversight in the OpenSSL code: It doesn't perform a verification pass on signatures before sending them to a client.
So all you crypto-nerds, how many of you do a verify on your signatures before you send them? Hands please? Nobody? Not even me? -- Yeah, we all tend to trust that our math Just Works. I mean it's a computer, you put in fixed input through a deterministic algorithm and you get the same output ever time. Right? Nope.
Computers, as we all hopefully know, aren't perfect. Trillions of minor errors happen every day, and they're usually compensated for: ECC RAM, cross-checks of math, etc. But because OpenSSL doesn't do a cross-check it's possible for those minor errors to creep into a transmitted signature. As the good folks from UMichigan explain in their paper if you can induce some minor errors in the OpenSSL signature math and collect a good signature and a large enough set of flawed signatures you can eventually derive the private key used for the signing.
That is all well and good, except it relies on errors in the system generating the signatures. These errors are rare (and pretty random) in the real world, so no problem, right? Wrong again Sparky! These clever folks came up with something I wouldn't ever have thought of.
Those of you who have worked on old Commodore computers probably know one of the first symptoms of a power supply going wonky is that the system starts acting up: Lots of random crashes, video corruption, etc. Why does that happen? Because the voltage being supplied to the system is fluctuating. Fluctuating voltages (specifically down-swings) cause all the magical voltage regulation hardware to go out of regulation, which feeds out-of-spec voltages to the chips, which in turn start making mistakes in their math.
The bottom line for this attack is an extension of that well-known Commodore problem: By putting controlled voltage fluctuations into the power supply of real computers (SPARC boxen running Linux) the UMichigan folks were able to induce errors in the math used by the real-world OpenSSL code and recover an actual key.