Read an Excerpt
The aim of this book is not to be just another "Guide for System Administrators," but rather a workshop manual that describes the tasks that need to be performed to build a complex network using the standard components delivered with the system.
We present the chapters in the same chronological order that the system administrator follows to build systems in real life. For example, we start by adding users onto a single system, add the system to the network, move on to configuring services such as NFS and NTP (which rely on the newly configured network), and so forth until we have built a complex of networked machines using NIS, NTP, and a multitude of other services.
We describe an environment consisting of a number of networked machines, including connections to the outside world. These systems will be used as the basis for all the examples, although the chapters can be isolated and will remain general enough to be adapted to any system.
So, what will you see in the book? We've covered all the tasks you'll need to get the environment up and running, including some of the following:
- We'll describe the boot process and talk about details such as the PROM, starting the system, the initialization process, and the shutdown process.
- We'll discuss users, create them with useradd and RBAC, and work through assigning quotas to them. When we move on to permissions, we'll look at "general" details, along with setuid, setgid, and Access Control Lists (ACLs).
- We'll add SCSI devices and look at how things like the device tree, instances, and path_to_inst work. We'll also add a custom tape device and create an st.conf entry for it. We'll learn about the different types of file systems and how things like superblocks and inodes are used. Then we'll partition, add, and use the devices within our system.
- We'll discuss class-based and classless IP addressing schemes. Then we'll split our environment into two subnets and configure them both. We'll include routing and external gateways to the Internet. We'll also use PPP to provide connectivity into remote networks, which also means configuring the associated UUCP databases.
- We'll configure services on the system to aid administration. We'll create an NTP server, after looking at how "time" works, and add some NIS masters/slaves to provide centralized administration. Within NIS we'll also create a custom map and tighten password security.
- We'll look at DNS and configure our domain for the public-facing machines. We'll also add a small mail server to the system, configure sendmail.cf using the m4 macroprocessor, and update the DNS entries to suit.
- We'll take an in-depth look at packagesbuilding our own in the process. We'll also work through the patching mechanism.
- Lastly, we'll look at some of the tools that are available to back up and restore all this data that we've created.
We firmly believe that showing lots of code examples is a very good way of explaining how the operating system works. As anyone who has worked with UNIX knows, there are many different ways of performing nearly every task. All users have their favorite commands they use to do this; some people will only use awk, while others know sed inside out. For this reason, we have tried to use different commands to perform the same task throughout the book. We hope this will be a useful way of showing some of the various options.
All the tasks we carry out are command-line based, which means they will all work regardless of whether you are using a graphics console or working remotely via a telnet connection. We've adopted this approach because we think it's a better way of seeing what's happening, rather than simply clicking on a button in a GUI.
The major system configuration details are described in Appendix A to allow you to see which machine we are talking about at a glance, which we hope will let you become familiar with the system we are describing.
Each chapter begins with a list of all the relevant online manual pages (along with their section numbers). We have taken the view that it is better to use code examples, wherever possible, to illustrate how commands may be used rather than provide a series of reference pages, which the user must determine how to use. Everyone has access to the manual pages, either online or at sites such as Sun's documentation site (http://docs.sun.com), these can be referred to for further information about any of the commands that have been run.
After that, we list the files that may be affected when carrying out any actions shown within the chapter. This allows the reader to follow the changes to these files as the reader progresses.
Next, we describe the task in depth: explaining what is taking place, showing the commands that need to be run, and showing the output that will be seen during execution.
We also have a section that shows ways of checking the parts of the system that relate to the chapter. For example, in the chapter that talks about adding users, we show how to check the password, shadow, and group files for invalid entries or corruption. These may be built into a suite of utility programs that are useful to the administrator for both general use and checking the health of the system.
In short, the aim is to provide the user with enough information to determine how commands are working while providing the information to allow them to determine how to take things further.
The code examples used have all been built and tested on the systems used to describe the setup. We have tried to achieve a balance between including lots of comments in the code and making it readable.
We create a number of tools, which can be used to monitor and manage the system, and define a hierarchy that we will use to configure both the servers and the clients. The examples try to use this defined hierarchy, but again it can be easily altered should you not wish to use our definition.
Public Domain Tools
There is no denying that many public domain tools are very useful, and that some are even considered irreplaceable! Even so, we are aware that several companies do not allow these to be loaded on to their systems. For this reason, we have tried to limit the commands we use to those supplied with the operating system.