I know of someone who did something similar on a mobile phone network.

Whilst anyone can (and ultimately will) make a mistake at some point in their career, the thing that caused his 'fast exit, stage right' was that there was no authorized change request covering the work. The icing on the cake was there had been an email sent to everyone reminding people that no changes were to be made without a change request barely a week before.

Yeah, you can get away with major outages caused by an approved change record with a minor slap on the wrist and the agony of a post incident/change review, but a minor outage without a change record often results in a swift exit from the company.

I know of someone who did something similar on a mobile phone network.

You mean he was firewalled?

See icon -->

"Thankfully one of Charles's ancestors in the monkey colony had anticipated just such an undesirable mutation, and had permanently and irrevocably white-listed the policy management server"

The true hero of this story!

Undoubtedly this firewall rule is written in blood. (or a lot of overtime coffee, at the very least!)

"requiremnet" indeed...

Oh come on! That's the the commonest mistake in the world. I find the fatser you type the moer of them you craete :P

P.S. I still upvoted you for spotting it so quickly - want a job proof reading?

In this case, a simple spell checker would have caught the mistake.

So, are The Vultures using one over on that side of the pond now ?

Weirdly I always used to struggle to type administrator properly. It was usually mangled to some variation of adminini... or such.

The other favourite of mine to mangle was GPUPDATE... and even now, typing this, it almost became GPUDPATE. A weirdly incorrect muscle memory.

Let he who has never sawn off the branch he was switting on, cast the first stone - I think that's mixing metaphors but you know what I mean

We'll burn that bridge when we come to it!

Didn't affect an entire network, but I do recall a scary experience with a computer that was controlling a 1.5m diameter IR telescope high up in the mountains of Switzerland. We we testing a new IR spectrograph, and one of the instructions I got from the engineer was that I should not move the telescope below -10 degrees declination, or else the liquid nitrogen and liquid helium might get poured out of the system, and various things might fail dramatically. The software controlling the telescope was, lets say, "interesting" in that an English language user interface was a late addition (afterthought is the correct phrase). It was very basic: it would prompt you for the coordinates of the object of interest, show the coordinates on the screen, and ask for confirmation by asking "Is this OK?".

At one point, I noticed I made a typo in the coordinates of the object of interest, entering -16 deg declination rather than -6 deg. At the prompt "Is this OK?" I dutifully entered "N" for no, just as I had successfully entered "Y" for yes previously. I was horrified to see the cheerful response I had seen so often before "Then I go!", and could hear the telescope motors start humming. There was no way to stop this before it pointed to this low position in the sky. Apparently, the user interface would consider any character input as a thumbs up, except for Cntrl-D (Unix EOF). We rushed upstairs expect all kinds of damage caused by this action. Luckily, the spectrograph survived this abuse, and worked fine for the rest of the session. I did suggest to our Italian hosts that they might want to update their UI and manuals.

> I should not move the telescope below -10 degrees declination, or else the liquid nitrogen and liquid helium might get poured out of the system, and various things might fail dramatically.

Does that include the humans that got in the way?

So, that is proof that 1) the programmer didn't bother with actually checking inputs, and 2) zero quality control or even proper testing.

I would venture that this would be grounds for a serious dress-down, if not a pink slip outright. When you're writing code for expensive equipment, the least you can do is make sure your code is not going to risk breaking anything and that means testing, testing and testing some more.

Because if the telescope had been damaged, it could be proven that the code did wrong and that company would have been obliged to send a new telescope free of charge.

If that had happened, I'd wager the CEO would have suddenly been very interested in testing procedures . . .

Note that the spectrograph was ours, bolted on the back of the scope, and the telescope software had nothing to do with the limits on the spectrograph, and there was no way for the coders to know that this limit applied.

Holy hell, with consequences that high how is anything OTHER than "Y" not taken as cancel/nope/oh-shit-no?

Windows loomed on the horizon in "antivirus/security package that included a firewall" it was pretty much an iceberg looking for a Titanic :)

In a very similar environment and possibly in the same era, faced with a similar requirement I went for a custom linux/ebtables/iptables (perhaps ipchains) screening bridge between the polloi and *the asset*.

Basically a discarded PC and two network adaptors and custom 2.4 kernel + ebtables userland. [std Python "Four Yorkshireman" sketch ... "you try and tell the young people today that"...]

Worked a treat until it wasn't needed a few years later.

I've never been a fan of firewalling all PCs seperately for rules like this.

Basic security rules like blocking certain services? sure.

Network flow rules? sounds like a nightmare!

L3+ managable switches, or VLAN segmentation is a much easier to control solution, with the added benefit that you enforce compliance for all devices.

(Or back then, a network bridge like you set up)