Who, Me? Welcome once again, gentle readerfolk, to the safe corner of The Register we call Who, Me? in which readers much like yourselves unburden themselves with stories that have been weighing on their minds – because they recall moments when things did not go quite according to plan.

Take for instance this week's hero, who we will Regomize as "Ivor". In his misbegotten youth, Ivor once worked for a college in the UK which, like many of its ilk at the time, used Novell Netware servers. In fact, this particular institution had just updated to the brand spanking new eDirectory, which it installed on ten of its servers.

Now, as with any new bit of software you install, errors were to be expected. One weekend, Ivor came in to work to trace some recently-reported errors. Seeing that the error messages were pointing at a sole server, he attempted a repair of that machine.

[1]

It did not.

[2]

[3]

So his next step was to remove eDirectory from the server to see if that fixed things.

It also did not.

[4]

However, the errors now seemed to be pointing at a different server. OK, thought Ivor, maybe the trace was being put off the first time by the errors on this server. He ran the repair on the second server, with no success. So he tried removing eDirectory again, also with no success.

But wouldn't you know it, the error trace then pointed him to a third server.

Third time's the charm, thought Ivor, and set about repairing again. And when that didn't work, he removed eDirectory just in case – because that had been such a helpful troubleshooting step it must be worth another go, right?

[5]

Wrong.

We will abbreviate Ivor's story somewhat at this point, because you can probably see where it's going. Let us leap ahead to the point where, of the ten eDirectory-equipped servers, he had run unsuccessful repairs and removed eDirectory from nine of them.

[6]That script I wrote three years ago is now doing what? How many times?

[7]One door opens, another one closes, and this one kills a mainframe

[8]Scripted shortcut caused double-click disaster of sysadmin's own making

[9]Lost your luggage? That's nothing – we just lost your whole flight!

Even though it was the weekend, the college was still staging classes. Calls were now coming in about why login was so slow and certain file shares were missing. All of the school's user data – describing 10,000 students and 700 staff – was at this point running on a single server.

And the worst part was, the errors were still showing up.

Ivor had only one realistic course of action. Clearly this was the damaged database and the source of the errors. This was the one that needed to be fixed. But if he reactivated any of the other eDirectory servers before repairing this one he would likely be replicating the fault and just end up chasing it around.

He had to repair the server live.

"If this killed the database," Ivor wrote, "or we had lost power, or the internal RAID controller failed, or just about anything had happened at this point," all would have been lost. In that event, he "would likely have had to get a job selling slices of melon to tourists on a beach somewhere" – which is a very specific and strangely idyllic way to imagine the disastrous end of your career in IT.

Thankfully (or not, depending on what you think about selling melon on a beach) the repair worked. Ivor was able to reinstate eDirectory on the other nine servers and full functionality was restored.

He later learned that the errors he was seeing were largely cosmetic and could have been safely ignored. But hey, senior management didn't need to know they paid a full day's overtime and nearly lost everything over a problem that didn't need to be fixed.

What about you? Ever imagined your career in IT ending on a beach selling slices of melon? Or had a day like Ivor's? We want to hear about it. Tell us your tale in [10]an email to Who, Me? and we'll share it with the world – anonymously, of course. ®

Get our [11]Tech Resources



[1] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2ZT@M3pjRrSFXTMCt-1VH@QAAA84&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0

[2] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44ZT@M3pjRrSFXTMCt-1VH@QAAA84&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0

[3] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33ZT@M3pjRrSFXTMCt-1VH@QAAA84&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0

[4] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44ZT@M3pjRrSFXTMCt-1VH@QAAA84&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0

[5] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33ZT@M3pjRrSFXTMCt-1VH@QAAA84&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0

[6] https://www.theregister.com/2023/10/23/who_me/

[7] https://www.theregister.com/2023/10/16/trainee_learned_an_important_lesson/

[8] https://www.theregister.com/2023/10/09/who_me/

[9] https://www.theregister.com/2023/10/02/who_me/

[10] mailto:whome@theregister.com

[11] https://whitepapers.theregister.com/