In the early 1990’s I was sent to a military research station to see if I could help out with a performance issue they were having. The site consisted of several buildings surrounded by a very high steel-link fence (fifteen feet?) and you entered by stopping at a barrier; a commissionair (the government’s standard security; actually retired members of the military) in a glassed-in cage would ask to see your identity card. After my first few days I just held my ID card up to the car window and the guard waved me through. I quickly learned that the base was off-limits to all non-security personnel between the hours of 6:00 pm and 6:00 am. No overtime there.
After I settled in I took a look at the system—which was running very slowly indeed. It didn’t take long to spot a batch job running at an elevated priority; high enough that it was blocking interactive users from accessing the system. The batch job was the daily backup procedure. Two questions: 1) why was the backup running during prime time? and 2) why was its priority raised?
The operator responsible told me it took two 9-track reel-to-reel tapes to perform a complete backup. He arrived at work at 6:00 am to start it, but, as each tape took about two hours, backup time ran into work time. He raised the priority of the job so that it would execute faster.
My first response: it should not take a 9-track tape two hours to fill with backed-up files. Raising the priority of that job was counter-productive because a job cannot run faster than the device it is writing to. Tape drives are slow, but not that slow. Lowering the priority of the job to a more reasonable level and increasing the buffer size, so that it wrote more data at a single time, cut the execution time down closer to an hour per tape.
My second response: why are you waiting until 6:00 am to start the backup? Why not mount a tape before leaving the previous day and have the job start executing at, say, 4:00 am. That way, by the time humans were allowed on-site, at 6:00 am, the job would be waiting for its second tape mount—and that should take less than an hour, thus finishing the daily backups by 7:00 am well before any scientists arrived to start their daily shift.
Both steps were simple common-sense solutions. I sometimes irritated people I worked with by asking: “why are you doing it that way? Why not…” It didn’t matter where I worked or in what field, I usually saw a more efficient way of doing something and ran into defensiveness and resentment when I pointed it out. The only way I was ever truly happy at work was when I was either the “expert” who they had to listen to, or the boss (who they also had to listen to). That way I could implement what, to me, looked like obvious improvements that apparently weren’t so obvious to others. The times when I was in the kind of position where I could make improvements in the work-flow without running into snarling and snapping mother wolves protecting the old ways, I always received praise and complements from higher ups, the reason being that my improvements were genuine improvements: just like resetting job parameters to speed up writing to tape and starting the job before humans arrived to mount the second tape.
They kept me around at the research facility for a while; first, writing documentation, then, when that was done, writing a program that would automatically take the data stored on old 9-track tapes and write it to cassette tapes. Three 9-tracks could fit onto one cassette and cassettes required a lot less storage space. That was fun. I got to explore the actual physical and logical structures that controlled tapes because I had to over-ride them to write three tapes onto one. Of course the program kept track of everything and printed out labels to put on the cassette covers listing the contents.
While I was working on that the system suddenly slowed down one afternoon. What the? I identified an interactive session that was running at an elevated priority. Even though I could do anything I wanted to on a system, having full access to everything, I would never consider raising the priority of my session except in a few exceptional emergency situations. I knocked the priority of the run-away session back to where it was supposed to be. Ten minutes later, there it was, running at a high priority again. Time for a closer look. The account in question was assigned all system privileges. Impossible: I was the only one who was supposed to have such access. Even operators were restricted in what they could do. I fixed the account by stripping away all the privileges that a common user had no right to. End of problem.
Until a few days later. There was that same account running at an elevated priority, locking everyone else out of the system. And, the account once again had full system access. There were only two ways this could have happened: either my—or the system account that was reserved for upgrades—had been broken into; or, someone had unauthorized access to the computer room. It was the latter. In those primitive days of computing we did not have monitors and keyboards connected directly to the computer in the computer room, we had teletype machines. In other words, every command and response was printed on fan-fold paper. That system solved a few mysteries during my career.
Because the console was wired directly into the machine it had access to everything. That was intentional so that a technician could work on a failed machine. Someone, presumably the owner of the account, had entered the computer room and typed the commands necessary to give his account full system access. Now most computer rooms were locked with a card-scanner or a cipher lock so that only those who needed to be there could actually enter the room. You would think that at a secure military research site that this basic security feature would be in place. It was not. The computer room door was left wide-open at all hours.
I reported the incident to the security team who immediately had the computer room locked. The employee was given a stern dressing-down and warned. I heard from the people working at the site a few months after I had moved on that the culprit had been caught trying his old trick again and had been fired on the spot. So, what had he gained at the expense of his career? a few minutes of uninterrupted access to a CPU. It wasn’t as if he was doing important work at the time; he had been playing a computer game.
No comments:
Post a Comment