0319-0322.html
来自「linux-unix130.linux.and.unix.ebooks130 l」· HTML 代码 · 共 390 行
HTML
390 行
<HTML>
<HEAD>
<TITLE>Developer.com - Online Reference Library - 0672311739:RED HAT LINUX 2ND EDITION:Essential System Administration</TITLE>
<META NAME="ROBOTS" CONTENT="NOINDEX, NOFOLLOW">
<SCRIPT>
<!--
function displayWindow(url, width, height) {
var Win = window.open(url,"displayWindow",'width=' + width +
',height=' + height + ',resizable=1,scrollbars=yes');
}
//-->
</SCRIPT>
</HEAD>
-->
<!-- ISBN=0672311739 //-->
<!-- TITLE=RED HAT LINUX 2ND EDITION //-->
<!-- AUTHOR=DAVID PITTS ET AL //-->
<!-- PUBLISHER=MACMILLAN //-->
<!-- IMPRINT=SAMS PUBLISHING //-->
<!-- PUBLICATION DATE=1998 //-->
<!-- CHAPTER=15 //-->
<!-- PAGES=0319-0340 //-->
<!-- UNASSIGNED1 //-->
<!-- UNASSIGNED2 //-->
<P><CENTER>
<a href="../ch14/0317-0318.html">Previous</A> | <a href="../ewtoc.html">Table of Contents</A> | <a href="0323-0325.html">Next</A>
</CENTER></P>
<A NAME="PAGENUM-319"><P>Page 319</P></A>
<H3><A NAME="ch15_ 1">
CHAPTER 15
</A></H3>
<H2>
Essential System<br>
Administration
</H2>
<B>by David Pitts</B>
<H3><A NAME="ch15_ 2">
IN THIS CHAPTER
</A></H3>
<UL>
<LI> Handling the All-Powerful Root Account
<LI> Maintaining the System—Implementing
Changes
<LI> Getting Help
<LI> Problem Solving—Logs
<LI> syslog
<LI> Wine—Accessing Windows Applications Under
Linux
</UL>
<A NAME="PAGENUM-320"><P>Page 320</P></A>
<P>Today, system administrators are at a premium. They are demanding high salaries, and
are receiving them. It does not matter whether the systems are Windows NT, Novell NetWare,
or UNIX. Part of the reason for this premium is simply supply and demand. The number
of knowledgeable system administrators is low, and the demand for them is high. The
other reason for this premium I have already alluded to. This reason is
"knowledgeable system administrators." The market is becoming flooded with system administrators with little skills
or training. People are entering the field because of the high pay. Many of them come with a
willingness to learn, but unfortunately, training them is a several-year and multi-thousand
dollar investment that corporations are incurring with no guarantee of a return on their
investment. This is particularly true when it comes to UNIX systems.
</P>
<P>UNIX is a very large and complicated operating system. It is also very powerful. Every
aspect of the system is under the direct control of the system administrator. But, what is it a
system administrator does? Here is a breakdown of the tasks that a system administrator must
deal with on a day-to-day basis:
</P>
<UL>
<LI> Account management
<LI> Assisting programmers
<LI> Assisting users with problems
<LI> Data backup and restoration
<LI> Meetings, both formal and informal
<LI> Problem determination
<LI> Software installation and configuration
<LI> System automation
<LI> System configuration and management
<LI> System integrity and other security issues
<LI> System startup and shutdown
<LI> User education
</UL>
<H3><A NAME="ch15_ 3">
Handling the All-Powerful Root Account
</A></H3>
<P>Although system administrators do all the things in the preceding list, they don't do them
as system administrators, per se; they do them as a special user called root, also known as
the superuser (su). Root is a special user account that is on every UNIX system. This special
user has full access to the system. The system ignores all permissions when dealing with root,
providing read, write, and execute permissions to every file and device known to the system.
</P>
<P>What does this mean in practical terms? This means that the command
rm -r / run as root will delete the entire system. It also means that root has access to all data. This is important
when it comes to backing up and restoring data, performing systems maintenance, and even for
security tasks. There are many commands that, with certain parameters, would be ideal to
hand
</P>
<A NAME="PAGENUM-321"><P>Page 321</P></A>
<P>
off to the users; bringing up print queues is a good example. Unfortunately, the same
command, with different parameters, takes down the print queues or could delete other users'
printouts. The root account is all powerful. It can be used to keep the system up and running as
a stable environment; it can also destroy the system and all data contained therein.
</P>
<P>It is because of this ability to manipulate the system that, as the system administrator, you
should take great care when you are using the root account—not only when you are dealing with
the system, but also when you are dealing with passwords. A password is the only
identification that the computer has for determining if people attempting to log on with a certain user ID
are who they say they are. Thus, anyone who gets root's password can control the system.
This also means that a Red Hat Linux system left unsecured can be booted from disk and the
root password changed.
</P>
<P>That is correct—you can change the root
password this easily:
</P>
<OL>
<LI> Boot the system with the boot disk.
<LI> Mount the root partition.
<LI> Edit the /etc/passwd file to remove any password for root.
<LI> Reboot from the hard disk.
<LI> Set a new password for root.
</OL>
<P>This is nice, and convenient, if the Red Hat system happens to be on a system in
someone's home with no other purpose than teaching the user how to use UNIX. But this is a
problem for a Red Hat system being used as an ISP in an unsecured location in a public building.
</P>
<P>Because of the power of the root account, each user on the system who has access to the
root password should not log in as root. When a task that requires root authority is needed,
the users should su to root (this is explained in greater detail in Chapter 19, "User Accounts
and Logins"), perform the task, and then return to their normal account. This procedure helps
to ensure two things. First, it helps to keep users from accidentally performing actions that
they did not intend to, but which are allowed by root. Second, it provides logging. The
/etc/login.defs is the file that defines, among other things, the
su log, the failed login log, and the list of who logged in last. Although logging does not stop an action, it will at least help to
determine who was performing the action.
</P>
<H3><A NAME="ch15_ 4">
Maintaining the System—Implementing Changes
</A></H3>
<P>The overall function of any system administrator is to keep the system up and running.
Not only does this mean applying the latest updates of software, adding and replacing
hardware, and adding new software, but it also means being part soothsayer, part instructor, and
part detective. The system administrator must
</P>
<UL>
<LI> Understand how things work
<LI> Know where to find things
</UL>
<A NAME="PAGENUM-322"><P>Page 322</P></A>
<UL>
<LI> Plan processes
<LI> Have a back-out plan and know when to use it
<LI> Make changes in small increments
<LI> Test all changes
<LI> Communicate effectively and in a timely fashion
</UL>
<P>Each of these seven items can, in and of themselves, be daunting. For example, it takes years
of training and practice to understand how everything works, and, just about the time you
figure everything out, it changes. The learning curve is steep and the changes are inevitable, but
does this mean that you ignore this area? Of course it doesn't. Without an understanding of
how things work, none of the other items can be accomplished effectively. As a system
administrator, you must be careful not to spend too little or too much time in any one of these areas.
</P>
<P>Fortunately, the first two items can be documented and referred to at a later time. As two
of the primary reasons for this book, they are covered throughout it. The other five items
are examined in more detail in the following sections.
</P>
<H4><A NAME="ch15_ 5">
Planning Processes
</A></H4>
<P>Red Hat is a complicated operating system. Many files and processes are dependent upon
other files and processes. Therefore, when you are preparing to make a change to the system, it
only makes sense to define a process for the task. The amount of planning and documenting
required for the task should, obviously, depend on the complexity of the task. It should,
though, at least touch on the following items.
</P>
<P>First, some kind of description of the task should be listed. Second, there should be
documentation of how this task is going to affect the system, including, but not limited to, the files
and processes affected. The third item should be a test plan. Finally, there should be some way
to back out of the change—to restore the system to its previous
configuration.
</P>
<H4><A NAME="ch15_ 6">
Creating a Back-Out Plan
</A></H4>
<P>Creating the back-out plan is the most important part of making a change to a system. In
determining the back-out plan, consider how long the task will take, how long testing will
take, and how long it will take to back out of the current process and return to the former
process. An important part of the back-out plan is a decision point—a predetermined point when
you decide to continue with the current process or to implement the back-out plan. This could
be a decision based on a time limit, a lack of system resources, malfunctioning equipment,
poorly written software, or any other problem that requires returning to the old process.
</P>
<H4><A NAME="ch15_ 7">
Making Changes in Small Increments
</A></H4>
<P>It is easier to back out of small changes than it is to back out of big and multiple changes. It
is also easier to plan a series of smaller changes than it is to plan one large change.
Diagnosing problems is considerably easier when fewer things are changed than when a large number
of
</P>
<P><CENTER>
<a href="../ch14/0317-0318.html">Previous</A> | <a href="../ewtoc.html">Table of Contents</A> | <a href="0323-0325.html">Next</A>
</CENTER></P>
</td>
</tr>
</table>
<!-- begin footer information -->
</body></html>⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?