Some of those problems continue to live on to this day.... I have my .login/.profile set term title when I log in...though there are places where its not done or it doesn't work. And, it doesn't reset automatically if you get disconnected. Though normally I still check to make sure I'm on the right host first....but sometimes when you're in a hurry....these things happen.
Once upon a time, when I was a software engineer. I was working on a large and significant change set..... and was cleaning after a compile with "rm *.o", except a space crept in...and it told me .o was not found. Yeah...all my work was not found either. Unlike some of my co-workers, at least I was doing work from my homedir on the main fileserver. Instead of on desktop workstation's disk. The company only backs up the servers it knows about...no workstations or PCs are backed up. It also uses an explicitly listed filesystems backup policy....so there'd be times we'd go to get something restored, and find that they never added the directory to backups...so started mounting new filesystems under a path that is backed up, and symlinking form where we really wanted the filesystem to go. Though that caused problems with most user restore requests :) Though that problem will probably live on forever, because of NFS. Users only seem to know what the mount is, and not request the export name, even though they had to know this when they asked us to set up the mount in the first place. And, the regular backup admin doesn't seem to check for that case when its not a regular mount. IE: we have a normal convention on where NFS filesystem are mounted....though its not forced. Back when I started...Unix systems were installed from piles of floppies....first 5.25" ones later 3.5" ones....seemed later on it was closer to 100 disks. Feels like that's how many it took to install my first Solaris system. Was also a pain later when it was taking 7 tapes to back up the system. But, I did it....along with differentials and cumulative . It was lucky when the drive crashed...it right after a cumulative. Was fun installing from disks, and then finding that one of the disks near the end is bad.... I'm not sure how the destroyed the NIS master at my last job....except that they said it wasn't recoverable, even though I had left a CD to restore it from baremetal. And, I've heard they can't figure out how to promote a slave....so they've just been continuing along with just the NIS slaves as they were before the master died. We used have an rdiff propagation system for configuration management...and the server was an old SunOS 4.1.3 box on a shelf....probably was the disk was small and the root fs would fill up now and then, so somebody would have to find a session and try to find something to clean up now and then. I'm the new guy, and I knew to leave the vmunix file alone. But, one day the Unix manager decides to help us all out and immediately deletes the vmunix file. That was probably the first sign that maybe she didn't actually know much Unix, even though she got the job through seniority. Now that she's a devop, she reminds us regularly that how little she knew with the kinds of tickets we get. More recently, one of the admins that used to work for her that had to be fired...now works with her in the devop group. He had previously applied twice to come back to work in our group....both times threatening legal action. The second time the search committee chair accidentally let slip that it was a comments made by one of his references (starting with, something to the effect of "I didn't know I was listed as his reference and I find it strange given what I think of his shortcomings....") So, he threatened to sue his reference. Didn't matter that he didn't meet the technical requirements for the job. Basically for hiring it comes down to, do we think the person knows what they need to know and is the person somebody that will fit in. Though at one time there were two distinct groups within our department, but everybody in the other group has quit....to eventually where they all work together somewhere else....twice. L
_______________________________________________ Discuss mailing list [email protected] https://lists.lopsa.org/cgi-bin/mailman/listinfo/discuss This list provided by the League of Professional System Administrators http://lopsa.org/
