Tuesday, July 31, 2007

There are certain laws in computing.
I'm not going to pretend that my degree is in computer science.
I'm also not going to deny having skipped the lab day on the one computer class I took in college because it was an unscheduled spur of the moment kind of thing wedged between the abacus and Schickard's calculating clock. The computers were in a "lab" in the sense that the door had a sign indicating such, though none were connected to each other or the outside world.
Side note: I seem to be very, very old.

Part 1. In which the geek describes a basic law of computing

One of these laws I work with every day is this: "In order for people to access a system, they must have (or acquire) the proper permissions to do so."
It seems simple enough. Whoever sets up a computer has to assign people rights to use it. Sometimes a special group called "Everyone" has rights to do whatever they want and sometimes (the times I most enjoy) certain groups of people are only allowed to do certain specific things.
I spend a lot of time making applications available for remote users. These people are granted rights to log on to the machine (even though they never see the actual server) to allow the applications to launch for them. Without rights to log on in some way, they would be out of luck.
All of that makes perfect sense, I hope, because otherwise this next part would be less fun for everyone.

Part 2: In which the basic laws of computing are thrown away and replaced with something entirely non-law-worthy

We have a whole group of servers dedicated to providing remote application access to users. Most of these servers pre-date me, but I know the guy who built them and I know they are built well.
Part of my initial assignment here was to move applications on an old and busted group of servers to this one so that the old and busted servers could be removed and (I guess) sold to a museum.
I got most of the applications moved with no issue. There is one left. We don't have the installation media and I can't find a vendor to tell me if the old database can be moved to the new version of the application. Also, I can't get anyone here to take ownership of the application at all. This situation is what I like to refer to as an application "going feral".
I mentioned it is on an older server. This server is a giant beast of a tan Compaq rack-mounted monstrosity with one power supply, a mostly working array of 4 gig SCSI hard drives and a decided need for someone to hit F1 to allow it to come back to life after a reboot.
I have complete computer access here. Really. Anything and everything I could ever want to do on any system I'm allowed to do. It is my job role and I have that level of access through our permission structure.
I can't access this old Compaq server with the feral application.
When trying to use the Microsoft native remote connectivity method I'm given an "Access is Denied" message. When I try to use a Citrix connection I'm notified that I lack "Permission to Log On Interactively". The third party management application can't find the server on the network and regularly purges it from even the possibility of connecting to it.
Since it is less than 20 feet from me in the server room, I decided early on to just hook up a monitor and keyboard to try to solve the mystery.
The video card is broken, and the keyboard seems to only really respond to "F1".
It is a total black box. I can kind of manage services remotely by bouncing a console off another server on the same subnet, but that doesn't always work.
In fact, no one in my group is able to log on to that machine at all.
And yet, every day people launch that feral app and use it for business purposes.
These people are people with less access than me, so their "Access is Denied" messages should be even more rude than the ones I get.
I was recently asked how the server worked at all if the administrators had no access, since almost by definition the users have less access than we have. I responded that by the laws of computing, and further by all that is good and holy, the server is not and cannot be deploying that application to users. And yet, it is.
I was then asked to provide a plan for decommissioning the server. The plan itself is simple:
First, we drive an aged oaken spike through the CPU. Then the server case should be filled with garlic, or at the very least garlic bread. After this, we burn the server in two separate pyres, one for the chassis and one for the drives.
This plan was received less well than my other, unrelated, plan from yesterday which I will share in case anyone else should find themselves in the midst of a day like I had.
After four hours of meetings about various things, I moved that we table the discussion and reconvene downstairs to continue the discussion over pie. This worked, with the added bonus that I just went back to my cubicle and avoided the rest of the meeting. The only downside? I missed out on pie.

No comments: