UNIX System Administration Handbook - Evi Nemeth [475]
This phenomenon is more prevalent at universities than at commercial sites, but it probably happens everywhere to some degree. Although it seems fun, it can easily be carried too far and should be strictly discouraged. There are enough real whammos for a new sysadmin without adding more, even in jest.
Iterative refinement
A sysadmin will often think that a problem has been fixed, only to receive several more trouble reports as the task slowly gets done completely and correctly. This process can occur because the user who first reported the problem did not describe it clearly or suggested the wrong solution. Equally often, it can happen because the sysadmin did not test the solution carefully.
Some common complaints include:
• Man pages and documentation not installed for new software
• Software not installed everywhere
• Software that turns out to be owned by the sysadmin or installed with permissions that are wrong.
Testing is boring, but a busy sysadmin can cut productivity in half by skipping it. Every trouble report costs time and effort, both for users and for the sysadmin. The job is not done until all operational glitches have surfaced and been taken care of.
A common problem is that a user reports that “X doesn’t work on machine Y” and the sysadmin goes to machine Y and tries command X and it works fine. The trouble report answer comes back “works for me” with a bit of an attitude attached. If the sysadmin actually tried the command as the user who submitted the report (for example, executing sudo su - username in front of the command), he might nail the exact problem on the first try. The “- ” argument to su causes the resulting shell to use the environment of the user you are su ing to. Ergo, you can really reproduce the environment that was reported not to be working.
Users can become upset when a problem is not completely solved on the first attempt. Try to set their expectations appropriately. It is often useful to get the user who reported a problem to work with you in solving it, especially if the problem relates to an unfamiliar software package. You will obtain additional information and the user will be less likely to think of your relationship as adversarial.
27.8 WAR STORIES AND ETHICS
Why ethics? A sysadmin’s job involves a significant level of trust, from respecting users’ privacy to protecting the company’s trade secrets. Trust relationships go both downstream with your users and upstream with management. Without that trust, it’s very hard for a sysadmins to do their jobs well. Your personal and professional integrity are priceless; protect them as you earn the trust of your users, your peers, and your managers.
This section contains war stories that illustrate some ethical dilemmas a system administrator may face. Some of the stories are our own, and others have been harvested from external sources, perhaps Nth-hand and perhaps not entirely in their most accurate forms.
Boss’s mistake #1
A department chair incorrectly sent personnel data to the entire faculty instead of to the executive committee for which it was intended. He asked a student sysadmin who was working that weekend to edit faculty members’ mailboxes and remove the message. Should the student do it? Should he refuse? Should he look at the message and decide for himself if it was really serious enough to warrant an invasion of privacy?
In this instance, the sysadmin did do as he was asked, but he demanded that the chairman send mail to the faculty members explaining what had happened. He also stipulated that there be a witness to watch him trim mailboxes and verify that he did not browse around while editing. This was a good solution and one that both the sysadmin and the chairman felt comfortable with.
Boss’s mistake #2
A new secretary at a large computer manufacturer in the midwest was new to UNIX and email. At the end of her first week, she sent her boss a message about how nice the