Red Hat Enterprise Linux 3 系统管理入门指南

需积分: 1 70 浏览量更新于2024-06-26 收藏 3.03MB PDF 举报

"Red Hat Enterprise Linux 3 Introduction to System Administration" 本文档是关于Red Hat Enterprise Linux 3系统管理的入门教程，由Red Hat公司于2003年发布。它旨在帮助用户理解和掌握在企业环境中使用和管理Red Hat Enterprise Linux 3所需的基本技能。 **Red Hat Enterprise Linux 3 简介** Red Hat Enterprise Linux (RHEL) 是一个商业级的Linux操作系统，专为企业环境设计，提供稳定、安全和高性能的服务器平台。RHEL 3是该系列的第三个主要版本，发布于2003年，它基于Fedora Core项目，提供了强大的服务器功能和全面的技术支持。 **系统管理基础** 在本教程中，学习者将接触到以下关键的系统管理主题： 1. **安装与配置**：包括如何规划和执行RHEL 3的安装，磁盘分区，网络设置，以及系统初始化配置。 2. **软件包管理**：通过RPM（Red Hat Package Manager）进行软件的安装、更新和卸载，以及使用yum工具来管理依赖关系。 3. **用户与权限管理**：理解Linux的用户和组概念，如何创建、修改和管理用户账户，以及权限控制（如chmod, chown, chgrp命令）。 4. **文件系统与存储管理**：学习不同类型的文件系统（如EXT3），挂载和卸载文件系统，以及磁盘配额的设置。 5. **网络服务**：配置常见的网络服务，如DNS、DHCP、HTTP、FTP服务器，以及防火墙规则的设定。 6. **日志管理**：了解系统日志的重要性，如何查看和分析 `/var/log` 目录下的日志文件，以及日志轮换的设置。 7. **进程与任务调度**：管理运行中的进程，使用cron进行定期任务的安排。 8. **故障排查**：学习如何使用诊断工具，如dmesg、top、ps等，来识别和解决问题。 9. **安全增强**：包括SELinux（强制访问控制）的介绍，以及如何实施基本的安全策略。 **开放出版物许可证** 文档遵循Open Publication License 1.0或更高版本，允许自由分发和修改，但对实质性修改后的版本分发有特定限制，且商业用途的纸质出版需获得版权所有者的许可。 **结语** "Red Hat Enterprise Linux 3 Introduction to System Administration" 是一套宝贵的资源，对于那些希望在企业环境中部署和维护RHEL 3系统的初学者来说，它提供了一个全面的学习路径。通过深入学习，读者将能够有效地管理RHEL 3服务器，确保其稳定、高效地运行。

4 Chapter 1. The Philosophy of System Administration

module to a faster model, and reboot. Once this is done, you will move the database itself to faster,

RAID-based storage. Here is one possible announcement for this situation:

System Downtime Scheduled for Friday Night

Starting this Friday at 6pm (midnight for our associates in Berlin), all ﬁnancial applications will be unavail-

able for a period of approximately four hours.

During this time, changes to both the hardware and software on the Finance database server will be per-

formed. These changes should greatly reduce the time required to run the Accounts Payable and Accounts

Receivable applications, and the weekly Balance Sheet report.

Other than the change in runtime, most people should notice no other change. However, those of you that

have written your own SQL queries should be aware that the layout of some indices will change. This is

documented on the company intranet website, on the Finance page.

Should you have any questions, comments, or concerns, please contact System Administration at extension

4321.

A few points are worth noting:

• Effectively communicate the start and duration of any downtime that might be involved in the

change.

• Make sure you give the time of the change in such a way that it is useful to all users, no matter

where they may be located.

• Use terms that your users understand. The people impacted by this work do not care that the new

CPU module is a 2GHz unit with twice as much L2 cache, or that the database is being placed on a

RAID 5 logical volume.

1.3.2. Tell Your Users What You Are Doing

This step is primarily a last-minute warning of the impending change; as such, it should be a brief

repeat of the ﬁrst message, though with the impending nature of the change made more apparent

("The system upgrade will take place TONIGHT."). This is also a good place to publicly answer any

questions you may have received as a result of the ﬁrst message.

Continuing our hypothetical example, here is one possible last-minute warning:

System Downtime Scheduled for Tonight

Reminder: The system downtime announced this past Monday will take place as scheduled tonight at 6pm

(midnight for the Berlin ofﬁce). You can ﬁnd the original announcement on the company intranet website,

on the System Administration page.

Several people have asked whether they should stop working early tonight to make sure their work is backed

up prior to the downtime. This will not be necessary, as the work being done tonight will not impact any

work done on your personal workstations.

Remember, those of you that have written your own SQL queries should be aware that the layout of some

indices will change. This is documented on the company intranet website, on the Finance page.

Your users have been alerted; now you are ready to actually do the work.

Chapter 1. The Philosophy of System Administration 5

1.3.3. Tell Your Users What You Have Done

After you have ﬁnished making the changes, you must tell your users what you have done. Again, this

should be a summary of the previous messages (invariably someone will not have read them.)

However, there is one important addition you must make. It is vital that you give your users the current

status. Did the upgrade not go as smoothly as planned? Was the new storage server only able to serve

the systems in Engineering, and not in Finance? These types of issues must be addressed here.

Of course, if the current status differs from what you communicated previously, you should make this

point clear and describe what will be done (if anything) to arrive at the ﬁnal solution.

In our hypothetical situation, the downtime had some problems. The new CPU module did not work;

a call to the system’s manufacturer revealed that a special version of the module is required for in-the-

ﬁeld upgrades. On the plus side, the migration of the database to the RAID volume went well (even

though it took a bit longer than planned due to the problems with the CPU module.

Here is one possible announcement:

System Downtime Complete

The system downtime scheduled for Friday night (refer to the System Administration page on the company

intranet website) has been completed. Unfortunately, hardware issues prevented one of the tasks from being

completed. Due to this, the remaining tasks took longer than the originally-scheduled four hours. Instead,

all systems were back in production by midnight (6am Saturday for the Berlin ofﬁce).

Because of the remaining hardware issues, performance of the AP, AR, and the Balance Sheet report will

be slightly improved, but not to the extent originally planned. A second downtime will be announced and

scheduled as soon as the issues that prevented completion of the task have been resolved.

Please note that the downtime did change some database indices; people that have written their own SQL

queries should consult the Finance page on the company intranet website.

Please contact System Administration at extension 4321 with any questions.

With this kind of information, your users will have sufﬁcient background knowledge to continue their

work, and to understand how the changes impact them.

1.4. Know Your Resources

System administration is mostly a matter of balancing available resources against the people and

programs that use those resources. Therefore, your career as a system administrator will be a short

and stress-ﬁlled one unless you fully understand the resources you have at your disposal.

Some of the resources are ones that seem pretty obvious:

• System resources, such as available processing power, memory, and disk space

• Network bandwidth

• Available money in the IT budget

But some may not be so obvious:

• The services of operations personnel, other system administrators, or even an administrative assis-

tant

1. Be sure to send this message out as soon as the work is done, before you leave for home. Once you have left

the ofﬁce, it is much too easy to forget, leaving your users in the dark as to whether than can use the system or

not.

6 Chapter 1. The Philosophy of System Administration

• Time (often of critical importance when the time involves things such as the amount of time during

which system backups may take place)

• Knowledge (whether it is stored in books, system documentation, or the brain of a person that has

worked at the company for the past twenty years)

It is important to note is that it is highly valuable to take a complete inventory of those resources

available to you and to keep it current — a lack of "situational awareness" when it comes to available

resources can often be worse than no awareness at all.

1.5. Know Your Users

Although some people bristle at the term "users" (perhaps due to some system administrators’ use of

the term in a derogatory manner), it is used here with no such connotation implied. Users are those

people that use the systems and resources for which you are responsible — no more, and no less. As

such, they are central to your ability to successfully administer your systems; without understanding

your users, how can you understand the system resources they require?

For example, consider a bank teller. A bank teller uses a strictly-deﬁned set of applications and re-

quires little in the way of system resources. A software engineer, on the other hand, may use many

different applications and always welcomes more system resources (for faster build times). Two en-

tirely different users with two entirely different needs.

Make sure you learn as much about your users as you can.

1.6. Know Your Business

Whether you work for a large, multinational corporation or a small community college, you must still

understand the nature of the business environment in which you work. This can be boiled down to one

question:

What is the purpose of the systems you administer?

The key point here is to understand your systems’ purpose in a more global sense:

• Applications that must be run within certain time frames, such as at the end of a month, quarter, or

year

• The times during which system maintenance may be done

• New technologies that could be used to resolve long-standing business problems

By taking into account your organization’s business, you will ﬁnd that your day-to-day decisions will

be better for your users, and for you.

1.7. Security Cannot be an Afterthought

No matter what you might think about the environment in which your systems are running, you cannot

take security for granted. Even standalone systems not connected to the Internet may be at risk (al-

though obviously the risks will be different from a system that has connections to the outside world).

Therefore, it is extremely important to consider the security implications of everything you do. The

following list illustrates the different kinds of issues you should consider:

• The nature of possible threats to each of the systems under your care

• The location, type, and value of the data on those systems

• The type and frequency of authorized access to the systems

Chapter 1. The Philosophy of System Administration 7

While you are thinking about security, do not make the mistake of assuming that possible intruders

will only attack your systems from outside of your company. Many times the perpetrator is someone

within the company. So the next time you walk around the ofﬁce, look at the people around you and

ask yourself this question:

What would happen if that person were to attempt to subvert our security?

Note

This does not mean that you should treat your coworkers as if they are criminals. It just means that

you should look at the type of work that each person performs and determine what types of security

breaches a person in that position could perpetrate, if they were so inclined.

1.7.1. The Risks of Social Engineering

While most system administrators’ ﬁrst reactions when they think about security is to concentrate on

the technological aspects, it is important to maintain perspective. Quite often, security breaches do not

have their origins in technology, but in human nature.

People interested in breaching security often use human nature to entirely bypass technological access

controls. This is known as social engineering. Here is an example:

The second shift operator receives an outside phone call. The caller claims to be your organization’s

CFO (the CFO’s name and background information was obtained from your organization’s website,

on the "Management Team" page).

The caller claims to be calling from some place halfway around the world (maybe this part of the

story is a complete fabrication, or perhaps your organization’s website has a recent press release that

makes mention of the CFO attending a tradeshow).

The caller tells a tale of woe; his laptop was stolen at the airport, and he is with an important cus-

tomer and needs access to the corporate intranet to check on the customer’s account status. Would the

operator be so kind as to give him the necessary access information?

Do you know what would your operator do? Unless your operator has guidance (in the form of policies

and procedures), you very likely do not know for sure.

Like trafﬁc lights, the goal of policies and procedures is to provide unambiguous guidance as to what

is and is not appropriate behavior. However, just as with trafﬁc lights, policies and procedures only

work if everyone follows them. And there is the crux of the problem — it is unlikely that everyone

will adhere to your policies and procedures. In fact, depending on the nature of your organization, it

is possible that you do not even have sufﬁcient authority to deﬁne policies, much less enforce them.

What then?

Unfortunately, there are no easy answers. User education can help; do everything you can to help

make your user community aware of security and social engineering. Give lunchtime presentations

about security. Post pointers to security-related news articles on your organization’s mailing lists.

Make yourself available as a sounding board for users’ questions about things that do not seem quite

right.

In short, get the message out to your users any way you can.

1.8. Plan Ahead

System administrators that took all this advice to heart and did their best to follow it would be fan-

tastic system administrators — for a day. Eventually, the environment will change, and one day our

8 Chapter 1. The Philosophy of System Administration

fantastic administrator would be caught ﬂat-footed. The reason? Our fantastic administrator failed to

plan ahead.

Certainly no one can predict the future with 100% accuracy. However, with a bit of awareness it is

easy to read the signs of many changes:

• An offhand mention of a new project gearing up during that boring weekly staff meeting is a sure

sign that you will likely need to support new users in the near future

• Talk of an impending acquisition means that you may end up being responsible for new (and pos-

sibly incompatible) systems in one or more remote locations

Being able to read these signs (and to respond effectively to them) makes life easier for you and your

users.

1.9. Expect the Unexpected

While the phrase "expect the unexpected" is trite, it reﬂects an underlying truth that all system admin-

istrators must understand:

There will be times when you are caught off-guard.

After becoming comfortable with this uncomfortable fact of life, what can a concerned system admin-

istrator do? The answer lies in ﬂexibility; by performing your job in such a way as to give you (and

your users) the most options possible. Take, for example, the issue of disk space. Given that never

having sufﬁcient disk space seems to be as much a physical law as the law of gravity, it is reasonable

to assume that at some point you will be confronted with a desperate need for additional disk space

right now.

What would a system administrator who expects the unexpected do in this case? Perhaps it is possible

to keep a few disk drives sitting on the shelf as spares in case of hardware problems

. A spare of this

type could be quickly deployed

on a temporary basis to address the short-term need for disk space,

giving time to more permanently resolve the issue (by following the standard procedure for procuring

additional disk drives, for example).

By trying to anticipate problems before they occur, you will be in a position to respond more quickly

and effectively than if you let yourself be surprised.

1.10. Red Hat Enterprise Linux-Speciﬁc Information

This section describes information related to the philosophy of system administration that is speciﬁc

to Red Hat Enterprise Linux.

1.10.1. Automation

Automation of frequently-performed tasks under Red Hat Enterprise Linux requires knowledge of

several different types of technologies. First are the commands that control the timing of command or

script execution. The cron and at commands are most commonly used in these roles.

Incorporating an easy-to-understand yet powerfully ﬂexible time speciﬁcation system, cron can

schedule the execution of commands or scripts for recurring intervals ranging in length from minutes

2. And of course a system administrator that expects the unexpected would naturally use RAID (or related

technologies) to lessen the impact of a critical disk drive failing during production.

3. Again, system administrators that think ahead conﬁgure their systems to make it as easy as possible to quickly

add a new disk drive to the system.

剩余199页未读，继续阅读

rocazj

粉丝: 9
资源: 725

Red Hat Enterprise Linux 3 系统管理入门指南

Red Hat Enterprise Linux 6 性能优化指南

安装必备：Red Hat Enterprise Linux 7指南

Red Hat Enterprise Linux 5 安装指南

Red Hat Enterprise Linux 4 Introduction to System Administration

Linux AS4 Red Hat Enterprise Linux Introduction to System Administration

Red Hat Enterprise Linux 3 System Administration Guide

Red Hat Enterprise Linux 6 Logical Volume Manager Administration

Red Hat Enterprise Linux 5 Logical Volume Manager Administration

Red Hat Enterprise Linux 7: Desktops and Administration

Red Hat Enterprise Linux 5 Global File System

最新资源