Apologies in advance for the technical speak after all the travelogue rambling, but this is what happened in the workshop this week. If you’re in tech support or you’ve ever tried to run a technical workshop, you will find much of this hilarious. For anyone else, just believe me – it’s funny now that it’s over.

The best thing about having a problem occur again is that you can instantly recognize it. Of course, if you didn’t find a decent solution the first time, then you’re stuck again, but at least you know why you’re stuck. You just don’t know how to fix it. Again.

So, we’re in lab in KL this week, getting ready to do some (very) basic exercises with SoftLayer. The students will log in to the portal, update their accounts and then create a virtual computer image in the cloud. All very high tech – all very cool technology, and all pretty simple to do. All the students have temporary accounts that I created in a guest cube or hotel or Admirals Club last week – I’m not really sure when I created them. I just know they were there before I arrived here. All the temporary accounts have the same password, since the way SoftLayer’s Customer Portal works, once you’ve created a user, you can just update the changed fields (like name and userid) and leave everything else the same to create an almost duplicate userid. So, if you’re setting up a workshop with a bunch of test users, it’s really easy to generate dozens of userids in a relatively short time.

Here’s the issue – and it’s a rather considerable issue – SoftLayer has what I think of as rather retarded password rules: a password must contain capital letters, lower-case letters, numbers and special characters. In other words, you have to generate a password you will never remember, and it’s one that will also be brutally difficult to type.

Apparently, when I created the first (of forty) userids last week, I spelled my own demo password wrong – and I spelled it wrong the same way twice because it got accepted. So, we found out today (after I tried to change the password – but I’m getting ahead of myself) that I had managed to put in the exact same wrong password for forty users, since once I created the first user, I never changed the password field again. So, now I had forty userids with an unknown password, so none of them could log in.

This would normally not be a big problem – you would just change the passwords. However, since you can’t change the password without knowing the old password, that gets difficult. So, in order to change the password, you would have to find the wrong original password once, and then change it forty times. Still, this is just an annoyance.

Here’s how we discovered that I had spelled the passwords incorrectly, and it wasn’t just that a couple of students couldn’t type. This is also where the problem that happened once, happened again.

A problem that occurred last week in the Chicago workshop occurred again today. If the SoftLayer Customer Portal detects five incorrect password attempts in a row, it locks your computer (well, your computer’s IP address) out for a half-hour. This is really good security, unless you’re in a workshop experimenting and not doing real work – but good security dictates everyone is treated the same way. There really is no such thing as a “demo” SoftLayer account.

Here’s the fun part.

If you’re on a local area network that uses network address translation, say, I don’t know, in a university computer lab that you’re using to hold a workshop, then all of the computers in the classroom look like they’re the same IP address. So, as soon as the fifth student gets the password wrong (and I had given all of them the wrong password!), the whole classroom is locked out. Boom! goes the dynamite.

So, we had just started the first lab forty-eight seconds ago, and now we all had to sit and wait a half-hour for anyone to try again.

Lunchtime, people!

This is why you should always schedule labs around lunch or breaks – so when something goes south, and it will, you just send everyone for a smoke or a Coke or a pee, and you fix it without them knowing while they’re gone.

Of course, if you tell them “Forget the userids and passwords we gave you this morning – use these instead”, they might suspect something has gone awry. Seeing the support team in the back snickering while the instructor is sweating is another giveaway.

There wasn’t a way to change the passwords, so while the students had lunch, I deleted forty accounts and created new ones, with a simpler password that still met all the requirements. We also tested the first one to make sure it worked before I created the rest. Not that I didn’t trust my typing. Hmm. Why didn’t I think of that the first time?

On the bright side, with the right spin, you can claim that you were just demonstrating SoftLayer’s intrinsic security and how your data must be safe in a system where an entire classroom can get locked out a half-hour at a time because some idiot creating userids while sleep-deprived can’t spell.

My new demo password will have to be “40UsersLockedOut!”. Then, I could remember it. It would still be difficult to type. Mainly, because I would be weeping.

2 thoughts on “Oops”

  1. We are problem solvers. Without them we are metaphysically nothing. Classrooms enjoy a little f***k-up by the instructor now and again. To borrow yet another overused but accurate cliche, it levels the playing field. And to fix it creatively is an endearing charm.

  2. brilliant. almost like doing a 12 week project to get the customer set up in a test enviroment. you’ve configured everything in vm, now you export it and then import it to the customer’s system yet parts won’t import. you call CS and they go oh yeah! we know about that problem but there isn’t a fix for it yet and we don’t know when. aaaarrrrrrghhh. spend the day manually configuring the customer’s system and then cross your fingers and hope to die that it all works in the demo the next day


Leave a Comment