Page 319
Page 320
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.
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:
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.
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
Page 321
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.
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.
That is correct—you can change the root password this easily:
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.
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.
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
Page 322
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.
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.
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.
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.
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.
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