Chapter 1
Topics in Administration
UNIX administrators are faced with many tasks during normal, day-to-day
operations. This first chapter deals with some of the tasks that most UNIX administrators
wish had some simple solutions.
High on the list is
the capability to automate routine tasks, something that is vital to a system
administrator. The life of an admin is a busy one, and if you have to do boring
tasks over and over manually, you will burn out fast. In this chapter, you'll
find examples of ways to automate day-to-day issues that can cut the time you
spend on them in half. For this reason alone you should always look for ways
to automate your environment as much as possible. Make sure you put in plenty
of notification routines so that if something does go wrong, you'll be
the first to know about it.
Another troublesome issue for administrators is system tuning.
However, you need to be careful: you might think you are tuning one thing when,
in fact, you might be breaking another. Some of the examples that follow will
deal with tuning the system in one way or another. Think before you make the
changes, and remember, what might be okay for one system might not be for the
other.
Please keep in mind, not only for this chapter but every time
you work on a system, these important questions you should ask yourself every
time you are about to make a change to the system:
-
-
1.Do I need to test this procedure?
Yes! Any time it is possible to test the change on a similar system,
do it! Take the time (if you can). If you don't, you might pay the
price later, and I mean later as in 2:00-in-the-morning later. If
you do not have a development system to test changes on, you are forced
to schedule time on the production system. See whether management backs
you on this one. They might if you can justify your actions well enough.
-
-
2.What is my back-out plan?
Always have a back-out plan, no matter how simple the change is, in
case it doesn't work. If the worst-case scenario takes place, know
what your options are.
-
-
3.How will the change affect
the system? You must always try to look at the broader scope. There
are instances where a little change can be made for one application and
the entire system or network of systems becomes affected. Installations
of third-party applications are notorious for this.
-
-
4.How will this change affect
my environment? There are times when one change can affect an entire
environment. For example, running NIS/YP, exporting NFS filesystems, and
modifying soft links are a few ways to affect your environment. Make sure
something you do on your system doesn't affect others without their
knowledge.
-
-
5.How will the change affect
my users? This is one of the most important questions of all and one
you really have to ask yourself. If the user is affected, your phone will
be ringing nonstop.
-
-
6.Should I notify anyone?
I will discuss this more in Chapter 9, "Users,"
but be aware that notification is the key to really great support. The more
people are aware, the more they will respect your abilities.
-
-
7.What is the worst-case scenario
if things go wrong? This is related to my advice to have a back-out
plan. You should always look at the worst-case scenario for any change and
attempt to anticipate a course of action if it happens. Remember that there
is always a chance of it happening when computers are involved.
-
-
8.Am I making this change
during the right time of the day? This question can be answered in
many different ways. Most admins like to say, "No time is a good time;
it has to be done!". As you all know the best time is in the evening
and on weekends. If something were to go wrong, you usually have the greatest
amount of time to fix the problem during this period. There is one exception
to this rule though: shops that run 24-7. For changes that don't take
much time and where user testing is involved, first thing in the morning
is best. If the first couple of users that arrive in the morning begin to
see some serious problems, you can always back-out on the spot if you need
to. Users love seeing you there at work before them. It makes them feel
as if you'll be on top of any situation that might take place.
-
-
9.Is there a better way?
In UNIX there is more than one way to complete most tasks. You should try
to find out whether there is a better way to accomplish what you're
trying to do. You should always be open to new ways. Keep your mind open
to new fresh ideas. Don't always go on your first thought. Even if
a user is rushing you do something now for him, take your time and
look for the best method for solving the problem.
-
-
10.Do I have time to make
this change now? The last thing you want to do is rush through the
job. You should always make your best attempt to follow through until the
end. A quick patch is okay too, but don't leave the problem finished
half way. If you leave the users hanging on too long with a partial fix,
your users will start to lose faith in you.
Try to keep these questions in your mind as you begin to make
changes to the system or solve the various problems that take place throughout
your day. In time, some administrators start to believe that they can dive straight
into a sink-or-swim situation thinking they'll come out swimming, but then
find they are sinking because they didn't ask a couple of these simple
questions. Take the time and ask the questions.
1.1 Collecting System Information
1.1.1 Description
For any new computer, collect the information that it contains.
Example
Flavors: AT&T, BSD
At the very least, collect
the following information for each system that you have:
% hostname
% grep `hostname` /etc/hosts | awk '{ print $3 }'
% grep `hostname` /etc/hosts | awk '{ print $1 }'
% hostid
On the front of most computers
On the front of most computers
% uname -a
% uname -a
% uname -a
Can be found at boot time
% dmesg
% uname -a
% uname -a
% uname -a
% df
- Other pieces of information to consider are
A copy of all the NFS mounted filesystems
NIS/YP configuration
A listing of all OS packages installed
A listing of all patches installed
Complete disk drive settings and configurations
All relevant software license keys and codes
Any custom soft links that were created
A copy of the settings and configurations for all defined
printers
Reason
As an environment grows or more machines need to be maintained,
it is best to always have a report of the configuration of the system.
Real World Experience
One of the worst things that can happen to even the most experienced
UNIX administrators is to open up a trouble ticket with a vendor to replace
a disk drive or memory and not have the answer to the simplest of questions:
"How big was the drive?" or "What size SIMMs were in the system?".
It takes only a second to gather the information when the computer first arrives.
Have the information readily available.
If
a system drive dies and you have a copy of the configuration (and good backups),
you can label the drive with the same configurations as the dead one, restore
from your backups, and be back in business.
Other Resources
Man pages:
df,
hostname, hostid, uname
Internet:
SysInfo home page-- http://www.MagniComp.com/sysinfo/
© Copyright Macmillan USA. All rights
reserved.
Previous
Section