An Introduction to System Administration

An Introduction to System Administration
Chapter 1

Chapter Objectives Explore the world of the Sysadmin.
List the duties of the Sysadmin. List the skill set required of the Sysadmin. List a few personality traits of a typical Sysadmin.

What Is a Sysadmin? In a “small company” the Sysadmin may be the entire information technology staff. The Sysadmin may do everything from telephone, to fax, to computer management. Sysadmin may have to order supplies, deal with users, develop software, repair hardware, and laugh at the CEO’s jokes!

What Is a Sysadmin? In a large company the Sysadmin may be one member of a large group. May be responsible for one aspect of the data center operation. Programmers Database Administrators Network Administrators Operators May not even know what the CEO looks like.

Common Sysadmin Traits
A Sysadmin is a customer service agent! The Sysadmin must be able to communicate with technical and non-technical users. The Sysadmin should be patient, and have a sense of humor. The Sysadmin must be able to solve difficult technical problems. The Sysadmin must be able to work in a group setting. The Sysadmin must document activities in order to reproduce the results.

What Does a Sysadmin Do? Plan and manage the machine room environment
design machine room; specify cooling, cabling, power connections, and environmental controls (fire alarm, security) Install and maintain operating system software, application software, and patches. Determine hardware and software pre-requisites, which patches to install, which services to provide, and which services to disable.

What Does a Sysadmin Do? Schedule downtime to perform upgrades/patches, and test devices and schedule downtime to manage devices. Install and maintain user accounts; develop acceptable use policy and login-name policy; determine password change policies; install/configure/manage name services; and manage licenses. Determine disk quota, police/manage disk space, and monitor log files.

What Does a Sysadmin Do? Train users on software and security.
Ensure that users have access to documentation. Help users and provide help-desk support and problem tracking system to answer user questions. Configure network services: printing, file sharing, name service. determine file sharing needs and printing policies. manage security for shared resources.

What Does a Sysadmin Do? Install/maintain system devices, hardware/drivers; specify supported devices; determine spares practices. Install/configure/manage web servers, configure web access agents Configure and maintain business applications web agents calendar software order/problem tracking software

What Does a Sysadmin Do? Install/configure/manage e-mail software
mail transfer agents. mail readers. Configure and manage system security security for business applications, read security mailing lists and CERT notifications, install/configure "firewall" software to limit intruder access, collect evidence in case of successful intrusion and clean up after intrusion

What Does a Sysadmin Do? Configure and maintain connectivity between hosts monitor connectivity troubleshoot connectivity problems investigate complaints of poor response

What Does a Sysadmin Do? Configure and maintain system backups,
determine backup strategy and policies, and configure backup software perform backups monitor backup logs check backup integrity determine disaster survival plans perform restores

What Does a Sysadmin Do? Troubleshoot and repair system problems; and determine, locate, and repair/replace problem components Document the system, and develop and maintain documentation on local setup and local policies

Skills Required Delegation and Time Management Ethics
Ability to create/follow Policies and Procedures Desire to learn Customer Service Attitude Knowledge of technical aspects Hardware Software Problem Solving

Chapter Summary Sysadmins are often viewed as “a jack of all trades”
Sysadmins are customer service oriented. Sysadmins need to be able to communicate clearly. Sysadmins need to be able to solve problems Sysadmins need to be analytical thinkers.

Operating System Concepts, Terminology and History
Chapter 2

Chapter Objectives Define a few of the terms which we use in the book.
Understand a few basic concepts the are the foundation of Operating System design. Explore Operating System history. It may seem odd to put history in a technical book, but the history of both UNIX and Windows provides important clues about why they look the way they do today and why they have the system management quirks they do. This is of particular importance for the various UNIX incarnations.

Operating System Concepts
For purposes of this book, we'll consider an operating system to be the supporting software structure on which application programs run. This support structure includes the facilities to manage the computer system's resources and any utility programs needed to maintain and configure the operating system. The heart of system administration is configuring an operating system to create an environment suitable for the applications that the users require.

One can classify operating systems into two broad groups, early and modern, based on an analysis of three key features: Ability to share CPU resources between multiple programs. Methods employed to control access to system storage. Methods employed to protect system and application memory from corruption.

Early operating systems provided poor support for these three features. Running multiple programs, while possible, was done via a cooperative system which depended on each application program to release the CPU periodically to allow its peer processes to run. Protection of system storage was limited. Critical system files and user files were not protected from damage by user-level applications.

Finally, early operating systems did not provide memory protection for individual processes or the operating system kernel, thus allowing application “bugs” to result in damage to the parts of the operating system and applications loaded into memory. The poor reliability of early operating systems is (in part) due to the lack of support for these features.

Modern operating systems are those which provide good support for these three features. All of the UNIX variants, Linux, Mac OS X and Windows NT, 2000 and XP provide support for these features. As a result, these modern operating systems are more robust and reliable. At an abstract level, modern operating systems share several design concepts. Due to the size and complexity of modern operating systems, each consists of a layered design. A core part of the operating system forms the base of the design and directly interacts with the computer hardware. The core layer is usually loaded into memory when the computer boots and stays there throughout. A middle layer (or layers), made up of a suite of libraries and services, form an abstraction of the computer hardware and provide a connection to the core layer. Items in the middle layer may be loaded as needed. Riding on top of these middle layers comes the user shell (or Graphical User Interface - GUI) and the application programs themselves. The layers are protected from each other and connected to each other through specific Application Programming Interfaces (API's). This provides modularity, allowing individual components in a layer to be changed without effecting items in another layer. It also provides a framework for reliability and security through careful control of the interactions between layers.

UNIX systems refer to the Operating System’s core component as the kernel. A UNIX kernel handles the interaction with the system hardware. The UNIX kernel is specific to a particular computer or group of computers that share a common hardware design. UNIX kernels are built around one of two designs: a single, monolithic kernel or a micro-kernel.

The monolithic design is older and uses a single binary image to provide the resource management and hardware interface functions of the core layer. Some examples of the monolithic design are Linux and Solaris. A micro-kernel design uses a very small task management component and a suite of modules for all other resource management functions. Windows NT, Windows 2000, Windows XP and Mac OS X are examples of micro-kernel designs. Modern monolithic kernels extend their designs by allowing additional components, known as loadable modules, to be added to the kernel after it starts running. These loadable modules are used to provide additional features such as the code needed to control less commonly used devices, or 3rd party software to control new devices. Since a loadable module functions as part of the kernel, care needs to be taken to assure that any module loaded into the kernel is secure. Systems requiring high security will need to disable the capability of loading modules and use a purely monolithic kernel to avoid the possibility of changes to the core functions of the operating system. Linux and Solaris are two examples of monolithic kernel designs that include loadable modules.

The recent incarnations of Windows; NT, 2000, and XP share a similar layered construction approach with UNIX. These recent versions of Windows are based on a micro-kernel design using a small kernel layer and hardware abstraction layer at their base. The middle layer is made up of dynamically loaded libraries and services. The applications layer contains the familiar applications such as text processors, spreadsheet, web browsers, etc. Note that the dynamically loaded libraries (DLLs) found in Windows differ significantly from the loadable kernel modules found in some UNIX variants. Loadable modules are specific to a given kernel and one generally cannot have multiple versions available at the same time. DLLs do allow for multiple versions often resulting in mismatched DLLs. These instances of incorrect versions for a DLL and a given operating system kernel or application program, is a common source of problems on Windows systems.

Hardware designs are often called hardware architectures. Fine distinctions between hardware architectures matter most at the core level of the operating system. Differences such as “Pentium III versus Intel 486” or “SPARC 4m versus SPARC 4c” are important in the selection of a kernel or operating system distribution. On many vendor’s hardware this simple description is sufficient to make a choice of operating system.

On PC hardware, the hardware architecture is often only part of the information needed to select an operating system. The variety of PC hardware (models of video, I/O, and network cards) all require specific software drivers. The availability of drivers for a specific device and a specific operating system is critical. All components in the PC, including each interface card and the motherboard, need to be supported by the operating system vendor

At the application layer level, the hardware architecture distinctions become less fine. At this layer general categories such as "Intel x86" or "SPARC" are sufficient to describe whether a particular program binary will run on a particular machine. This general hardware description is sometimes called the application architecture. The application architecture is often stated more completely as a combination of the general hardware architecture and the operating system. You will frequently see application architectures described as Linux x86 or Solaris SPARC. Still more detailed specifications such as Linux x86 libc5 or Linux alpha add the kernel version or libraries needed by the application to the description of the operating system and hardware architecture. The main purpose of these application architecture specifications is help match application binaries to the operating systems and hardware on which they will run.

History Lessons The development of the various flavors of UNIX, Windows and Mac OS give us clues to their administration and design.

History Lessons The simplified UNIX history tree is a mess.
A more complete and detailed history tree is even more confusing. A complete tree is about 12 pages long! (see One of the reasons for the numerous interconnections between branches in the history of UNIX has been the availability of the UNIX source code, either freely or under license, and the ethos of borrowing ideas and sharing modifications and fixes. From the start, UNIX was built by programmers for programmers, and the ability to hack on the operating system itself, fix bugs, add features and share those changes with others has been a core value of the world of UNIX.

History Lessons From the late 1970s to early 1980s, UNIX evolved into two related but distinct camps. One camp centered about a commercial UNIX developed by American Telephone and Telegraph (AT&T) . The AT&T versions were named System III and later System V. UNIX System V evolved from the earlier UNIX System III. This version of UNIX had great influence over the later development of UNIX due the publication by AT&T of the System V Interface Definition (SVID), a complete description of what UNIX was and how it was to behave. With compatibility as their goal, nearly every major UNIX flavor picked up some or all of the features specified in the SVID. Sadly, the publication and acceptance of the SVID did not bring about the unified compatibility it might have. Most of the commercial UNIXes are System V-like (to varying degrees) depending on how closely the vendor followed the published specifications. The result is an annoying list of minor differences where these operating systems might have been more fully compatible Common System V style UNIXes include Solaris, HP-UX, IRIX and AIX. Sun's operating environment, in particular, made a very major switch in 1987 from being SunOS, a BSD-styled UNIX operating system to the System V style UNIX known as Solaris.

History Lessons The other popular UNIX variant, Berkeley Standard Distribution or BSD UNIX, was funded by the Department of Defense's Advanced Research Projects Administration. Networking was added to BSD UNIX making it an important force in the early development of the Internet. BSD UNIX formed the basis for the early SunOS, IRIX, NeXTSTEP and later versions of BSD. The most common current BSD-styled UNIXes are the BSD triplets, OpenBSD, FreeBSD, NetBSD.

History Lessons Differences between flavors of UNIX become more apparent the more sophisticated the user becomes. At the most basic level, all UNIX variants share a common set of user level commands that function in a nearly identical manner with the exception of some option flags. More sophisticated users will note the different option flags. Programmers will note that the BSD and System V families of UNIX have significant differences in libraries and system calls. The differences between UNIX variants will be most apparent to the system administrator.

History Lessons From the perspective of a system administrator, a BSD derived UNIX has several noteworthy differences from its System V cousins. The option flags and output format for several programs, are different from their System V counterparts. BSD UNIXes use a small collection of run control files (e.g. /etc/rc, /etc/rc.local) which each start multiple service daemons. The BSD UNIX device naming convention for disk and tape drives usually uses a flat directory scheme with a letter, number, letter pattern (e.g. /dev/rz0a) to specify the device driver, device number and partition or density. From a system administrator's viewpoint, a System V derived UNIX differs from a BSD derived UNIX in a couple of areas. Some command option flags and output are different. The run control files on a System V styled system are numerous, with each one starting just one service. They are stored in a separate directory and links from the files into directories named for the various run levels are used to specify which services to start at given level and the order to start them in. This is covered in greater detail in chapter 4, System Boot and Shutdown Procedures. Finally, System V derived UNIXes use a system of sub-directories and number-letter sequences to name disk and tape devices rather then the flat arrangement found on BSD derived systems.

History Lessons So where does Linux fit into all this?
Linux is sort of a mutt as far as its orientation with regard to the BSD and System V styles of UNIXes. Many of the commands share the BSD style option flags and output Run-control files and other aspects of system administration vary between distributions. Linux owes its birth in part to additional restrictions AT&T placed on the use of UNIX source code for teaching. These restrictions led to the development of MINIX, an implementation of UNIX written by Andy Tanenbaum for teaching purposes. MINIX provided the inspiration for Linus Torvalds to write his own implementation of UNIX. The Linux kernel developed by Linus was combined with a suite of UNIX programs, mostly written by the GNU project, into a Linux distribution. When someone talks about Linux, they are most often referring to a distribution, a combination of the Linux kernel and the associated GNU utility programs. Linux distributions are sometimes referred to as GNU/Linux to signify the marriage between the Linux kernel, and the GNU compilers, libraries, and tools. In this book when we refer to Linux, we are referring to a complete distribution, including both the Linux kernel and the GNU tools.

History Lessons Where did Windows come from?
At nearly the same time the two major UNIX varieties were establishing themselves and the commercial UNIX derivatives were being born, the personal computer was being created. Bill Gates and Microsoft delivered the first PC operating system, the command line oriented Disk Operating System (DOS). Figure 2-3 in the text shows a simplified history of the popular Windows operating system. While the shift from PC-DOS to Windows was a major event in this history, the more important event for system administrators is the split between Windows 9x and Windows NT. Rather then continuing to extend the PC-DOS based Windows 9x series, Windows NT and it's progeny, Windows 2000 and Windows XP, were built on an all new micro-kernel designed by a team led by David Cutler who had previously led the VMS design group at Digital Equipment Corporation. It should come as no surprise that many of the features one sees in Windows NT such as the user privilege system and access control lists for file access control look very similar to the features one finds in VMS. The Windows 9x series are considered “consumer” operating systems. Their lack of the key features of a modern operating system limit their ability to be effectively managed in a multiuser environment. In the remainder of this book, we will focus on the “comercial” versions of Windows, NT, 2000 & XP.

History Lessons In an effort to compete with the Apple graphical user interface (GUI), the Windows Operating System was developed. Early versions of Windows lacked the maturity of the Apple GUI. The Windows development split into two streams: a “home” or personal version of Windows, and a “business” or commercial version. Recently, Microsoft has been trying to merge the two versions into a single offering. Windows NT adds Windows versions of several key features associated with UNIX and other modern, multi-user operating systems and not present in the PC-DOS based versions of Windows. These include full memory protection for the kernel and user programs, and facilities for networking and inter-process communications. Windows also adds a number of system services including a scripting engine shared by all applications. The main thing lacking in Windows NT at its initial release was the user interface enhancements and wide range of supported hardware found in the Windows 9x releases. The later history of Windows has been one of unification. With the release of Windows XP, the user interface enhancements and wide range of hardware support have been fully incorporated into the Windows NT based kernel and operating system. This integrated design is not without its problems for the system administrator. Some Windows design choices make the task of securing Windows more difficult. Shared resources such as the visual basic scripting engine, a part of the operating system that is available to every program, have been exploited in a wide number of ways to allow viruses, and other malware to spread widely on the Windows platform. Similarly, shared libraries and services on servers based on the Windows platform have had a poor history with regard to immunity to bugs that have resulted in network visible vulnerabilities. Web site defacements and break-ins are often the result of these vulnerabilities.

History Lessons Apple and Mac OS X
Driving along a third parallel set of tracks, Apple developed Mac OS for their Macintosh computer during roughly the same time frame as Windows. Inspired by the work Xerox had done on graphical user interfaces, Apple developed the Macintosh, the first commercially successful personal computer with a graphical user interface. Macintosh occupies an import place in history as it served as the inspiration and model for graphical user interfaces that would follow, including Windows and the various X windows based desktops found on UNIX. However, the early versions of Mac OS like the Windows 9x series suffered from their lack of support for the key features of a modern operating system.

History Lessons Apple and Mac OS X
NeXT Computers took the look and feel of MacOS and married it to a UNIX-like micro-kernel architecture to form the NeXTStep Operating System. When Apple acquired NeXT, the developers had an opportunity to update and expand the Apple GUI interface, resulting in MacOS X. After Apple's acquisition of NeXT, the history of MacOS merges into the history of UNIX. The NeXT operating system, NeXTSTEP, is based on the work on Mach, a micro-kernel operating system written at Carnige-Mellon University. Apple developed MacOS X using the modern NeXTSTEP as its base. MacOS X has both the Macintosh user interface and the OpenBSD UNIX interface riding on top of the Mach kernel. From a system administrator's viewpoint, MacOS X appears much like NeXTSTEP. The specialized NeXT utilities such as netinfo are there for basic user, host and network configuration management. The familiar UNIX utilities are very much like they are on a OpenBSD UNIX system. However, there are two important exceptions. The Macintosh user interface is based on Apple's proprietary windowing system, not X windows as found on other UNIX systems. While X windows servers are available for MacOS X, the native window system is proprietary. The second notable difference is the filesystem. The default filesystem of Mac OS X is the Macintosh HFS+ filesystem. HFS+ does not provide all of the filesystem features expected by UNIX, in particular MacOS has differences in where it stores metadata (file permissions and ownerships), filename case sensitivity, and case preservation. These differences create some unexpected situations that can result in security problems.

Summary Basic terminology and history gives the system administrator the background to take on the tasks she faces. Understanding some basic terminology aids in the choice of software, operating systems and hardware and forms a common language for broad descriptions of these items and their relation to each other. The history of the development of UNIX, Windows and Mac OS provides insights into the organization, tools and problems one faces on a particular type of system. An understanding and knowledge of this history allows a system administrator to more rapidly come up to speed when faced with a new system.

Fundamental System Administration Tools
Chapter 3

Chapter Goals To introduce reader to a few of the tools required to perform the duties of the system administrator. To introduce good practices for system administrators. File Tree navigation fundamentals. Introduction to the UNIX vi File Editor.

Fundamental Sysadmin Tasks
The daily tasks performed by a system administrator require specialized as well as common tools. System administration requires a way of working that is : craftsman-like, strives for a working practice aimed at producing robust, secure, and reliable systems. This chapter examines tools and practices common to many system administration tasks.

Fundamental Sysadmin Tasks
System administrators are knowledgeable users of the systems they manage. They need to know how to: navigate the file system, use basic user-level tools, use the ubiquitous vi editor, combine commands using pipes, employ a variety of graphical tools. It is assumed for the purposes of this chapter that the reader has a basic knowledge of the Windows and UNIX user environments.

Good Practices Good working practices are the threads that tie together the tasks performed by the Sysadmin. Good practices make tasks easier to reproduce, preserve system security/robustness, and maintain system functionality. System administrator involves managing details. Knowing how a system is configured, what patches have been applied, what services the system needs or provides, and any number of other items is a tremendous aid in solving problems. If you are new to the systems you are managing, a first step is to get a laboratory-style notebook and make a map of your network and an inventory of the systems. This map does not need to be complete at the start, but you should create it with an eye toward adding information as you go along. The type of information you keep depends somewhat on your environment, but basic network and system configuration data are a good start. Along the way, you will want to add system-specific quirks, such as odd potential problems or unusual things that need to be done when a system is rebooted. A list of local system modifications and installation procedures should form another section of your system administrator’s notebook. Careful organization can help keep system modifications corralled into manageable areas, but some system configuration information will need to be changed and reinstalled when a system is upgraded. Local installation customs and procedures will also need to be noted, not only for your use but for their use in teaching others and delegating tasks.

Good Practices Another part of the job is continual learning.
Establishing a discipline of carrying out daily, weekly, and monthly tasks is necessary in maintaining systems, identifying slowly growing problems, and preparing for unexpected problems. System administration is a rapidly evolving field. New tools and new versions of tools appear daily. Security threats and techniques to thwart them are continually changing. Reading books, such as this one and those listed in each chapter’s “References” section, is good a place to start. Short courses and technical conferences offer another avenue for education on current topics. Among the best of these are offered by the USENIX organization in concert with the System Administrator’s Guild (SAGE), and by the System Administration Network Security Institute (SANS). Contact information for both of these organizations is found in the “Reference” section at the end of this chapter.

Good Practices · Avoid using root or administrator as much as possible. Use a less privileged account, for which mistakes will be less drastic. · Avoid using wildcard characters, such as the asterisk (*), when running as root or administrator. · Make it a habit to create backup copies of files before you edit. · Allow plenty of time to complete the tasks you need to perform.

Moving Around the File Tree
The most basic tasks of system administration involve the manipulation of file storage. Understanding file system navigation tools, and being able to use them, are basic to managing a system. Both UNIX and Windows organize disk storage into a tree structure. UNIX unifies all file storage space, disks, remote file systems, and entries for devices and communications end points into a single tree. Windows takes the approach of creating a forest of trees, one for each disk or remote file system or share, with separate named entities (e.g., c:, lpt0)

Files within the file trees can be referred to by their full path names, traversing the tree from the root to the leaf and listing each directory as it is passed. Although providing the full path completely specifies the location of a file, it is more common to use a relative path; one that starts in your current location. Commands for traversal of the file tree: cd / chdir Change Directory pwd Show current location ls / dir List the files and directories

A less common set of commands gathers and displays file system space statistics. On UNIX systems, the df command reveals statistics concerning individual file systems in a system’s file tree, whereas the du command produces a list of the space consumed by directories. On Windows systems this information is available using a graphical file tree viewer such as the explorer program or the web browser. The graphical user interface (GUI) that is common today originally came from systems developed at Xerox’s Palo Alto Research Center. The Xerox Star was an early office system with overlapping windows, mouse pointer, and WYSIWYG text editing. Although the Star did not survive in the marketplace, it was seen by Steve Jobs (of Apple) on a visit to PARC. Inspired by the Star, Apple produced the LISA and Macintosh, bringing the GUI to a wide market.

Why vi Despite the graphical tools available for many system administration tasks, on UNIX systems, many tasks require file editing. Examples include maintenance of hosts and network files for networking, and of configuration files for daemons such as inetd and init. Few people really “love” vi. However, it is frequently the only screen-oriented text editor available for managing a system. Although not as easy to use as some editors, vi is widely available and should be accessible on any UNIX system.

Why vi Many editors cause problems when editing system files. For example: Pico and emacs do not (by default) place a newline at the end of a line of text. This causes many problems with editing files such as /etc/passwd, and other format sensitive configuration files. These editors may not have access to all of the resources that they require when the system is in single user mode.

Power Tools There are a number of general tools and techniques that are more frequently used by system administrators than by users. These include command shell features, graphical desktop tools, programmable filters, and scripting languages. Many of these are available on both UNIX and Windows in one form or another, although most have their roots in the UNIX environment.

Power Tools pipes - allow you to “pipe” the output of one command into another command as input. ps (task manager) – allows you to view the system process table. The ps command differs a bit among UNIX variants. The two major divisions are the BSD-style and the System V-style. more/less – pagination commands that allow you to view files one page at a time. grep – Get Regular Expression – find a pattern in a file. One of the fundamental design ideas in the UNIX command line interface is the modular combination of basic commands. Many UNIX commands were designed to allow them to be flexibly combined to process or filter information as it is passed from command to command. The vertical bar character, called a pipe, is used to form the connection between commands. Data flows from left to right between commands.

Power Tools tar – create a tape archive of files. Programmable Filters
Another class of tools that can be used with pipes or by themselves to massage a flow of data are programmable filters. Two common examples of filters are awk and sed. awk uses an interpreted command language, and treats input as though it were a textual database. sed – the stream editor, uses the regular expression language seen in vi and grep, and allows you to edit streams of input. One of the fundamental design ideas in the UNIX command line interface is the modular combination of basic commands. Many UNIX commands were designed to allow them to be flexibly combined to process or filter information as it is passed from command to command. The vertical bar character, called a pipe, is used to form the connection between commands. Data flows from left to right between commands. NOTE: When creating archives using tar, be aware that the path given to tar for the files or directories being archived is saved in the archive, along with the files and directories. If a full path is given (e.g., /home/dwight/AudioBooks), older versions of tar will not be able to extract the files and directories in any location other than the path they were archived from. Although modern tar commands have the ability to get around this using an option flag, it is a good habit to use a relative path, as demonstrated in the previous example. Archives created with a relative path can be extracted in any location.

Power Tools find – locate files by name, or file characteristics, or locate strings in files. perl – a very powerful interpreted scripting language. cygwin – a UNIX shell and utilities for use on Windows systems. One of the fundamental design ideas in the UNIX command line interface is the modular combination of basic commands. Many UNIX commands were designed to allow them to be flexibly combined to process or filter information as it is passed from command to command. The vertical bar character, called a pipe, is used to form the connection between commands. Data flows from left to right between commands. NOTE: When creating archives using tar, be aware that the path given to tar for the files or directories being archived is saved in the archive, along with the files and directories. If a full path is given (e.g., /home/dwight/AudioBooks), older versions of tar will not be able to extract the files and directories in any location other than the path they were archived from. Although modern tar commands have the ability to get around this using an option flag, it is a good habit to use a relative path, as demonstrated in the previous example. Archives created with a relative path can be extracted in any location. NOTE: One of the most important aspects of the Windows versions of perl and UNIX-like toolkits for Windows is their use in remote system administration. Command line tools such as these can be used remotely to perform basic administration tasks that would ordinarily need to be performed from the Windows console.

Juggling Multiple Tasks
Juggling multiple tasks is a fact of life for a system administrator: Monitoring network and system performance dealing with a never-ending stream of searching the web for information remotely accessing several systems Modern windowed environments help with juggling tasks by providing easily used graphical interfaces and tools for grouping related tasks.

Windowed Environments
Both Windows and UNIX provide some form of windowed work environment. Although these desktop environments all appear to be different, they have several common features that are of interest to the system administrator. First, note that all desktops allow for multiple windows. Switching back and forth between tasks or GUI tools is performed by mouse click or keyboard shortcut.

Windowed Environments
Second, all desktops offer terminal emulation, providing multiple command line interfaces. Multiple terminal windows are often used for connections to remote systems or to edit a configuration file while using another terminal window to test the configuration. Third, idle tasks can be reduced to icons or entries on a task management menu for easy access. Fourth, UNIX desktops provide a facility for switching between multiple virtual screens. There are add-on tools for the Windows desktops that facilitate the virtual screen facility.

General-purpose GUI Tools
Most system administrators handle a large volume of each day. A powerful mail agent is a requirement for dealing with this flood of information. A good mail agent for a system administrator should include filtering tools, for automating the task of sorting mail, and an easily navigated filing and searching system. Some recent mail agents are GUI based and make it easier to fully use their filtering and navigation features. As mentioned, information on GUI tools and windowed desktop environments is incorporated where it relates to the task at hand. Most of the tools covered are specific to a given task. However, there are several general-purpose GUI tools a system administrator should be aware of.

Web Browsers A vast amount of useful system administration information is available on the Internet and viewable via a web browser. Most UNIX and Windows platforms offer several web browsers, such as the popular Internet Explorer and Netscape Navigator. For basic information, viewing and downloading of files, nearly any web browser will work. However, a browser that integrates graphics and PDF file viewing allows a wider range of information to be viewed.

Virtual Terminal Perhaps the most common use of a windowed environment is a setup of multiple-terminal windows, connected to multiple systems. Terminal windows have several advantages over an ordinary terminal: Terminal windows provide variable scroll-back capabilities that provide easy review of output. Terminal windows can emulate various terminals, allowing a single workstation to act in place of one or more special-purpose terminals. Terminal windows also allow for easy transfer of small bits of text and command strings by incorporating “cut and paste” capabilities.

Spreadsheet Spreadsheets can be used effectively to automate a number of recordkeeping tasks. Typical uses of a spreadsheet are as a table of data that can be sorted and searched and as a progress checklist for larger tasks.

Summary careful and systematic work habits
The fundamental tools of system administration include: careful and systematic work habits a selection of basic software tools. editors, filters, file system navigation windowed environments power tools

Booting and Halting Chapter 4

Chapter Objectives Examine the sequence of events that occur when a system is booted. Examine the methods used to modify the boot sequence. Examine how to use the PROM monitor to select alternate boot devices. Examine the boot manager and boot loader. Examine how to shut a system down properly.

An Overview Of The Boot Sequence
When power is applied, the system resets all of the logic gates (chips) to a known state. A series of diagnostic tests (Power-On Self- Test, or POST) are run from the PROM Monitor to ensure that some minimal set of hardware components are available for system operation. Once the POST operation completes, the system loads a small “boot loader” program from the system PROM. The boot-loader loads the system boot block.

The system executes the code from the boot block. This program loads the secondary boot loader that will eventually load the operating system kernel and start it. Most secondary boot loaders allow the operator to select the device to boot from, as well as the program that will be loaded into memory and started.

The kernel creates a few necessary processes: the init process, a process scheduler, and usually a few memory management processes. The init process runs a series of start-up scripts that configure the system for multi-user operation. Now that we’ve see the basic series of events that occur during the system boot process, let’s examine some of the internal events that occur during each major step of the boot process.

Step 1: PROM Monitor The PROM monitor includes a small program (Power On Self Test, or POST) that initializes the system hardware, and runs a miniature diagnostic program. The diagnostics ensure a minimally operational base for the OS to run on. POST diagnostic routines do not guarantee that the system hardware is fully functional. Once the diagnostic completes, the PROM monitor probes the system busses to determine what hardware is connected to the system. Once the hardware has been probed, the PROM monitor loads and starts the second phase of the boot process; the boot block.

PC PROM Monitors PC BIOS Limited alternate boot device selection
Typically: Disk, CDROM, Floppy, and net. Sometimes alternate disk boot is supported. Configure/modify hardware settings Enable/disable device, change IRQ/memory ranges. Allows for device BIOS interaction PC Bios is actually a multi-level “monitor” Each device may have it’s own BIOS that is run by the master BIOS. The device BIOS initializes the individual device, and reports the status to the master. The master collects the results and tabulates this information for the OS.

Sun PROM Monitor Sun PROM Monitor Apple Monitor RS6000 Monitor
Actually a 2 level monitor which includes “new” and “old” modes. The SUN monitor includes a FORTH language interpreter. Allows the user to select alternate boot devices, enable/disable hardware features, probe devices, test devices. Apple Monitor RS6000 Monitor SGI and HP monitors The Apple Monitors Due to this limited functionality, many sysadmins do not consider that the Apple machines contain a viable a PROM monitor. In fact, there is a PROM monitor in the new Apple systems, albeit the user interface is still extremely limited! None of this mattered too much in the past, as the only OS that would run on an Apple computer was MacOS. Current- generation Apple computers can boot and run legacy MacOS, MacOS X (a UNIX-like OS), and Linux. In order to boot these alternate OS’s on an Apple required some form of a boot PROM. RS6000, SGI, and HP PROM monitors are functionally similar to the Sun monitor, but the user interface is very different. Refer to chapter 4 for more information on these monitors.

Step 2: Boot Block The boot block’s job is to initialize some of the system’s peripherals and memory, and to load yet another program, the secondary boot loader, (sometimes known as the boot manager) that will load the OS kernel. A boot block is typically placed on the disk as part of the OS installation process. The sysadmin should be familiar with the similarities and differences between the following boot blocks: Windows Boot Block Linux Boot Block Solaris Boot Block IRIX Boot Block MacOS and AIX Boot Block The boot block is often contained in the system PROM. This program knows how to find the primary storage interface. It looks in a specific location on the storage media, and loads the next “N” blocks of data into the system memory. Once the data is loaded into memory, the system attempts to “run” the data as though it were a program. If things went well, the data is a program, the secondary boot loader.

Step 3: Secondary Boot Loader
The secondary boot loader loads the kernel and starts it. The secondary boot loader often allows operator intervention: Select alternate kernel to load Modify boot parameters (single user, extensions, …) USE PASSWORD SECURITY HERE!!! Securing the boot process such that users cannot boot alternate media, or an alternate kernel, is a very wise step to take! The secondary boot loader is usually tailored to specific operating systems. The boot loader knows how to find/load/start a specific OS kernel. Recently, secondary boot loaders have become more intelligent, and many now know how to locate/load/start several Operating System kernels. These loaders are possible, because the OS vendors have published information telling how their boot loaders work, and where they expect to find the information required to load the kernel, and boot the system. A good example of this type of boot loader is the GRand Unified Boot loader (GRUB).

Linux Loader (LILO) # sample /etc/lilo.conf boot = /dev/hda delay = 40
password=SOME_PASSWORD_HERE default=vmlinuz-stable vga = normal root = /dev/hda1 image = vmlinuz label = net test kernel restricted image = vmlinuz-stable label = stable kernel other = /dev/hda3 label = Windows 2000 Professional table = /dev/hda

GRUB # /etc/grub.conf generated by anaconda timeout=10
splashimage=(hd0,1)/grub/splash.xpm.gz password --md5 $1$ÕpîÁÜdþï$J08sMAcfyWW.C3soZpHkh. title Red Hat Linux ( custom) root (hd0,1) kernel /vmlinuz custom ro root=/dev/hda5 initrd /initrd img title Red Hat Linux ( ) Emergency kernel (no afs) kernel /vmlinuz ro root=/dev/hda5 title Windows 2000 Professional rootnoverify (hd0,0) chainloader +1

The Windows Multi-Boot Loader
timeout=10 default=multi(0)disk(0)rdisk(0)partition(2)\WINNT [operating systems] multi(0)disk(0)rdisk(0)partition(2)\WINNT="Microsoft Windows 2000 Professional" /fastdetect multi(0)disk(0)rdisk(0)partition(1)\WINNT="Windows NT Workstation Version 4.00" multi(0)disk(0)rdisk(0)partition(1)\WINNT="Windows NT Workstation Version 4.00 [VGA mode]" /basevideo /sos

Step 4: The OS Kernel Once the kernel is loaded, and started, it probes devices. Some architectures use the PROM monitor to build a device tree that is handed to the kernel during the boot process. Other architectures require the kernel to probe the system busses for devices to build the device tree. Once the device tree is available, the kernel parses it, and each device is probed to determine if it is operational, (and if so, the driver module is loaded into the kernel). This search for memory and devices is sometimes referred to as auto-configuration.

Step 4: The OS Kernel UNIX Run Levels
All flavors of UNIX, and UNIX- work-alikes use similar foundations for the system run modes. As far as UNIX and its ilk are concerned, there are basically two run modes: single user (sometimes called maintenance mode), and multi-user. There may be several forms of the multi-user mode (with services, without services, and so on) on any given UNIX OS.

Step 4: The OS Kernel MacOS Run Levels
MacOS also provides for “multiple” run levels. On the older versions of MacOS, different run levels meant simply a choice between “boot normally”, or “boot without extensions”.” Now that MacOS X is a Mach/UNIX based kernel, there are more run levels available. The MacOS X kernel enjoys the same set of run levels, as do the other UNIX variants. WARNING: Early versions of MacOS X contain a nasty security hole.; if a user holds down the Command and “s” keys during a reboot, the system will come up in single- user mode, without prompting the user for the root password.

Windows Run Levels Windows has a limited set of run levels Multi-user
Safe Mode Safe mode with networking Typically used to repair damaged system.

Step 4: The OS Kernel Start-up Scripts
(Un)fortunately, within the OS world there are several “camps” of believers when it comes to how the system should start system services. The following sections provide an overview of the details of the Windows, MacOS, System V UNIX, and BSD start-up sequences, pointing out OS- specific oddities as applicable.

Step 4: The OS Kernel Typically, BSD variants include a run control (also known as an rc) script in the /etc directory. This allows the administrator to edit a single /etc/rc script to make it start a new service at boot time. Other BSD variants have simply increased the number of rc files in the /etc directory. For example, the FreeBSD start-up directory contains scripts with names such as /etc/rc.atm, /etc/rc.firewall, and /etc/rc.network. These individual scripts, respectively, configure the ATM network cards, cause the system to become a firewall, and configure the network links respectively. These scripts are called by the master script, /etc/rc The easiest way to “add” a new service to a BSD box is to develop a rc.servicename script, and test it manually. Once the script seems to work manually, edit the master /etc/rc script, add the lines required to make the master script call the new script. Then reboot the system (when convenient) to test that the script works in automatic mode. At this point you may want to roll the new script into one of the existing scripts, but that will require further testing, and another downtime (or two) in order to ensure that things work the way that you expect them to.

rc script problems Using a small number of rc scripts can cause problems: Startup becomes more difficult to test, as each script starts multiple services. Need to reboot system to test scripts. Not easy to “shut down” individual services using rc scripts.

System V Scripts System V employs a directory full of init scripts. Each System V variant seems to put these scripts in a different directory: Solaris /etc/init.d Linux /etc/rc.d/init.d HPUX /sbin/init.d Each script starts/stops one service. Symbolic, or hard links connect the /etc/init.d scripts into the correct run level directories (/etc/rcN.d/ where “N” is the run level between 0 and 6). As system enters a run level, the scripts in the corresponding run level directory are executed: First the K (Kill) scripts are run in numeric, then alphabetic order. Next, the S (Start) scripts are run in numeric, then alphabetic order.

System V Scripts Typical init script format:
grumpy% ls -lsa /etc/rc*.d/*afs* 2 lrwxrwxrwx 1 root other 15 May /etc/rc0.d/K66afs -> /etc/init.d/afs 2 lrwxrwxrwx 1 root other 15 May /etc/rc2.d/S70afs -> /etc/init.d/afs Typical init script format: #!/bin/sh Setup code (set environment variables, subroutine definitions, …) case $1 in start) Code to start service stop) Code to stop service *) Error handling code and/or usage message

Benefits of init Scripts
One of the benefits of using init directory scripts is that they are easily tested. The scripts may be manually invoked with the stop and start arguments as a check to determine whether they function correctly before creating the links to the rc directories, and trying them under actual system boot conditions. This procedure is recommended because it can help you catch mistakes that might interrupt the boot process and leave the system unusable.

Changing Run Levels The following commands are typically reserved for system maintenance activities. UNIX shutdown Command The System V init 0 Command The telinit Command NOTE: The shutdown, telinit, and init 0 commands can only be executed with root access. Windows Shutdown Command Legacy MacOS Shutdown Command

Emergency Measures # STOP-A pressed Abort at PC OxFOO31870. >sync
panic: zero syncing file systems done. 586 static and sysmap kernel pages 34 dynamic kernel data pages 179 kernet-pageable pages 0 segkmap kernel pages 0 segvn kernel pages 799 total pages (799 chunks) dumping to vp ff1b9004, offset 117 pages left pages left 101 pages left 5 pages left 799 total pages, dump succeeded rebooting... Sometimes OS level commands just won’t help. If thte system is completely hung, and ignoring keyboard input, sometimes you have to take drastic steps. SPARC hardware includes a special key sequence that is processed by the PROM monitor. If you hold down the STOP key, and press the A key at the same time, the system will revert to the control of the PROM monitor. At this point, you can use the “sync” command to cause the sytem to sync all memory to disk, and perform a controlled “crash and burn” reboot of the system. On PC systems, the CONTROL-ALT-DELETE will often accomplish the same result as the STOP-A will on a Sun.

Summary The administrator should understand the sequence of events that occur when a system is booted. The administrator should understand the methods used to modify the boot sequence. The administrator should know how to use the PROM monitor to select alternate boot devices. The administrator should understand the workings of the boot manager and boot loader. The administrator should understand how to shut a system down properly.

Operating System Installation
Chapter 5

Chapter Objectives Explore the hardware and software prerequisites for OS installation. Explore steps that must be taken before installing or upgrading an OS. Explore methods of producing robust reproducible OS installations. Explore installation types and techniques. In this chapter you will explore the process of OS installation, including seemingly minor details that present challenges and make life interesting. S. This chapter is not intended as the tell-all/end-all reference for installing an OS! Every OS release changes something. Usually a new release of an OS requires more disk space than the previous release. Sometimes a new release will come with a new installation tool. Always read your OS vendor’s documents before attempting to install the system.The following material covers the most problematic issues involved in a typical installation.

Installing an Operating System
Hardware Requirements Before you attempt to install an OS on a machine, it would be wise to ensure that the OS in question runs on the hardware that you have available. Multi-platform OS Support Most OS vendors that distribute software that runs on multiple hardware architectures publish a hardware compatibility list (HCL) for their OS. Single Platform OS Support Vendors of single-architecture OS deal with many of the same problems faced by multi-platform vendors.

OS for Intel-based Systems Windows is probably the most widely used OS available for Intel-based systems. Windows includes drivers for a wide range of devices that work on Intel-based systems. Versions of Windows produced over the past decade will operate on systems ranging from a 486 chip up to the latest Pentium. The current versions of Windows generally require a Pentium 166 (or better) processor chip, a minimum of 32 megabytes of memory, and 2 gigabytes (or more) of free disk space. Windows may not operate smoothly on some of the older systems, but it will operate.

OS for Intel-based Systems Recent releases of Linux are beginning to nip at the heels of Windows in regard to device driver availability, and the number of systems running the OS. The open-source movement has the advantage of allowing anyone to submit a device driver for their favorite device. Because there are so many PC systems available, many people know how to write “bad” software for the PC architecture. This plethora of untested/unsupported software available for the system can lead to security and reliability problems. Both Linux, and Windows suffer because of this situation!

OS for Intel-based Systems Well behind Windows and Linux, BSD, and Solaris are also available for Intel architecture systems. Solaris suffers from a lack of device drivers for the latest/greatest devices. Solaris also often does not offer device drivers for very old devices. Sun discontinued support for the Solaris Intel edition with the release of Solaris 9. They now offer a Linux “solution” in place of Solaris for Intel. BSD variants are generally more secure than the competitors, and offer very robust/well tested code, but they have not caught on as general purpose offerings. BSD is often found in research labs, and under the hood of network “appliances” such as firewalls.

OS for Non Intel-based Systems Proprietary hardware architectures may not allow you to run more than one OS. The “single offering” case greatly simplifies the decision regarding which OS you should load on the machine! The single OS is also easier for the vendor to support, as the service personnel only have one system to learn. Single-OS systems are also likely to be replaced by multi-OS systems over time. The world of computing is not a “one-size-fits-all” environment! The UNIX vs. Windows war will be battled for many years.

OS for Non Intel-based Systems Whereas some architectures may only work with one OS, others are blessed with multiple fully supported OS. Some vendors may provide full support for their proprietary OS but partial support for a second OS. More often than not, the second OS is one of the Linux distributions. Vendors such as Hewlett-Packard, IBM, Compaq and others now offer multiple OS for their hardware. Other vendors (like Sun) offer a line of Intel based Linux systems, as well as the SPARC based systems.

OS for Non Intel-based Systems Other hardware vendors only support their proprietary OS on their hardware. This is true for Sun Microsystems, even though there are Linux distributions that support the SPARC architecture. Although Linux is available for SPARC systems, many software vendors do not port their applications for the Linux/SPARC market. Without applications available for Linux/SPARC, customers stay with the proprietary Solaris OS on Sparc.

Cataloging Hardware Requirements
When you consider the OS hardware requirements, you need to pay close attention to any nonstandard hardware on your system. All hardware found on the system should be cataloged. Need to determine if device drivers are available. Need to determine if the hardware is mission critical. Looking over the inventory form before attempting to install the latest OS version may make the decision for you.

Cataloging Hardware Requirements
PC systems typically force a few more restraints on the system hardware than other architectures. For example, an Intel system requires a VGA display and keyboard in order to boot. Unfortunately, there are hundreds of display adapters, thousands of keyboards, and tens of thousands of mice available for PCs of different heritage. OS designers also impose restraints on the system hardware. Software kernel architectures may impose specific revision-level requirements on the hardware. For example, Solaris 8 will not boot on the sun4c hardware architecture.

Installation Time Requirements
When it comes to a discussion of installing an OS, the answer to “what hardware do I need?” is almost as nebulous as the answer to “how long will it take?” When everything goes right, a full OS install might take an hour. But when things go wrong, you might be looking at eight or more hours to get the OS installed and working. How do you estimate the amount of time required for an OS installation?

Installation Time Requirements
Never assume the OS installation will go smoothly. Even if you get extremely lucky, and everything does go well, figure on at least two hours just to get a bootable OS on the system media. Do not forget that after the OS is installed you will need to install patches and service packs to bring the OS up to date. Once the OS is installed and patched, do not forget that you have to install all of the applications users need in order to get their work done. Allow time for the appropriate number of reboots during the OS and application installation phases. The “load” media for an install can also have a huge impact on the installation.

Types of Installations
There are several types of installation models available to work with. The installation could be a server or a workstation. The goal of the installation could be to set up a machine usable as a desktop workstation, web server, database server, service machine, or interactive system. The system could be a diskless host that boots from the network, or a diskful system that serves files to other hosts. Each of these configurations may require that a particular set of software be installed such that the system performs its duties and users can get some work done.

Windows Installations The concept of a problem-free Windows installation may sound foreign to some administrators. This is never more apparent than on a dual-boot system. However, even the simple task of installing a single version of Windows on a system may hold a few surprises for the administrator. Hardware Support Issues It is not unusual to find that the version of Windows you want to install does not support the latest hardware available on your system.

Surprises Encountered While Installing Windows Windows can have a strange propensity for nondeterministic behavior. You can install it on three identical systems and end up with three completely different problems. It is also possible to follow the same installation procedure and end up with three systems configured differently once the installation is complete. For uniform installations, use the Windows network installation utilities, or tools like ghost” or “PC-rdist” to “push” an image to the new system from a pre-configured repository.

Some of the more common problems encountered while installing Windows include: One or more network interfaces may not operate correctly. Generally, removing the adapter’s driver, rebooting the system, and reinstalling the driver will correct this problem. NT 4.0 cannot be installed on systems with a boot partition larger than 4 gigabytes. This limit requires you to partition system disks larger than 4 gigabytes into (at least) two partitions. The device drivers on the Windows distribution media are often less than optimal. Display and network drivers seem to be the “big losers” in this respect. Service packs have been issued for all current versions of Windows. It is imperative that the sysadmin install these service packs to secure the system against well-known attacks.

Dual-boot Windows Installations The idea behind a dual-boot system is to install two different OS on the bootable medium. This allows the user to run either system, which hopefully allows the user more flexibility in performing tasks. Unfortunately, creating a dual-boot system is a lot more difficult than it should be, and many times Windows seems to be in the middle of the problems. One rule of thumb for installing a dual-boot system that includes Windows is to install the Windows OS first. If you are trying to install two versions of Windows, always install the older version first. This is often necessary because new versions of Windows often contain changes to the file system, and the old versions do not understand these changes.

Other Installations Installing a Solaris/Linux dual-boot Intel system often presents problems for the administrator. The Solaris Intel installer limits the number of partitions allowed on a disk where Solaris will be installed. If the disk has more than three partitions, and/or the installation of Solaris would cause the disk to have more than three partitions, the installation will fail. Linux wants a boot partition, and a kernel partition (minimum). Solaris also wants a boot partition and a kernel partition. If you wanted to build a dual-boot Linux/Solaris system, you would need four partitions. However, Solaris will only allow you to install on a disk with three (or fewer) partitions. In this case, install Solaris first, and then install Linux on a separate partition later. Better yet, buy a second disk, and install one OS on each disk!

Desktop Installations Installing the OS on a desktop PC is often a very different problem than installing an OS on a corporate database server. Generally, desktop computers come in two flavors: systems that contain their own copies of everything and systems that rely on network-based servers for critical applications. Standalone Systems Self-contained systems are often referred to as standalone systems, or “thick clients.” These machines typically contain the OS, and local copies of all applications required by users of the system. The installation of a standalone system will require more time than some other systems, because you have to load the OS, and all of the applications on the local disk. Such installations can easily become multi-day tasks!

Desktop Installations Networked Client Systems Systems that rely on network-based servers for critical applications/services are typically referred to as networked client systems, or “thin clients.” These machines usually contain a copy of the OS, but very little other software gets installed on these systems. User files typically reside on a network-based file server. Applications may reside on yet another network-based server. These systems rely on the network to be operational for the system to be useful. Such systems are typically very easy installations. You load the OS, configure the network connection, and possibly configure a few other parameters to allow the system to locate the network-based servers and you are “done”.

Server Installations Installing an OS on a server is often a long, arduous task. You have to install the OS and configure it to provide services to other computers. The types of “clients” the server supports will usually complicate this configuration task. The applications/services provided by the server may provide more complications. Homogenous Servers The homogenous server is probably the simplest server to install. This type of server only provides services to clients of the same architecture/kernel architecture. This means that only one version of the OS and all applications need be installed on the system. Such systems may be used as a boot server, file server, name server, web server, database server, or many other purposes.

Heterogeneous Servers Heterogeneous servers are probably the most difficult system you will ever have to install. These systems may provide boot services, applications, and/or file services for a variety of systems of different kernel/hardware architectures. For example, a Linux system may be set up to provide file service to Linux, Solaris, and MacOS boxes via NFS, while providing file service to desktop PCs via Common Internet File Services (CIFS) by running the Samba application. Such servers are typically very complicated beasts to install and configure. You will have to install copies of multiple OS for the system to function as a boot server. Similarly, you will have to install application binaries for multiple architectures in order to support application services for client machines.

Planning for an Installation The “footprint” or size of the OS should be considered to ensure that the system contains enough disk space. How that disk space is parceled might play a role in the OS installation. Similarly the size of the main memory might need to be taken into consideration. Disk Space Requirements One of the most important decisions you will need to make before you install an OS is how much space to allocate to the system software. If you allocate too much space to the system software, users may not have enough space. If you allocate too much space to users, the system may run out of space. Calculate how much space the OS and application binaries will occupy. Once you have a number in mind, double it. In a few weeks or months you will be glad you did.

Every successive release of an OS is larger than its predecessor. This is an important point to remember, because you may have to upgrade the OS on a machine two or three times over the lifetime of the hardware.

Installation Methods Current OS are typically distributed on CD or DVD media. Older releases were distributed on tape cartridges or floppy diskettes. More often than not, the distribution media is bootable, and therefore all you have to do is place the media in the appropriate device and turn on the power. The magic of the boot process boots the installation media, and an installation program guides you through the installation process.

Installation Methods Windows Installations Most Windows installations give the administrator very few options. When installing from the distribution media, the administrator selects the partition to install the bits on, answers a few questions about the local environment. The system does the rest without input from the operator. Unfortunately, the information required during the installation is not all collected up front; the information-gathering process is spread across the entire installation process. This makes Windows installation more time consuming than it should be, as the administrator has to sit and wait for the system to ask questions. If the questions were all asked up-front, the administrator would be free to attend to other tasks while the bits moved from the CD to the hard drive.

Installation Methods Windows CD/DVD Installations Installation of Windows from CD/DVD media is pretty simple. You boot the installation media, answer a few simple questions, and the installer program does the rest for you. Unfortunately, because the process is simple, it is not very configurable. The media-based installer is geared to the novice administrator’s capabilities; hence, the number of decision points and allowable options is very minimal. One downside to the CD/DVD installation is that the installation process is just interactive enough that the operator cannot start the installation and leave for an hour or two. The Windows installer has a habit of wanting companionship, asking another question every 15 minutes or so just to make sure the person performing the installation stays nearby, and awake. This may be acceptable for a one- or two-host installation, but it becomes extremely inefficient if you have to install the OS on 100 computers. If you find that you need to perform many “cookie-cutter” installations, look into the network install-server options available with most of the high-end Windows operating systems. An example network install script is discussed in the “network installations” section (below). All versions of Windows provide a GUI-based installation tool. The first portion of the interaction between the user and the installation tool is primarily an information-gathering phase. The user is asked for information regarding the type of install, the disk partitioning, type of file system to install, and the system hardware. Once these questions are answered, the system formats the specified partition, and installs a minimal system on the hard disk. When that partition is booted, the system resumes the installation process. The next phase of the installation is an automated process in which the installer loads the required OS binaries onto the system disk. Once the first round of binaries are installed, the system reboots, and the installation continues, with the system running from the system hard disk. At this point, a minimal OS has been installed. However, this OS needs to be customized to fit into the local environment. The next phase of the installation prompts the administrator for local configuration information such as time zone, host name, network address information, domain membership, and so on. As the administrator answers questions, the installer configures services, and moves on to the next set of questions. Once all binaries are installed and configuration is complete, the system is ready for patches.

Installation Methods Network Installations
If you want to customize the installation process, and/or make it completely automatic, you need to build a network-based installation server. Such an installation is referred to as an “unattended” installation in Windows parlance. The installation server contains on-line copies of the distribution media, a set of “answer” files that control what parts of the software get installed on the system, and a “boot daemon” that listens for installation requests on the network. You can customize the answer files to install the OS and any required applications without operator intervention. This is a much more suitable installation method if you have to install 100 computers instead of 2 or 3. This method comes with a price: someone has to build (and hopefully test) the answer files. It is possible to build answer files that will install thin clients, thick clients, and some types of servers. Once the answer files are built, they must be tested to ensure they do the right thing. To test answer files, you often build a bootable diskette for the specific installation at hand. You boot the installer diskette on the system to be installed, and the installation is completely controlled by the answer files on the server. The configuration/testing portion of the network load process can be very tedious, but if you have many systems to install the time spent developing and testing these rules will pay off in the long run, as subsequent installations are very simple, and can often be handled by inexperienced personnel. The answer files are text files that contain answers to the questions asked by the installation program. A sample answer file is included on the Windows distribution media under the name \i386\Unattend.txt. The Windows distribution media also contains a program named Setup Manager (in the file Support\Tools\Deploy.cab), which can be used to create custom answer files. Once the answer file has been created, you need to create the distribution folder that contains a copy of the CD distribution media. To populate the distribution folder, copy the content of the distribution media into the folder you just created. Refer to the information regarding unattended installations for more information, and a “checklist” procedure for this type of installation.

Installation Methods ; Microsoft Windows 2000 Professional, Server, Advanced Server and Datacenter ; (c) Microsoft Corporation. All rights reserved. ;; Sample Unattended Setup Answer File ; This file contains information about how to automate the installation ; or upgrade of Windows 2000 Professional and Windows 2000 Server so the ; Setup program runs without requiring user input. [Unattended] Unattendmode = FullUnattended OemPreinstall = NO TargetPath = WINNT Filesystem = LeaveAlone [UserData] FullName = "Your Name Here" OrgName = "Your Organization Name" ComputerName = "COMPUTER_NAME"

Installation Methods [GuiUnattended] ; Sets the Timezone to the Pacific Northwest ; Sets the Admin Password to NULL ; Turn AutoLogon ON and login once TimeZone = "004" AdminPassword = * AutoLogon = Yes AutoLogonCount = 1 ;For Server installs [LicenseFilePrintData] AutoMode = "PerServer" AutoUsers = "5" [GuiRunOnce] ; List the programs that you want to launch when the machine is logged into for the first time

Installation Methods [Display] BitsPerPel = 8 XResolution = 800 YResolution = 600 VRefresh = 70 [Networking] ; When set to YES, setup will install default networking components. ; The components to be set up are TCP/IP, File and Print Sharing, and ; the Client for Microsoft Networks. InstallDefaultComponents = YES [Identification] JoinWorkgroup = Workgroup

Installation Methods UNIX Installations
Many flavors of UNIX allow (in fact, insist on) significant operator interaction during the installation process. UNIX installers are often much more willing to allow custom installations than their Windows counterparts. This generally infers that the operator needs to be more knowledgeable about the specifics of the system to successfully complete the installation process. It also means that unattended installations are not feasible without plenty of advance configuration and planning.

Installation Methods CD/DVD Installations
As with Windows distribution media based installations, the installers used by UNIX OS are somewhat automated. A difference between UNIX and Windows installers is that MOST UNIX installers ask all of the questions up-front, then use the answers to drive the remainder of the install. A typical Solaris 8 installation requires about 20 minutes of operator interaction, then for the next hour (or more) no interaction is required. RedHat Linux installations are similar to Solaris in regards to operator interaction. While MOST UNIX installations often take care of the interactive portion up-front, a few of the installers “hold the user’s hand” throughout the installation process (much like Windows). Most provide context-sensitive help, on demand, throughout the process. One notable exception to this generalization appears to be the Debian Linux distribution. Many Linux users love their Debian systems, once they get through the installation. However, the pain of installing the OS is almost enough to send them running for the latest RedHat media instead of waiting for the final result!

Installation Methods Network Installations
Most versions of UNIX support a network-based installation system of one form or another. Like Windows, these installers require a network-based boot server, rules files that dictate how the installation is performed, and a boot daemon that runs on the server to manage the process. The Solaris JumpStart package is one such network-based installer. Sun’s WebStart and the Linux KickStart service are other examples of the automated network-based installer. Because there is no official standard for these network-based tools, and each vendor has one (or more) of these installers, describing all of the current offerings is difficult, if not impossible.

Installation Methods Linux Kickstart
Linux may be “kickstarted” from a bootable floppy diskette or from a network-based boot server. The floppy diskette must contain a configuration file named ks.cfg. This file is the Linux equivalent of the Windows “answer file” for an unattended installation. To perform a network installation, you need to have a DHCP server running on your network. The DHCP server instructs the new system how to contact the boot service machine identified in the ks.cfg file.

Installation Methods The Kickstart process requires a “rules” file to control the installation. The ks.cfg file contains several directives that tell the installer how, and what, to install on the system. The format of the ks.cfg file is as follows. <command section> <a list of %pre, %post, and/or %packages directives> <installclass> The easiest way to create a Kickstart file is to use the Kickstart configurator utility supplied on the distribution media. To start a Kickstart install, you use a special boot floppy. The boot floppy may contain a CD-ROM or network “boot block.” In either case, you start the boot with the following command. Boot: linux ks=floppy # ks.cfg resides on the floppy # ks.cfg resides on NFS fileserver Boot: linux ks=nfs:<server_name:>/path_to_ks.cfg

Installation Methods Solaris Network Boot Service Daemon
To provide a Solaris installation server, you must build and configure a system that will listen for install requests, and know how to deliver the proper files to the host being installed. This requires the sysadmin to complete the following two major tasks. Build a server, install the boot server software, and configuration files. Install the binaries to be served on the boot server. Under Solaris, the first task consists of creating several configuration files. Among these files are /etc/bootparams, /etc/ethers, and sysidcfg. The network boot process reads the configuration files, and then listens for an installation request from the network. The client that requires installation services sends a DHCP request packet, which asks for network information. Once the client has a valid network address, it asks if anyone knows how to boot it. The boot server replies by sending the client the installer image to be booted. The client loads and starts the installer, which handles the remainder of the install. Solaris provides a set of scripts that will assist you if you decide to create an installation server. The distribution CD contains a directory named Tools, which contains the setup_install-server, add_to_install_server, modify_install_server, and add_install_client scripts. These scripts are used, respectively, to create an install server, copy the installation media to the install server, add the WebStart interface to the server, and add client information to the server. The instructions for using these scripts are in the main pages, and in the Advanced Installation Guide distributed with the OS media. The distribution media also contains some sample configuration and rules files for your perusal.

Installation Methods Saving Critical Data In the event your installation involves the upgrade from an old version of an OS to a new version, there is another critical point to consider. What do you do with all of the old files on the system when you get ready to install the new software? If the system is a standalone desktop, and you have a new OS (as well as new applications to install), you may not need to worry about saving anything from the old system. More often than not, however, before an old OS is shut down for the last time there are several files you may wish to save. You are strongly advised to make a full backup of every file on the system.

Installation Methods Servers often present an even bigger challenge when you are upgrading an OS. For instance, because you may not have to change the partitioning to load a new OS, it would help to know how the disks on the system are currently partitioned. Printing out information regarding current disk partitions may be very helpful information during the upgrade. Saving the password file, NIS name, server maps, user files, and other critical information before you begin the installation procedure is always strongly recommended. Again, err on the side of caution, and perform a full file system backup before you begin the upgrade. Nine out of ten times you will be glad you spent the extra time to do so.

Summary Installing an OS is a huge undertaking.
There are no set formulas for how it should be done. Early steps in the planning should include checking that the new software will run on the hardware. Determination of the type of installation, homogenous server, heterogeneous server, standalone system, thick client, or thin client should also be addressed before beginning the installation process. System types to be supported and the intended use of the system must also be factored into installation planning. Application availability should be checked, and rechecked. If mission-critical applications are not available for the OS to be installed, you may have to change your plans.

Summary Because the administrator’s approach to OS installation is critical to the success of the system, allocating some time for experimentation can be extremely useful. Plan an installation and then implement the system based on initial planning sessions. As the first installation is performed, keep copious notes on the process, and any surprises encountered. Once the system is up and running, inspect everything to make sure no critical information was forgotten. When you think the test installation is a success, wipe out the installation and go through the process a second time. When it comes to installing an OS, practice makes perfect.

Managing System Software
Chapter 6

Chapter Objectives Explore hardware and software requirements for application installation. Explore types of software installations. Explore software installation and maintenance tools. Explore disk layout, and pros/cons of partitioning. Explore steps required before an installation is attempted.

Managing System Software
Operating systems, utilities and applications are continually being updated. User’s request new software package installations as their needs change or new packages become available. Vendors constantly offer new versions of operating systems, utilities and applications. Bugs are found and patches to correct them need to be applied. No matter the source or the reason, the system administrator will be called upon to manage the system's software on a routine basis. Software maintenance is the task of obtaining, installing and keeping track of these updates.

Software Maintenance Concepts
Software maintenance is conceptually pretty straight-forward. As new features are added or bugs discovered, the provider of the operating system or applications bundles together the files needed to add the feature or correct the bug and makes them available. The bundle of files is then installed to add the feature or correct the problem and possibly some additional commands are run to adjust configuration information as needed by the newly installed files. Depending on the installation tools used, the bundle of files may also be checked for correct installation and authenticity as part of the installation process.

These bundles of files are given various names. Packages refer to a bundle of files that contain the programs, configuration files and installation commands for a single facility such as a print spooler. Updates often refer to bundles that add additional features. Patches, service packs and hot fixes often refer to bundles that correct a problem.

Some vendors group bundles together into larger groupings. For example, Sun calls the groupings of Solaris packages, clusters, while Red Hat names their groupings for the type of system (e.g. server, client, laptop, etc.). A configuration is the term often used to describe a particular suite of packages such as the suite of packages one might install on each of a group of similar systems or the complete suite required packages needed to set a system up as a web server or print server.

The difficulty in performing software maintenance comes in four areas. First, there is not much agreement on the format for bundling files. Second, various bundling formats require specialized installation, removal and management tools. These tools are different between vendors, and offer differing feature sets. Third, updates, often overwrite configuration files, reset values to defaults, add users, turn on services, or perform other actions that causing working software to fail, or security to be compromised. Finally, there is the chore of keeping track of which updates have been installed and which of the available updates need to be installed.

Software Packaging Formats
Bundles of software can be packaged in a wide variety of forms. It's not uncommon to use one format for the operating system software, another for an application program and third format for a tool or utility program. The self-extracting formats should be examined most carefully before using them. These formats have a history of being attacked via so-called Trojan Horse programs. A careful system administrator will verify the authenticity of any patch or package before he installs it.

Software Maintenance Tools
The wide variety of software packaging formats can be grouped together based on the features present in the tools used to manage them. There are three basic types of tools, simple archivers specialized multiple command package management suites all in one tools Additionally, many of these tools include additional graphical interfaces making them easier to learn and use. Individual package management tools are not hard to learn, it is the variety of differing feature sets and tools across operating systems that makes this task tougher then it ought to be.

Simple Archivers The simplest of the software package management tools are the simple archivers such as tar, zip and cpio. These common archiving tools are found on both UNIX and Windows and are used to create and install files from their corresponding archive formats. Macintosh users will be familiar with Stuff-It tool for archiving files on that platform. While tar, zip, cpio and other archive tools have the advantages of being cross platform, commonly used and readily available, they lack a number of features commonly found in tools specifically designed for software package management.

Simple Archivers Drawbacks of simple archival tools
Tracking installed software is left up to the administrator. Simple archivers make no installation records. The system administrator must use some external means to record what has been installed via these tools. Any additional work required such as modifying configuration files or additional set up steps must be performed by hand. These tools provide no integrated way to verify the authorship of the archive. A simple archive does not contain the information needed to check for any dependencies the package may require. None of these tools provide a direct method for obtaining the archives over the Internet.

Software Package Management Tools
To address these deficiencies of simple archive tools for software package management, specialized installation tools were developed. Unlike the simple archivers whose packaging format is common across systems, these specialized tools use a wide variety of formats with limited cross platform availability. Worse still, the tools used to manage these packages are at least as varied as the packaging formats themselves. Finally, the features provided by these tools vary from tool to tool often leaving the system administrator to pick up the slack when a needed feature is missing.

A typical suite has commands to install or update packages, inquire about which packages are installed and remove packages. Dependency checking is an important feature for a package installation tool as many UNIX packages are modular, built on top of libraries found in other packages. Verification is the act of checking that the package is installed correctly and the files in the package match those installed. This can be used to check for possible tampering that may have occurred due to a break-in or to check that file modes or ownerships have not been changed my mistake.

Another aspect of assuring system security when installing packages is the determination of the authenticity of the package being installed. This is especially important when using packages and patches downloaded over the Internet. Listing the installed packages and removing packages are common features across all of the package installation tools.

Creating your own packages is one way a system administrator can deal with the installation and maintenance of locally developed software on a large number of systems. Advantages of home-grown installers: The created package can be distributed and installed using the same tools and procedures used for other packages. Any post installation configuration steps needed may be encapsulated in the package, assuring a consistent installation. Checking and verification of proper installation of a package can be used to verify that the locally developed software is installed correctly.

Graphical Software Package Management Tools
A typical software package management tools suite often tops off the command line tools with a graphical installation tool. In the case of Windows, graphical tools are the only way to install many software packages. These tools often offer the administrator fewer installation options, but handle the typical installations very well. While these graphical tools can make life easier when managing software on a single system, they suffer when put to use across many systems.

Graphical Software Package Management Tools
When dealing with large numbers of systems, command line tools that can be run from scripting languages offer the flexibility needed to get package installations accomplished in a timely fashion. Graphical installers (generally) offer few installation options, by tending to oversimplify the installer for use by a novice user. Installations that make use of shared disk space for applications and other special situations will often require the use of options not found in a graphical installation tool.

Dealing with missing features
It would be terrific if every software package management tool or tool suite had all the features needed. Unfortunately, nearly every installation tool suites lack one or more features. This can be worked around by combining the installation tools with other commonly available tools. The easiest (missing) feature to compensate for is Internet access. Most vendors provide access to software packages and patches via ftp, the web or both. Internet available packages and patches are often further packaged into one of the several common formats for download and will need to be unpacked from their distribution packaging before they can be installed.

Authenticity & Integrity
Verification that a software package is intact and was produced by the genuine author are two critical but lacking features of nearly every software package management suite. They are of special importance when using the Internet to obtain patches or other software. One method of checking integrity and authenticity is to use a public key cryptographic tool such as gpg. Another way to fill in for this missing feature is to perform checksum and MD5 cryptographic fingerprint checks on the files using the sum and md5sum commands. However, the vendor or other supplier of the patch or software package must publish a reference MD5 fingerprint or checksum value for comparison. Not all vendors do.

Catching Unintended Changes
Despite the best intentions of the software vendor, installing a new package or patch sometime results in unintended changes to the operating system configuration files. These changes are not always easy to spot, but there are several things that can be done to prevent problems caused by package or patch installations. 1. Make certain you have a good backup of the system to be patched. 2. Install the package using an account other than root whenever possible.

Catching Unintended Changes
3. Install the package or patch on a test system first. 4. List and inspect the contents of the patch or package to be installed. 5. Extract and examine the installation script(s) for setuid/setgid commands, or any chown, chmod, cp, rm, mv, or shell redirection commands to ensure that critical system files are not altered. 6. Use a file modification monitor such as tripwire.

Finishing Touches Installing a package is often times not the end of the job for the system administrator. A wide variety of software packages require some degree of local customization, configuration, licensing or user level setup to complete the installation process and present the user with the fully functioning tool they expect. Since every package will have its own customization and configuration needs, the system administrator will need to read up on the specifics of the packages in use at his site.

Finishing Touches Configure once, and distribute the configuration.
Even packages that are installed by a package installation tool often have configuration files that will need to be modified. These files can modified to suit local conditions and then distributed using a tool such as rdist. Wrap a short shell script around a package to set needed variables. Many packages require setting environment variables or adding elements to a shell’s execution path. Instead of having each user make the needed changes, one approach is to replace the program with a short shell script that sets the environment as required.

Finishing Touches For packages that contain several tools, all of which require special environmental variables or modifications to the user’s execution path consider adding the needed setup information to the skeleton files used to create the user’s accounts. Employ a specialized user environment configuration tool such as modules. The modules tool provides the means for the system administrator to package up the environment variables, PATH and other user environment changes into modulefiles that can be easily loaded by a user to configure their environment to suit a specific package. The modules tool performs complex tasks such as removing and reordering elements of the user’s execution PATH to allow even differing versions of the same package to be configured correctly.

Service Packs and other special situations
Some patches and software packages cannot be installed using the usual software management tools. Special updates often require more time and a planning than the usual package installation. Following the precautions listed in the previous section on unintended changes are a must for special updates. Additional caution is recommended.

Service Packs and other special situations
Keep the previous kernel version available and ready to use. On Linux this can easily be accomplished by adding an entry to /etc/lilo.conf or /etc/grub.conf. Other UNIX variants allow for a second kernel to be kept in the root or boot partition. Make an emergency boot disk. The procedure for this varies, but many operating systems allow you to make a floppy disk that the system can be booted from. Locate a bootable CD for the system being updated. Many operating systems allow you to boot from the installation CD and correct problems caused by updates.

Tracking and Distributing Packages and Patches
Installing packages and patches on a large collection of systems is a challenging task. The system administrator will need to maintain records of the packages and patches installed, check for missing packages and patches, and perform multiple installations. Record keeping and checking for correct package and patch installation is rarely integrated into a software package management tool or suite of tools. A simple, external method of monitoring packages and patches is the keep records in a table such as a spreadsheet.

Another approach is to make use of the software package management tool’s ability to list the installed packages. Lists of packages from each system in a group can be gathered and compared to a master list or a master system. This makes missing patches easy to spot. The lists from each system can be stored and referred to later to determine which patches or packages need to be installed on a given system.

Package and patch distribution can be accomplished in a similar manner. One method which works well is to place the package and patch files in a network-accessible directory which is available to all the systems to be patched. Then connect to each system in turn and execute the appropriate package installation commands. Automating the actual installation of packages and patches is an area where UNIX and command line package installation tools really shine. Command line tools are readily automated by a variety of methods and are easily run remotely over a network connection such ssh.

Summary Maintaining the software on a system involves the periodic installation of software packages and patches. While a straight-forward task in concept, the pitfalls are many. The wide variety of package formats, management tools and missing features in specific tool sets make the process of managing packages and patches more challenging then it ought to be. Before attempting a software installation, the administrator should: Explore hardware and software requirements for the application. Understand the types of software installations. Understand the software installation and maintenance tools. Understand the disk layout, and pros/cons of partitioning. Understand the steps required before the installation is attempted.

System Devices Chapter 7

Chapter Goals Understand internal system device interconnections.
Understand device configuration and access from the hardware perspective. Understand device configuration and access from the software perspective. Understand how to view the system’s copy of the device information. Understand device naming schemes used by various operating systems. Understand how to add a device to an operating system, and rebuild the kernel.

System Devices In order to manage the devices on the system, the sysadmin must have some concept of system architecture – the interconnection of devices on the system. A knowledge of how operating systems deal with devices is also good background information for the sysadmin. This chapter examines some of the terminology associated with system devices, and some generic information about device/operating system interaction.

Generic System Architecture
Internally, the system may contain multiple system busses. The memory and I/O busses may be combined, or there may be multiple busses dedicated to individual tasks. The sysadmin cannot do much with these busses, as they are generally etched on a circuit board. The I/O busses are the ones that we are interested in, as quite often, the sysadmin needs to install/troubleshoot/remove devices from these busses. Access to these busses is typically provided via connectors on the system motherboard. Sometimes these connectors are used to “spawn” another bus (such as the ISA bus, the PCI bus, the Sbus, …), and sometimes the connectors are end-device connection points (COM ports, Parallel ports, …).

Generic Architecture There are two basic types of buses that we will examine: Serial bus – a bus which contains a single pair of wires for unidirectional data transmission. COM ports, and network connections are typical examples of serial bus devices. Parallel bus – a bus which contains multiple wires for high-speed bi-directional data transfers. Disk drives, tape drives, and graphics cards are typical examples of parallel bus devices.

Device Terminology Parallel Bus Interfaces and Bus Standards
PCMCIA Bus – 16 bits wide, 4/8MHz, 4/8 megabyte/second EISA Bus – 16 bits wide, 8 MHz, 33 megabyte/second PCI Bus – 32/64 bit wide, 33/66 MHz, 264 megabyte/second Sbus – 32/64 bit wide, 25 MHz, 168 megabyte/second AGP Bus – 32 bit wide, 66 MHz, 2 gigabytes/second Parallel Ports – 8 bits wide Serial Bus Interfaces COM Ports – RS323, RS422, RS423, 100Kbit/second USB Bus – up to 15 megabytes/second Firewire – hundreds of megabytes/second

Windows Device Terminology
Windows defines devices in terms of an interrupt level (IRQ), a memory range, and a group of device registers (I/O range). All device interactions between Windows and a specific device are handled via a device driver. The device driver requires knowledge of the IRQ, memory range, and I/O range of the device. The kernel contains a table of all devices connected to the system. This table contains the appropriate values for these “variables” for each device.

Windows Device Terminology
Interrupt Request (IRQ) A signal line that is used to signify that a device requires service. Memory Range The memory space occupied by the device interface. I/O Range The memory space designated for the device registers. Plug-and-play A method to allow the system to auto-configure the board settings (IRQ, I/O range, Memory range). Each device interface has the ability to interrupt the processor. The kernel contains a table that maps interrupt levels to device driver routines. When a device asserts it’s IRQ line, the system reads the IRQ level from the bus, and consults the table to determine which service routine to invoke. NOTE: That multiple devices within the same device class may share an IRQ line. For example, multiple Ethernet interfaces may share the same IRQ. In this case, the driver must poll all Ethernet devices in order to determine which one asserted the interrupt. Allowing different types of devices to share an interrupt request level will probably lead to problems! The device interface typically includes some command/control/status registers. These registers are bus interfaces to the device. The device driver needs to read/write values from/to these registers to make the device perform the necessary I/O operation, and to check the status of the device. The device may contain it’s own memory. This memory is typically mapped to system address space such that processor may access the memory to read/write data from/to the device.

UNIX Device Terminology
UNIX “thinks” that everything in the universe is a file. UNIX devices are nothing more than special files. The special files have attributes that allow the kernel to load the correct device driver in order to service I/O requests.

Information displayed by the ls command for a typical text file includes: Size in blocks: Number of blocks this file occupies on the disk. Permissions: Read, write, and execute bits for the owner, group, and world. Link count: Number of hard and soft links to this file. Owner: Owner of this file. Group: Group owner of this file. Size: Size of this file in bytes. Modify date: Modify date for the file. File name: Name of this file.

Information displayed by the ls command for a device special file includes: Size in blocks: Number of disk blocks this file occupies. Access mode: Single character that determines the access mode of the device. Permissions: Read/write/execute bits for the owner of the file, the group owner of the file, and the rest of the world. Reference count: Count of hard and soft links to this file. Owner: User ID of the user that “owns” this device. Group: Group ID of the group that owns this device. Major: This field identifies the “class” of device with which you are dealing. The number in this field is used as an index to a table of device types. Minor: This field is used as a secondary index to a table of devices within a specific device class. Modify date: Date the device was last written. File name: “Name” of the device. if you have used “block mode” operations to transfer a “block” of data per reference (b), or character mode operations to transfer a single character of data at a time (c). Block mode operations typically involve direct memory access (DMA) operations.

Problems with the UNIX view
Whereas UNIX likes to view everything as a file, some device operations defy the designer’s ability to connect file operations to device operations. It is pretty easy to envision read, write, seek, and rewind in terms of file operations. But how can you describe an operation such as setting the speed of a serial port in terms of file operations? Similarly, how could the operation of ejecting a tape, floppy diskette, or CD-ROM be described in terms of a file operation? These operations defy all attempts to describe them in terms of a file operation; therefore, another mechanism was introduced to enable these actions.

IOCTLs Input/output control functions (IOCTL) are the mechanisms that allow UNIX to implement the odd operations that cannot be described in the scope of file operations. The ioctl routines are small programs or functions specifically crafted to achieve a single operation. UNIX defines several ioctls as standard, and specific variants of UNIX define several other “proprietary” ioctls. Stty, eject, offline

Generic Device I/O When a device asserts an interrupt:
The system reads the IRQ lines to determine what type of device handler (driver) to invoke. The device driver scans the I/O registers of all devices of that type to determine which unit has the interrupt bit set. The device driver uses other information in the device registers to perform an I/O operation (read/write/…). When the I/O operation completes, the device driver return control to the kernel.

Generic Device I/O When a system requires I/O:
The system invokes the device driver and passes it a structure that defines the requested operation. The device driver uses the information in the kernel tables to contact the appropriate device. The device driver sets/clears bits in the device registers to cause the device to perform an I/O operation (read/write/…). Unless this is a blocking operation, the device driver returns control to the kernel, and the operation is performed (somewhat) asynchronously.

System Configurations
Because the kernel contains tables that map the devices to specific drivers, it should be possible for us to view this information. If we want to troubleshoot a device we want to see that it is “where we thought it should be” We can use this information to build an inventory of what is on the system. This makes adding a new device a little bit easier. The system input/output devices are attached to a set of interconnected buses. On many systems, the PROM monitor recognizes these interconnected buses and respective devices as a tree of nodes. At the root of the tree is a node that describes the entire system. The leaf (child) nodes are typically indented (with respect to their parent node) to show the hierarchical relationship between nodes. Nodes on the device information tree that have children generally represent system buses and the associated controllers on the buses. Each parent node is allocated a physical address space, and a major device number that distinguishes the devices on this node from one another. Each child of a parent node is allocated a minor device number, and a physical address within the parent node’s address space. The physical address of nodes is generally assigned in relation to the device’s physical characteristics, or the bus slot in which the controller is installed. This is done in an attempt to keep device addresses from changing as systems are upgraded and new devices are installed on the system. Each device node on the device information tree can have the following attributes. · Properties or data structures that describe the node and associated devices. · Methods or software procedures used to access the devices. · Children (devices or other nodes) that are attached to the node and lie directly below it in the tree. · A parent, or the node that lies directly above the current node in the device tree.

Windows Device Tree Under Windows, the device information tree is available under the operating system’s system control panel. The system control panel contains a link to the device manager. As shown the device manager provides a graphical representation of the available system devices. The display can be set to illustrate the devices by type, devices by connection, resources by type, and resources by connection. This allows the operator to view device interconnections and device resource utilization in several formats.

Windows Device Tree

UNIX Device Tree As mentioned in the chapter on booting, many systems use code in the PROM monitor to build a device information tree. This device tree shows the interconnection of system components, and contains address/memory/IO information for each device.

Solaris Device Tree Under System V, the physical device interface to the nodes on the device information tree lies in the /devices directory (Solaris) or the /hw directory (IRIX). This directory contains subdirectories that store device-special files for audio devices, floppy disk drives, the eeprom, pseudo devices, bus adapters, serial port devices, and other system devices. Within each subdirectory of the devices directory there are more entries, which may be special-device files or directories containing special-device files. The directory hierarchy simplifies the task of locating a specific device by grouping device entries for that type of device in a single directory. TIP: A simple method of identifying the address of any device on the system is to use the command ls –lsaR /devices/* The output of this command will list the device-special files for all devices on the system.

Solaris Device Tree

Solaris Device Tree The Solaris prtconf utility allows the administrator to print the system configuration to a terminal or line printer. This utility provides a list of devices and drivers loaded in the system. Indenting child node information with respect to parent nodes in the prtconf output preserves the device information tree data. When used with the -p flag, prtconf will display the OpenBoot prom information about the devices. The -v flag tells prtconf to display the output in verbose format.

Solaris Device Tree

Solaris Device Tree The Solaris sysdef utility also allows the administrator to examine system configuration information. The sysdef utility provides a list of devices defined on the system and loadable driver modules, as well as the state of many tunable kernel variables. Indenting child node information with respect to parent nodes in the sysdef output preserves the device information tree information.

Solaris Device Tree

UNIX Device Tree Unfortunately, the utilities to display the device tree vary by operating system. All operating systems have a way to view the information, but this requires that the sysadmin needs to be familiar with multiple commands to perform one operation. Some third party tools work with multiple versions of UNIX operating systems The sysinfo command is one such utility.

UNIX Device Tree

UNIX Device Tree Linux (and to some extent Solaris) make use of the /proc file system to manage some portions of the device information tree. The Linux developers have put a lot of thought and time into the /proc file system and the capabilities provided by this structure. Under the /proc file system is one of the interfaces to the system devices. The device information tree can be seen by using the ls command to view the /proc file system.

Device Names Under Windows, devices have fairly simple names:
COM ports – communication ports LPT – the line printer port. Disk Tape SCSI Sound Display In order to determine the names of the devices on the system, simply use the device manager to display the device list.

Device Names Unfortunately, under UNIX, device names can be very difficult to figure out. Most devices on a UNIX system are named with an acronym derived from the device type. For instance, on many UNIX variants, an SCSI disk drive is an sd device. On other UNIX variants, a disk may be known as a dsk device, an hd device, and in one case, a dad device. An SCSI tape drive may be an st device on one system, but this same tape drive could be an rmt device, or a ct device, on another system.

System V Device Names System V provides an easy-to-use, easy-to-remember method of accessing devices that does not require the memorization of several eight-digit hexadecimal addresses. System V allows multiple names for each device on the system. The operating system’s link to the physical device is through a file in the /hw or /devices directory. However, many System V operating systems also include aliases for these /hw and /devices entries. Under Solaris, such alias entries reside in the /dev directory, and are symbolically linked to the entries in the /devices directory. NOTE: Under Solaris, disk drives are the only devices that use alphabet soup designators. Other System V Release IV operating systems may use similar designators for tape drives and other system devices. Under HP/UX and IRIX, the /hw directory contains the device-special files. There are links from /dev/dsk to entries in /hw/disk. Under IRIX the disk name contains three portions. For example, /dev/dsk/dks0d1s0 is the IRIX disk drive unit 1, partition 0. The first s0 is the SCSI bus instance, the d1 is the disk unit number, and the second s0 is the disk partition of the specific disk. Many of the IRIX device names are more BSD-ish than they are System V-ish. The subdirectories within /hw are named for the type of device. Here, input, cpu, disk, scsi, net, and ttys are a few of the device directories available under IRIX.

System V Device Names The Solaris /dev/dsk directory contains entries with names such as /dev/dsk/c0t3d0s0. This form of device name is often referred to as the “alphabet soup” designator for the device. These logical names for devices are much easier for most users to remember than names such as A Solaris alphabet soup name for a device consists of four fields: Controller (CN), Target (TN), Device (DN), and Slice (SN). CN represents controller number N. This refers to the logical controller number of the device interface. A system with a single SCSI interface would have devices connected to controller c0. A system with two SCSI interfaces may have SCSI devices connected to both the c0 and the c1 SCSI interfaces. TN represents the target number. This is the SCSI target ID (or SCSI address) of a device connected to the controller. DN represents the unit number of the device connected to target controller TN, which is in turn connected to bus controller CN. Some peripherals allow the connection of several devices to a single target controller on the SCSI bus. The device-naming scheme uses the DN field of the device name to refer to these child devices. A typical ESDI disk controller may connect to the SCSI bus as target 2. The ESDI controller may in turn allow the connection of two disk drives. These disk drives may be referred to as /dev/dsk/c0t2d0s2 and /dev/dsk/c0t2d1s2. SN represents the slice or partition number of the device. See Chapter 9 for more information on disk slices and partitions. System V allows multiple names for each device on the system. As discussed in the section on device-special files, the operating system’s link to the physical device is through a file in the /hw or /devices directory. However, many System V operating systems also include aliases for these /hw and /devices entries. Under Solaris, such alias entries reside in the /dev directory, and are symbolically linked to the entries in the /devices directory. For example, the Solaris /dev/dsk directory contains entries with names such as /dev/dsk/c0t3d0s0. This form of device name is often referred to as the “alphabet soup” designator for the device. These logical names for devices are much easier for most users to remember than names such as A Solaris alphabet soup name for a device consists of four fields: Controller (CN), Target (TN), Device (DN), and Slice (SN). The following are descriptions of these fields. Under HP/UX and IRIX, the /hw directory contains the device-special files. There are links from /dev/dsk to entries in /hw/disk. Under IRIX the disk name contains three portions. For example, /dev/dsk/dks0d1s0 is the IRIX disk drive unit 1, partition 0. The first s0 is the SCSI bus instance, the d1 is the disk unit number, and the second s0 is the disk partition of the specific disk. Many of the IRIX device names are more BSD-ish than they are System V-ish. The subdirectories within /hw are named for the type of device. Here, input, cpu, disk, scsi, net, and ttys are a few of the device directories available under IRIX.

BSD Device Names The device-naming scheme used by early BSD UNIX variants is quite different from the System V naming. Most of the device acronyms are derived from the type of device, and/or the manufacturer of the device. For example, an SCSI disk device might be called sd#P, where sd is an “scsi disk,” # refers to the SCSI target address, and P refers to a file system partition on that drive. For example, /dev/sd3a on a SunOS system refers to the “a” partition of the disk connected to the on-board SCSI controller at address 3. Recent versions of the BSD software (FreeBSD, BSDI, NetBSD) have stayed with this simple device-naming scheme.

BSD Device Names BSD UNIX uses pretty simple acronyms to name some of the devices: sd is an scsi disk, st is an SCSI tape, tty is a tty device (serial port), kb is a keyboard, eth (or ec) is an Ethernet controller, and so on. Although these names may be easy to derive, there are problems with this scheme. Consider, for example, a system with an SCSI controller, a system console device, and a scanner device. Which device is /dev/sc0?

BSD Device Names Although parts of Linux are System V-ish, the device names are more BSD-ish. Under Linux, an IDE disk drive is /dev/hda (hard disk A), whereas an SCSI disk is /dev/sda (scsi disk A). Other system device acronyms under Linux may also vary from the scheme used by most BSD operating systems. NOTE: Substitute appropriate unit numbers for the # symbols in the table. Here, W = controller, X = SCSI ID, Y = device ID, and Z = Partition.slice. For Linux: L = Unit “letter” and P = partition letter or number.

PROM Device Access Some hardware architectures allow considerable access to the device tree from the PROM monitor. Intel architectures are generally limited due to BIOS limitations. SPARC, PA/RISC, and PowerPC architectures offer very good availability.

PROM Device Access The SPARC OpenBoot monitor refers to devices by their points of connection to the system. The operating system refers to devices by mnemonic names and device-special files. Most of the device names that system administrators deal with are actually aliases that point to some physical device on the system.

PROM Device Access For example, the root file system may reside on a disk referred to as either /dev/dsk/c0t3d0s0 or sd3a by the administrator. This same disk is known to the OpenBoot monitor as disk3, To list the hardware on a Solaris box, use the PROM monitor’s show-devs command

PROM Device Access The show-devs command will return output formatted as follows: name: A name is a text string that generally has a mnemonic value. For example, sd represents an SCSI disk. Many controller names use some portion of the manufacturer’s name or model number. @: The “at” symbol must precede the address parameter. address: The address is a hexadecimal numeral string representing the physical address of the device on the system. The address is usually in the following form: hex_number,hex_number. “:”: A colon must precede the arguments parameter. arguments: The arguments constitute a text string whose format depends on the device. The arguments may be used to pass additional information to the device’s driver software.

Hardware Device Access
Examining the physical address of a device allows the system administrator to determine the point of connection for that device. To determine the point of connection for the disk3 device, simply break down the physical address into the following components. - Device is connected to a PCI adapter. 1f, An address on the on-board bus. - A pci interface is the on-board pci adapter. 1, A pci slot number and an address offset within that slot. This means that the pci device is in pci slot 1 with a hexadecimal address offset of 1 from the parent node (main system bus) address. - An IDE adapter connected to the PCI. The IDE adapter’s address offset from the pci bus adapter. - Device in question is an IDE disk. 0,0:g - Denotes IDE target 0, logical unit number 0, partition g of the disk.

Reconfiguring Device Information
Sometimes when a new peripheral is installed in a system it becomes necessary to reconfigure other peripherals. For instance, it may be necessary to move an adapter card from one slot to another slot in the system to allow the installation of a new adapter card. Because the device information tree contains information concerning the slot number of each device on the system buses, the device information tree must be rebuilt whenever devices are moved or new devices are installed on the system. Generally, you want to minimize changing device names, as you may have to manually edit system files to reflect these changes.

Adding Windows Devices
Under Windows, the plug-n-play software generally handles installation of new devices. The plug-n-play code finds a new device on the system bus, and probes the device to determine what it is. If the device supports plug-n-play, it tells the system what type of device, and what driver it wants. The OS loads the driver from the generic pool of drivers, or asks you for media to load from.

Adding Linux Devices The generic “menu” for adding a new device to a Linux system includes the following. Obtain source code for your kernel and place it in /usr/src/linux. Build new kernel: Use the Linux kernel configuration tools to configure a new kernel, and then compile the new kernel. Install new kernel: Copy the recently compiled kernel to the /boot directory and inform the boot manager of its presence. Reboot new kernel: Shut the system down and hopefully boot the new kernel. NOTE: If your kernel uses loadable kernel modules, you may be able to add a device drivers on the fly. The generic steps required to build a new linux kernel: Change directory to the Linux source directory (/usr/src/linux). Invoke the command make xconfig. This will bring up an X11-based window that walks you through the configuration process. If you are not running X11 you can use make menuconfig to open a text-window-based configuration tool. It is important to know what hardware constitutes your system, and what hardware you are adding. You need this information so that you build a kernel that supports the right devices. Once you have selected all of the drivers to be included in the kernel, you exit the xconfig application and type the following commands: make dep make bzImage make modules make modules-install This set of steps will check for all of the build dependencies (include files, and libraries), build the kernel, build the loadable modules, and install the modules in the /lib/modules directory. Once these steps are completed, the kernel needs to be copied into the boot partition using the following. cp /usr/src/linux/arch/i386/boot/bzImage /boot/vmlinuz-“version” Then you edit the lilo.conf file and add the relevant information such that you can boot this new kernel. See Chapter 5 for more information on the lilo.conf file. Once the lilo.conf file has been updated, run the command /sbin/lilo to cause lilo to update the system tables. When this completes, you need to shut the system down and boot the new kernel. The new kernel may be tuned by making changes to the content of the files in /proc. For example, you can change the number of open files per process by changing the value in the file /proc/sys/fs/file-max. Kernel tuning is explored in Chapter 24.

Adding BSD Devices Creating the “menu” for adding a new device to a BSD system is similar to the procedure for adding a device to a Linux system. Obtain source code for your kernel and place it in /usr/src/sys. Build the new kernel; that is, create a new configuration file. This is the difficult part. The config file is a series of directives that tell the config program what you want it to do.

Adding BSD Devices Each line begins with a keyword
machine - Define the machine type i386 cpu cpu - Define the CPU type i686_cpu ident ident - Define the name of the kernel my_kernel maxusers maxusers - Define the kernel table sizes maxusers=16 options options - Define compile-time options options symbol=value config config - Define the root and swap partitions config my_kernel root on wd0 controller controller - Define the mass storage controllers controller wd0 ad isa? Port “IO_WDI” bio irq 14 disk - Define a disk connected to a controller disk wd0 at wdc0 drive 0 tape - Define a tape connected to a controller tape wt0 at wdc0 drive 4 device - Define a device that has no controller device sc0 at isa? Tty (system console device) pseudo-device - Define a pseudo device pseudo-device loop (network loopback device)

Adding BSD Devices Once you have configured all of the devices, build the kernel. 1. Run the config command to build the kernel compilation repository. The configuration file should be located in /sys/arch/conf, and the config command will create the directory /sys/compile/kernel_name (where kernel_name is the name of your new kernel configuration). Once this completes, change the directory to the compilation directory, and run the command make depend, followed by the command make. Under BSD operating systems, the names can be difficult to divine. Few “standards” exist to assist you in naming a device. There are usually controllers named isa0 (ISA bus), pnp0 (Plug and Play), eisa0 (EISA bus), and pci0 (PCI bus). The console subsystem consists of a controller named atkbdco (AT keyboard controller), with devices named atkbd (AT keyboard), a psm0 (PS mouse), and a vga0 (video display). Floppy controllers are fdc devices, and floppy diskette drives are fd devices. The IDE controllers are named wdc0 and wdc1, each of which can support two wd devices (disks). A CD-ROM drive is an acd0 device. For other devices, read the on-line documentation that comes with the specific BSD OS for more information on naming the devices.

Adding BSD Devices 2. Install new kernel: Copy the recently compiled kernel to the root directory. It is best to not write over the running kernel. Therefore, first copy the running kernel to something like /vmunix.ok, and then copy the new kernel to /vmunix. 3. Reboot new kernel: Shut the system down and hopefully boot the new kernel. It is possible to tune the BSD kernel using the sysctl command. Invoking sysctla will cause the system to list all of the tunable kernel parameters.

Adding Solaris Devices
Solaris provides several methods of rebuilding the device information tree. Two of these methods require a system reboot. The third method allows the operator to reconfigure devices “on the fly.” boot -r: This command tells the OpenBoot monitor to reconfigure the device information tree before starting the operating system. touch /reconfigure; reboot: The Solaris start-up code looks in the root directory for the /reconfigure file. If this file exists, Solaris will rebuild the device information tree as part of the boot process. Whenever a device is added or removed, the system should be restarted with the boot -r command. This forces the operating system to rebuild the device information tree and load the correct drivers.

Adding Solaris Devices
A more dangerous way of reconfiguring the system on the fly is to execute the drvconfig, disks, tapes, and devlinks commands. These four commands cause the system to probe for new disk and tape devices, and add them to the device information tree while the system is up and running. Although these commands are available and perform the task, it is always best to use the boot -r command to let the system find and install the devices at reboot time. In addition to rebuilding the device information tree, you can edit the /etc/system file to supply configuration options to the kernel at boot time.

Summary This chapter examined how devices on systems are named and how they are addressed. Several examples detail the relationship between device-special files, logical device names, device aliases, physical device names, and addresses of the devices. The examples also show how to track down the device physical address information for several typical device aliases. Many PROM monitors also give the operator access to system devices. This chapter examined some of the PROM monitor commands available to examine/configure system devices. Example output shows how to identify the devices and driver modules loaded on a system, how to use this information to determine where to install new devices on the system, and how to force the system to reconfigure the device information when devices are added to or removed from the system.

Summary The administrator should understand internal system device interconnections. The administrator should understand device configuration and access from the hardware perspective. The administrator should understand device configuration and access from the software perspective. The administrator should understand how to view the system’s copy of the device information. The administrator should understand device naming schemes used by various operating systems. The administrator should understand how to add a device to an operating system, and rebuild the kernel.

Disks and File Systems Chapter 8

Chapter Goals Recognize basic disk components.
Understand basic disk geometry. Understand partitioning and formatting. Recognize advantages and disadvantages of SCSI, IDE, and alternative disk systems. Recognize similarities and differences in popular Windows and UNIX file system structures. Understand how to create a file system. Understand how to make a file system available.

Disk Subsystem Disk Drives (General)
Disk drives are one of the most important parts of a system. Because they have moving parts, disk drives break down! Some disk failures are survivable (soft errors, random bad blocks). Other disk failures are catastrophic (head crash, electronics failures). The System Administrator has to know how to determine what is wrong, and how to fix it. Disks play a big part in overall system performance. Access time is orders of magnitude slower than memory. File system layout can cause performance problems.

Disk Subsystem Disk Drive Components
Disk drives contain several key components: Magnetic media Read/Write heads Assorted logic read/write, positioning, memory, status, bus interface) Motor Positioner

Disk Subsystem Disk Drive Terminology
Disk drives have a language all their own: cylinders tracks (or heads, or surfaces) sectors seek crash servo positioner bad blocks geometry partition format

Disk Drives 101 A platter is coated with magnetic particles (oxides).
By changing the orientation of these magnetic particles we can encode zero’s and ones and store them on the platter. The platter is mounted on a spindle that is driven by a motor. A read write head “flys” above the surface of the platter. This head contains a small electromagnetic device that can determine the orientation of the particles on the platter. By passing a current through this magnetic device, we can also magnetize the particles to alter their orientation.

Disk Drives 101 Because the platter is spinning, and the head’s position is somewhat “fixed”, we end up with a ring of information (cylinders) on the platter. By creating many rings on the platter we increase the storage density of the platter. A positioner moves the read/write heads from ring to ring on the platter(s). By stacking many platters (hence more read/write heads) on the same spindle we increase the density of the disk. Each ring (cylinder) is broken up into uniform chunks (sectors). Each sector can hold some amount of data. The raw capacity of the disk drive is determined by : # cylinders X #heads/cylinder X #sectors/head X #bytes/sector

Disk Partitions Sometimes it is desirable to segment, or partition a physical disk into multiple logical disks. Sometimes the OS buffering routines provide better performance if the disk is partitioned. It is generally desirable to partition files such that system files, application files, and user files are on separate partitions. A partition is a logical grouping of a number of physical cylinders into a logical disk drive. Each operating system and hardware architecture has it’s own method of partitioning a disk.

Disk Partitions Most operating systems for Intel x86 architectures use the fdisk program to partition the disk. Non-Intel architectures use another program to perform the same operation. Once the disk has been partitioned, file systems are created on the logical disks. On Windows boxes, this is done using the format program. Non-Windows boxes typically use the mkfs, or newfs utilities to perform this operation.

Disk Subsystem Advanced Disk Geometry
O.K., so we have cylinders, heads, sectors, a positioner, and partitions. Now what? How does this relate to storing and retrieving the information we want? Before we can store and retrieve data we have to come up with a way of uniquely identifying each cylinder/head/sector on the drive. An Index mark on the spindle gives us a starting reference point. The read/write surfaces are numbered 0 (zero) through H. Head zero reads/writes data on platter 0. Head 1 reads/writes data on platter 1, and so forth. Cylinders are numbered 0 (zero) through C. Some manufacturers use the innermost cylinder as 0. Other manufacturers use the outermost cylinder as 0.

Disk Subsystem Any guess where sector “s” is located?
Starting on cylinder zero, sectors are numbered 0 (zero) through S. Sector zero is the first sector after the index mark. Sector zero is also the first sector on surface zero. Any guess where sector “s” is located?

Disk Subsystem Disk Geometry
Sector S is the first sector on cylinder 0, surface 1. Why is sector s on the next surface, not the next cylinder?? It is much faster to have electronics “turn off” one head, and enable the next head than it is to move the positioner to the next cylinder! (ns vs. ms). Sector 2S is the first sector on cylinder 0,surface 2 and so on. Sector HS is on cylinder 1, surface 0. By continuing this numbering scheme, we can determine the “address” of each sector on the disk drive. As long as the hardware can keep up, we can count this way forever.

Disk Subsystem Disk Geometry
Unfortunately, early systems did not have the ability to count forever. Early UNIX was designed to run on 16 bit hardware. 16 bits allowed us to count to 65,536 sectors. At 512 bytes/sector, this only allowed us to access 32 Megabytes of data per disk drive. By partitioning a large disk into several smaller logical disks, we had a way of addressing the entirety of the disk drive: partition 0 was the first 32 Mb, partition 1 was the second 32 Mb and so on. Newer hardware is capable of addressing much larger disks, but partitioning is still in use.

Disk Interfaces At this point we have a basic understanding of the physical disk media. Now we need to examine how this media is connected to the system. There are several interfaces used between the system bus, and the disk drive. Small Computer System Interconnect (SCSI) Fibre Channel Integrated Drive Electronics (IDE) Firewire USB Parallel port

SCSI SCSI devices SCSI has become one of the more popular bus adapters for PC, MacIntosh, and Workstation systems. There are many flavors of SCSI (see table, next page). You need to make sure that you don’t mix different types of SCSI devices together: Performance might suffer! Physical damage may result! Errors will be difficult to track down

SCSI SCSI bus systems can be very finicky.
Termination is very important. There should be a terminator at each end of the bus. Active (regulated, forced perfect) terminators are best. Cable length is very important. Specified cable lengths are maximums. It is best to keep external cables as short as possible. Internal cables often use a considerable amount of the cable budget. Don’t mix HVD and LVD devices! High Voltage Differential Low Voltage Differential

SCSI Disk Formatting (SCSI)
SCSI disks are very different from their predecessors: SMD disks had a fixed number of sectors/track. SCSI disks allow variable numbers of sectors/track. SMD disks had variable sector sizes. SCSI disks have a fixed sector size. SMD disks used data headers in each sector to keep track of control information. Therefore the sector size was usually set to 512 data bytes + some number of header bytes. SCSI disks do not have headers! That’s a LIE. They do have headers, we just can’t see them. The logic on the disk drive is the only thing that can see the headers.

SCSI With the older disks, because of the fixed number of sectors/cylinder, the OS was in charge. The OS could always calculate exactly where the sector was because all of the operands were constants: The system disk has 1024 cylinders, 19 heads, and 17 sectors/cylinder, and each sector can hold 512 data bytes. The disk contains how many sectors? 1024*19*17 == sectors The disk can store how many bytes of data? * 512 == 169,345,024 bytes

SCSI This user wants to read block zero of their file which the file system claims resides on block 14,560. How do we find the sector on the disk? 14,560 / (19*17) ==> Our sector is on the 45th cylinder The 45th cylinder starts at sector: 45*19*17 ==> 14,535 We know our sector isn’t the first one on cylinder 45, so we have to determine which surface it is on: 14, ,535 ==> Our sector is 25 sectors after the start of cylinder 45 45 / 17 > Our sector is on surface 3 45 - (17 * 2) ==> Our sector is the 11th sector on surface 3 Give me sector 11, on surface 3, cylinder 45 please NOTE: This is an oversimplification. In reality, the system counts from 0 for cylinder/head/sector!

SCSI With SCSI the variable number of sectors per cylinder tends to confuse the OS. SCSI drives lie to the OS by telling it “I have C cylinders, H heads, and S sectors/track. The OS uses this value when it fills in the file system tables. The OS goes through the same computations to read/write the blocks on the disk. The SCSI disk hardware takes the numbers from the kernel, and does it’s own computations to determine where the block really resides on the disk! The operating systems still have the misconstrued notion that they are in charge! In reality, most current OS’s just ask for file system block N, and let the disk drive do the calculations

SCSI Review - Disk Formatting (SCSI)
UNIX file systems do not understand the concept of variable numbers of sectors/track (or zone sectoring) on SCSI disks. The file system wants to view the world as “the disk has X sectors/track, Y data heads, and Z cylinders”. SCSI disk drives want the world to view them as N contiguous data blocks (1 cylinder, 1 head, N sectors). In order to keep everybody happy, we tell the Operating System that the disk has some number of cylinders, some number of heads, and some number of sectors/track. The disk drive promptly ignores this notation, and “does the right thing”

So how do we figure out these magic numbers? First determine how many sectors the drive contains (alternately we can derive this from the drive capacity). Factor this into prime numbers. Make up #cylinder, #head, #sector entries based on these prime numbers and feed this information to the format program. As long as the numbers of cylinders, heads, and sectors that we give the system generates a number equal to, or less than the number of sectors on the drive, we are in business.

SCSI It is generally best to tell the system numbers which make sense as far as performance goes: Switching heads is fairly fast. Switching cylinders is fairly slow. Unfortunately, if you claim 1 cylinder, with a whole bunch of heads, the I/O performance is pretty bad. It is better to try to find out how many cylinders the drive has, and use a # cylinders number that is close to that value.

SCSI The more sectors that go under one head in one revolution, the more data we can transfer without switching heads, or moving the heads to another cylinder. On the other hand, the buffers are all finite sizes, so you lose if you tell the system too large a number for the number of sectors. Most vendors give a ncyl/nhead/nsect specification for their drives…use it whenever possible! When it isn’t possible, the following may be helpful:

SCSI Example: Assume we have a drive with 10,000 sectors.
Use the /bin/factor program to find the prime factors: 10,000 ==> 2 X 2 X 2 X 2 X 5 X 5 X 5 X 5 Group these factors into C/H/S groupings: 5 X 5 X 5 X 2 cylinders, 2 X 2 heads, 2 X 5 sectors 250 cylinders, 4 heads, 10 sectors/track. Example: Assume we have a 512 Megabyte drive: determine the number of sectors by dividing the capacity by the sector size (512,000,000 / 512 ==> 1,000,000 sectors). Factor this: 2X2X2X2X2X2X5X5X5X5X5X5 Group these factors into C/H/S groupings: 5X5X5X5X2 Cylinders, 2X2X2 heads, 5X5X2X2 sectors 1250 cylinders, 8 heads, 100 sectors/track

If SCSI disks were perfect, this scheme would work every time! Unfortunately, disks have defects when they leave the factory, and more defects appear over time. In order to accommodate these defects, the concept of alternate sectors, alternate cylinders, and bad block forwarding was developed. When the format program “numbers” the sectors from 0 through S-1. What happens if a sector is bad? By allocating some number of “spare” sectors we can map bad sectors to good sectors!

SCSI Disk Formatting (SCSI) Consider the following scenarios:
Platter with bad sector Same platter with sector mapped to alternate sector on same cylinder. Same platter with sector mapped to alternate cylinder. Need pictures here!!!

SCSI If the bad spot is located on a cylinder which contains a “free” alternate sector, this is the preferred location to map the bad block. The drive electronics do not have to move the heads in this case. The only “penalty” is the delay caused by the rotational latency of the platter. On the other hand, if there is no free alternate sector on the same cylinder as the bad spot, there are penalties to be paid. The drive electronics have to move the heads to an alternate cylinder, and then write the data into the alternate location. The original bad spot has to be marked bad, and a table has to be updated to point to the new “alternate” location for the data from that sector. Every time the file is accessed, this penalty is paid.

Most versions of UNIX have a file which contains a database of disk models and corresponding format information for these disk drives. Under Solaris this file is /etc/format.dat The format.dat file contains a lot more than just the C/H/S information on the drives: Other information includes: the type of controller, the cache control flags for the drive, the number of alternate sectors, the rotational speed of the drive, the number of bytes per track, zone sectoring information, and typical partition table entries for this drive.

UPDATE THIS

Once the information is in the format.dat file we use the format command to format the disk. The format program issues a “format unit” directive to the SCSI disk. The SCSI disk electronics format the media, and map out bad spots. Once the sectors are all numbered and verified, the format command writes a label on the disk. This label contains the geometry information, and other information required by the operating system (rotational speed, capacity, partitioning...).

IDE The IDE interface, a mainstay of the PC market, has found its way into the workstation market because of its ease of configuration and low price. The IDE interface automatically takes care of all of the details of formatting the drive, and mapping out bad sectors. The SCSI interface requires more attention from the operator during format/repair operations, but the data throughput performance makes it the logical choice for high-performance servers and workstations. The system administrator needs to be aware of the interface capabilities when recommending systems for particular applications! The administrator also needs to be aware of the different operation/maintenance procedures for both SCSI and IDE drives

IDE Early IDE disks were relatively slow, at 1 megabyte per second.
Current IDE standards (ATA33 and ATA66) have produced IDE disk systems that transfer at rates of 33 megabytes per second, and 66 megabytes/second, with 100-megabyte-per-second IDE systems (ATA100) just around the corner.

Fibre Channel Although current SCSI subsystems can transfer data at 160+ megabytes per second, this was not always the case. Designers wanted a faster channel between the host and the disk farm than SCSI could provide. One technology that provided a high-speed channel already existed: Fibre Channel. Because it uses fiber optic cabling, Fibre Channel is capable of driving signals over a long distance at high speeds. Fibre Channel technology provides connections capable of delivering a gigabyte of data per second, compared to a high-end SCSI that can provide two to four hundred megabytes of data per second.

Fibre Channel To provide maximum I/O subsystem performance, many RAID arrays include a fiber channel host interface. This interface provides a 25-megabit-per-second (or faster) interface between the disk array and the file server. High-end RAID arrays may include a 100-megabit-per-second Fiber Channel interface, or a Fiber Channel Arbitrated Loop (FCAL) interface.

Disk Subsystem Load Balancing Disks
Disks are one of the biggest performance bottlenecks in any computer system! Reliable high-speed disks do not exist! We have to make the best of the drives available. We can increase disk I/O throughput by adding I/O adapters. The system can overlap operations on all I/O adapters. If we split the file systems up the right way we can help the system: Put swap and /tmp on separate disks, Put /usr and /opt on separate disks.

We can increase disk I/O throughput by adding spindles: The system can overlap operations on multiple drives. Command queuing on the drives improves throughput. If we split the file systems up the right way we can help the system: Put swap and /tmp on separate disks, Put /usr and /opt on separate disks.

Disk Subsystem We can increase disk I/O throughput by using technologies such as Redundant Arrays of Inexpensive Disks (RAID). RAID defines several types of disk interfaces. Some of these are for designed for high reliability applications, some are designed for high throughput applications.

Raid Level 0 implements a striped disk array. The data is written across multiple disk drives. This improves throughput by spreading the I/O load across several channels and drives. A striped disk does not provide any additional data redundancy or fault tolerance over standard disk systems. Raid Level 1 implements a mirrored disk array. The data is written to two disks. This ensures that the data is available even if one disk drive fails. A mirrored array does not provide any performance benefits. Raid Level implements a mirrored striped array. This allows for data redundancy and improved throughput. Pictures of the different raid levels!

Raid Level 2 interleaves data sectors across many disks. A sophisticated error correction facility provides some degree of fault tolerance. Raid 2 is not found in use very often. Raid Level 3 interleaves data sectors across many disks much like Raid Level 2. Raid Level 3 uses a separate “parity” disk per array for error correction. If a disk fails, the parity disk can regenerate that portion of the data on the fly. Raid Level 4 implements a striped array with a parity disk. This level is not used very often. Raid Level 5. Raid Level 5 interleaves data sectors across many disks much like Raid Level 3, but instead of a single parity disk, the parity information is also interleaved across multiple disks.

Disk Subsystems

Hardware solutions aren’t the only way to improve disk throughput and/or reliability. Many Vendors offer software products that will treat ordinary SCSI controllers and disks as though they were an array of disks. The Windows volume manager allows volume sets, RAID volumes, and extended storage. Many vendors offer software that will migrate files between disk drives to improve throughput. Many vendors offer products that will defragment and migrate files within a file system in an attempt to improve throughput. Add windows stuff here

General Checklist for Adding a Disk
Regardless of the disk interface in use, the general procedure for adding a new disk to a system, is very similar. 1. Identify the target address the new drive will use. 2. Shut the system down using the shutdown command. 3. Set the drive address jumpers, and install the new drive on the system. 4. Boot the system as required to cause the system to find new hardware. 5. If necessary, use the format and/or fdisk utilities to format and partition the new drive. 6. Bind sectors in a partition into a file system. 7. Check file system integrity. 8. Add the new file systems to the system tables. 9. “Mount” the new file systems. 10. Bring the system down. 11. Use boot to restart the system.

Adding an SCSI Disk to the System
As long as the SCSI or IDE adapter does not already have its full complement of devices, connecting a new disk is pretty simple. Depending on the type of SCSI adapter, it may be possible to connect 7, or 15, devices to a single SCSI adapter. Each device must have a unique SCSI identification (ID), which is also known as the SCSI address, or unit number. Some systems automatically select the SCSI ID when you plug the drive into the system chassis. This ensures that you do not connect two devices with the same address. On other systems the operator needs to determine which SCSI IDs are already in use, and then set the SCSI ID of the new device to one of the unused values. This is typically accomplished by installing small jumpers on the drive. If the drive is mounted in a case, the SCSI is sometimes selected via a push-button switch on the case. Some OSs only allow certain types of devices to use specific SCSI IDs, whereas other systems have no such restrictions.

Adding an IDE Disk to the System
IDE adapters allow the connection of two devices to the system. Most PC motherboards include two IDE channels, which facilitate the connection of four IDE devices (two per channel). IDE disks usually require less setup than their SCSI counterparts. If there is only one device connected to the IDE channel, install the MASTER jumper on the drive. If two devices are installed, one should be the MASTER (install the master jumper), and the other should be the SLAVE (install the slave jumper). Once the drive jumpers have been set, adding it to the system is as simple as plugging it into the IDE cable, and connecting a power cable to the drive’s power connector. NOTE: Setting the master/slave jumpers incorrectly, or attempting to connect more than two devices to the IDE bus will cause problems communicating with the IDE subsystem.

NAS AND SAN Network-attached Storage
Another type of storage system currently in use is the Network Attached Storage (or NAS) system. The NAS system is a special-purpose computer that runs a stripped-down OS. This computer is outfitted with several disk controllers, and many disk drives, typically providing hundreds of gigabytes of storage for a local facility. The NAS storage system can typically provide network-based file sharing for UNIX and Windows clients. A typical NAS storage system contains one or more high-speed network interfaces. Data requests and delivery are carried out over the communications network. It is not unusual for a NAS system to provide data to the client machines at a rate of 15 to 45 megabytes per second over a 100- (or 1000-) megabit-per-second network.

NAS AND SAN Storage Area Networks
A more recent entry in the storage systems arena is the storage area network, or SAN. A SAN is designed to provide multiple paths between end nodes (client workstations) and storage elements. A SAN relies heavily on high-speed fiber connections between storage components. These data paths are independent of the normal network connections, and are used exclusively for disk-farm to client-system data transfers. The system’s network interfaces are used for normal data communication traffic, such as web browsing, , and log-in sessions

Utilities Once a disk is connected to the system, it has to be “formatted” before it can be put into use. The task of formatting the disk drive is carried out using a hardware-based format utility, or an operating-system-based format utility. The hardware-based utilities are often referred to as a “low-level” formatter, as they provide a hardware-level format to disk drive(s). The low-level formatter knows nothing of partitions. These formatters number all sectors on the drive under the assumption that the entire disk drive is one large partition.

Utilities The software-based utilities allow the operator to partition the disk into multiple logical disk drives. The sectors on each logical partition might be independently numbered, but generally the formatter just creates a table that delineates how to split the existing “low-level” format into multiple partitions. Some OS provide multiple tools for partitioning and formatting disk drives. Other OS combine all of these functions into a single utility.

Windows File systems Windows Disk Administrator Utility
The Windows 2000 Disk Administrator utility is a GUI-based tool that allows the operator to format the disk, partition disks, write labels to disks, and assign volume labels and drive letters to system disks. The Disk Administrator also allows the operator to create software-based RAID storage systems known as extended partitions or volumes. In addition to allowing the operator to partition and format system disks, the Disk Administrator is the tool that creates the Windows file systems and all of the requisite file system structures on the disk.

Windows File systems Windows Command-line Disk Utilities
The Disk Administrator utility contains all of the tools required to manage a disk on a Windows system. However, sometimes it is not possible, or desirable, to use the GUI-based Disk Administrator utility. In addition to the Disk Administrator, the command-line tools fdisk.exe and format.exe allow the administrator to partition and format disks. The fdisk tool is used to partition disks, and to select the type of partition. fdisk allows the operator to select which partition will be “active.” The active partition is the one that contains the OS you want to boot. The format utility numbers all of the sectors on the partition, maps out any bad spots, and generates all of the necessary file system structures. The format utility uses the following generic syntax. format volume [/fs:file-system] [/v:label] [/q] [/a:unitsize] [/f:size] [/t:tracks /n:sectors] [/c] [/x] [/1] [/4] [/8]

Windows File systems Windows offers several file systems. Under the most recent commercial versions of windows there are three file systems available: FAT 16, FAT 32, and NTFS. FAT The File Allocation Table (FAT) file system is the “old standard” file system for Windows installations. The FAT file system suffers from a lack of feature bloat, but it is still the backbone of the consumer-oriented versions of Windows. There are several versions of the FAT file system available under various versions of Windows. The most current versions are FAT 16 and FAT 32. FAT 16 is used for backward compatibility with older consumer versions of Windows. FAT 32 is the latest version of the FAT file system, The on-disk structure of the FAT 16 and FAT 32 file systems is similar, but just different enough to make them incompatible. The FAT file system stores two copies of the file allocation table within the volume. If one copy of the table becomes corrupted, in theory the system can automatically recover using the second copy of the information.

Windows File systems The FAT 16 file system can support partitions up to 4 gigabytes (4,096 MB). Each file or folder stored in a FAT 16 file system is provided with a 32-byte entry in the file allocation table. The file allocation table is the master index of what files are stored on the partition, and which sectors/clusters are used to store this file. Using this information, it is also possible to determine which sectors should be “free” and available to store future files. The file allocation table is a packed list of 32-bit entries with a one-to-one mapping to file system clusters. The file allocation table entries contain the following information. Name format filename.extension Attribute 8 bits Only four bits are currently defined: read-only, system file, archive, hidden Create time 24 bits Create date 16 bits Last access date 16 bits Last modified time 16 bits Last modified date 16 bits Starting cluster number 16 bits Cluster contains a pointer to the next cluster, or the value 0xFFFF if this is the last cluster used by the file File size 32 bits The entries in the table are created on a first-come, first-serve basis; there is no overlying structure to the table! The default size of the disk clusters is determined by the size of the partition. The minimum cluster size is 1 sector/cluster (512 bytes) for small (32 MB or smaller) partitions. The largest cluster size is 128 sectors (64 Kbytes) for large (2,048 to 4,096 MB) partitions. The operator can tune the cluster size using the format command with the /a:size switch when invoking format.

Windows File systems The FAT 32 file system supports partitions up to 2,047 gigabytes, and files up to 4 gigabytes, but the most current versions of Windows can only create partitions up to 32 GB. The file allocation table entries are very similar to the FAT 16 table entries, but many fields have been expanded in size. The primary operational difference is that the cluster number entry is 4 bytes (32 bits) on a FAT 32 file system, and a FAT 32 file system requires at least 65,527 clusters. FAT 16 and FAT 32 file systems do not scale well. As the number of entries in the file allocation table increases, the amount of work required locating a file increases. In addition, the table does not provide storage for attributes such as file ownership, or access modes. The FAT file system provides no means of securing files from users that might use the system.

Windows File systems The New Technology File System (NTFS) is a newer file system provided with the commercial versions of Windows. The NTFS file system provides the structures required for file security and ownership, as well as correcting the scalability problems found in FAT file systems. In addition, the NTFS file systems includes transaction logging to provide increased reliability and performance.

Windows File systems When a partition is formatted for NTFS, the following support structures and metadata required for the NTFS file system are created. The first 16 records (roughly 1 megabyte) of the MFT are reserved for the NTFS metadata. Boot sector: Sectors 0 through 15. The boot sector contains the BIOS parameter block. BIOS parameter block: Contains information about the volume layout and file system structures. Code: Describes how to locate and load startup files (typically NTLDR.EXE). System files: Include entries for the following information. MFT Record 0, Master File Table: Contains information about every file and folder stored on the partition. MFT Record 1, Master File Table # 2: Backup copy of the MFT. MFT Record 2, Log File: List of recent transactions. Used to provide recoverability. MFT Record 3, Volume Name: Name of this partition MFT Record 4, Attributes: Table of file and folder attributes, including security descriptors and the following file type attributes. · Standard information: Time stamps, link counts, and the like Attribute list: List of the attribute records that do not reside in the MFT. Filename: Up to 255 unicode characters, and an 8.3 representation. Security descriptor: File access permissions. Data: Data stored in the file.

Windows File systems Data: Data stored in the file. Index root: Used to implement folders. Index allocation: Used to implement folders. Volume information: Volume name and version number. Bitmap: Map of clusters used by this file. Extended attribute information: Not used by NT; provided for OS/2 compatibility. Extended attributes: Not used by NT; provided for OS/2 compatibility. MFT Record 5, Root Filename Index: Name of the root folder ($.). MFT Record 6, Cluster Bitmap: Bitmap that represents which clusters are used and which are free for use MFT Record 7, Partition Boot Sector: Bootstrap code for this partition, if the partition is marked as bootable. A copy of this information is located elsewhere on the partition. MFT Record 8, Bad Cluster File: List of the bad clusters on this partition. MFT Record 9, Quota Table: Disk usage information for each user. Currently unused. MFT Record 10, Uppercase Table: Table to provide lowercase to uppercase unicode character mapping. MFT Records 11 – 15: Six records reserved for future use. It should be obvious that the NTFS stores much more information about a file than the FAT file system. This extra information allows the NTFS file system to support security, as well as provide improved system performance and file lookup speed.

UNIX File systems Due to the large number of UNIX variants, there are also large numbers of file systems supported under UNIX. The first five file system types listed—ufs, hsfs, pcfs, nfs, and tmpfs—are the most commonly used under most UNIX variants. A workstation on a network may employ many types of file systems concurrently. Some OS accomplish this by abstracting the file system driver out of the kernel, and into the file system mount code, or as loadable kernel modules. Other OS accomplish this by making file system drivers an integral portion of the OS kernel code.

UNIX File systems ufs File Systems
The ufs file system is the standard UNIX file system based on the Berkeley Fast File system. Most other UNIX file systems rely on the structures provided by the UFS file system. The current UFS file system implements several modifications to early UNIX file systems to improve disk subsystem performance and reliability. Many system utilities will work only on ufs file systems. The most notable of these utilities are the ufsdump and ufsrestore commands. Some UNIX variants also provide ufs logging. A file system that employs ufs logging is more fault tolerant than a standard ufs file system. The ufs logging feature allocates 1 megabyte of file system space per gigabyte of file system for use as a transaction log. The system disk driver writes all transactions to the log. Once the ufs log has been written, the driver considers the transaction complete. The information in the ufs log is written to the file system at a later time. Consult the manual page for mount_ufs for more information on ufs logging, and how to configure/enable it for specific versions of UNIX.

UNIX File systems The superblock provides the structure of the UFS file system. The superblock stores much of the information about the file system. Such information includes the following. Size and status of the file system Label: file system name and volume name Size of the file system logical block Date and time of the last update Cylinder group size Number of data blocks per cylinder group Summary data block: contains summary information about the partition, number of inodes, directories, fragments, and storage blocks on the file system File system state information: clean, dirty, stable, active Path name to last mount point Some UNIX variants also provide ufs logging. A file system that employs ufs logging is more fault tolerant than a standard ufs file system. The ufs logging feature allocates 1 megabyte of file system space per gigabyte of file system for use as a transaction log. The system disk driver writes all transactions to the log. Once the ufs log has been written, the driver considers the transaction complete. The information in the ufs log is written to the file system at a later time. Consult the manual page for mount_ufs for more information on ufs logging, and how to configure/enable it for specific versions of UNIX.

UNIX File systems Superblocks are located at the beginning of the partition, and are replicated in each cylinder group. Each superblock replica is offset from the beginning of the cylinder group by a different amount. The amount of offset is calculated to provide a superblock on each platter of the drive. The inode structure is stored in the summary information block of the superblock. The inode is a 128-byte structure that contains the following. Type of file: regular, directory, block special, character special, symbolic link, FIFI/named pipe, or socket Mode of the file: read/write/execute permissions for this file User ID of the file owner Group ID of the file owner Number of bytes in the file Array of 15 disk block addresses used by this file Date and time file was last accessed Date and time file was last modified Date and time file was created Some UNIX variants also provide ufs logging. A file system that employs ufs logging is more fault tolerant than a standard ufs file system. The ufs logging feature allocates 1 megabyte of file system space per gigabyte of file system for use as a transaction log. The system disk driver writes all transactions to the log. Once the ufs log has been written, the driver considers the transaction complete. The information in the ufs log is written to the file system at a later time. Consult the manual page for mount_ufs for more information on ufs logging, and how to configure/enable it for specific versions of UNIX.

UNIX File systems The array of 15 disk blocks stored in the inode point to the data blocks that store the file’s content. The first 12 of these blocks are called “direct” blocks. The direct blocks point directly to the first 12 data blocks of the file. If the file is larger than 12 data blocks, the 13th disk block points to an “indirect” data block. The indirect block contains block addresses of other blocks used by this file. The 14th disk block points to a double indirect block. The double indirect block points to blocks that contain addresses of additional indirect data blocks for this file. Similarly, the 15th disk block points to a triple indirect block. Figure 8-18 shows how these data blocks, indirect blocks, and double indirect blocks are used to keep track of the data portion of a file. Some UNIX variants also provide ufs logging. A file system that employs ufs logging is more fault tolerant than a standard ufs file system. The ufs logging feature allocates 1 megabyte of file system space per gigabyte of file system for use as a transaction log. The system disk driver writes all transactions to the log. Once the ufs log has been written, the driver considers the transaction complete. The information in the ufs log is written to the file system at a later time. Consult the manual page for mount_ufs for more information on ufs logging, and how to configure/enable it for specific versions of UNIX.

UNIX File systems Journaling File Systems
Journaling file systems are not a file system per se, but a method of protecting the system against lost data and corruption of information. A journaled file system allocates some portion of the partition’s storage space as a transaction journal. Every file system operation is logged to the journal. If a problem such as a system crash or power failure occurs, the system can rebuild the file system transactions by reading the journal and replaying the transactions that were missed due to the problem. Several OS provide journaling file systems. IRIX, Solaris, Windows, AIX, HP/UX, and Linux all provide some form of journaled file system. Although each of these OS provides this feature, each OS accomplishes this via different means.

Linux File Systems The Linux OS currently provides support for 15 file systems, with more on the way! Many of these file systems are similar to the “UNIX” file systems previously listed. The remainder of the Linux file systems are different enough to warrant their own coverage. As in UNIX, the Linux file systems are grouped into a single hierarchical file system tree structure. Linux file system drivers provide the means of mounting the different file systems on the tree such that they may be accessed using standard utilities.

Linux File Systems The file systems currently supported by Linux include the following. Minix: Ext: Ext2: Ext3 Xia Umsdos Msdos Vfat Proc Smb Ncp Iso9660 Sysv Hpfs Affs Ufs Minix: the original Linux file system. · Ext: The Extended file system (ext) was the replacement for the Minix file system on Linux. The ext file system came with a new concept: the virtual file system (vfs) driver. The vfs code allows the real file systems to interface with the kernel via an application-programming interface. This greatly simplified the task of porting new file systems to the Linux environment. · Ext2: The Second Extended file system (ext2) eventually replaced the ext file system on Linux. The ext2 file system continues to be the mainstay file system for Linux systems. Although it is similar to the ufs file system, it contains several modifications that improve performance and reliability of the overall file system. · Ext3: The most recent version of the ext file system under Linux. Ext3 adds a configurable level of journaling to the features of the ext2 file system. · Xia: The successor to the Minix file system. The Linux implementation allows Linux and Minim [Author: Minix?]to share files. · Umsdos: A Linux version of the DOS file system. This file system provides additional structures for supporting file ownership, and security information for DOS file systems. · Msdos: An implementation of the Microsoft DOS file system without the Linux extensions. · Vfat: A Linux implementation of the Windows FAT file system. · Proc: Refer to the UNIX file system section for information on the proc file system. · Smb: The Microsoft Server Message Block file system for Linux. This file system allows Linux to mount Microsoft SMB file systems. · Ncp: A Linux implementation of the Novel Client Protocol that allows Linux to mount Novel Netware file systems. · Iso9660: The Linux implementation of the ISO9660 file system used by most CDs. · Sysv: The Linux implementation of the original System V UNIX file system. Not used often. · Hpfs: The Linux implementation of the High Performance File System, allowing Linux to mount OS/2 hpfs partitions. · Affs: The Linux implementation of the Amiga fast file system that allows Linux and Amiga systems to share files. · Ufs: Refer to the UNIX file systems section for information on the ufs file system.

Creating UNIX File Systems
Except in special cases, a file system must be created on a partition before the partition can be used under UNIX. The act of creating a file system puts a framework on the partition that enables UNIX to store files there. The file system framework provides index information for the disk blocks initialized and mapped when the disk was formatted. Creation of a new file system under most variants of UNIX can be accomplished by invoking the newfs utility. The newfs utility allows you to create file systems with default (or custom) file system parameters. In effect, newfs is just a user-friendly front end to the mkfs program. The mkfs command creates the file system superblocks, divides the file system into several cylinder groups, and takes care of creating all file system substructures required by the OS. Minix: the original Linux file system. · Ext: The Extended file system (ext) was the replacement for the Minix file system on Linux. The ext file system came with a new concept: the virtual file system (vfs) driver. The vfs code allows the real file systems to interface with the kernel via an application-programming interface. This greatly simplified the task of porting new file systems to the Linux environment. · Ext2: The Second Extended file system (ext2) eventually replaced the ext file system on Linux. The ext2 file system continues to be the mainstay file system for Linux systems. Although it is similar to the ufs file system, it contains several modifications that improve performance and reliability of the overall file system. · Ext3: The most recent version of the ext file system under Linux. Ext3 adds a configurable level of journaling to the features of the ext2 file system. · Xia: The successor to the Minix file system. The Linux implementation allows Linux and Minim [Author: Minix?]to share files. · Umsdos: A Linux version of the DOS file system. This file system provides additional structures for supporting file ownership, and security information for DOS file systems. · Msdos: An implementation of the Microsoft DOS file system without the Linux extensions. · Vfat: A Linux implementation of the Windows FAT file system. · Proc: Refer to the UNIX file system section for information on the proc file system. · Smb: The Microsoft Server Message Block file system for Linux. This file system allows Linux to mount Microsoft SMB file systems. · Ncp: A Linux implementation of the Novel Client Protocol that allows Linux to mount Novel Netware file systems. · Iso9660: The Linux implementation of the ISO9660 file system used by most CDs. · Sysv: The Linux implementation of the original System V UNIX file system. Not used often. · Hpfs: The Linux implementation of the High Performance File System, allowing Linux to mount OS/2 hpfs partitions. · Affs: The Linux implementation of the Amiga fast file system that allows Linux and Amiga systems to share files. · Ufs: Refer to the UNIX file systems section for information on the ufs file system.

Working with the newfs Command
On most UNIX systems, the default type of file system created by newfs is a ufs file system. Two notable exceptions are Linux, which defaults to an EXT2 file system, and Irix, which defaults to an XFS file system. The syntax for invoking the newfs command: # newfs [mkfs options /dev/rdsk/c#t#d#s# Invoking newfs with the -N option causes newfs to display the basic parameters of the file system without actually creating it. The newfs command will display information about the new file system as it operates. The first line printed by newfs describes the basic disk geometry. The second line of output from newfs describes the ufs file system created in this partition. Cylinder groups are a concept introduced in the Berkeley UNIX Fast File system. Cylinder groups provide a method by which file blocks are allocated close together on the disk to improve performance.

TIP: Varying the size of the cylinder groups is one way to tune the performance of a ufs file system. The final two lines of newfs output list the locations of the superblock backups. The superblock is the head of the file index node or inode information used by the ufs file system. The inodes are “used” by routines in the Solaris kernel to allocate, read, write, and delete files. Backup copies of these superblocks are created in the event a system crash, power failure, or other problem leaves the main copy of the superblock damaged.

How newfs Connects to mkfs
As previously mentioned, the newfs command is a front end to mkfs. The newfs command invokes mkfs to perform the actual creation of the file system on the target device. The mkfs command requires a long list of parameters. For most applications, a detailed knowledge of the mkfs parameters is unnecessary; newfs makes proper choices for the parameters it passes to mkfs. It is possible to build a file system tuned to store a large quantity of small, frequently changing files, such as those found in the Usenet net-news system. Such a file system would require more index nodes or inodes than are provided by the default options used by newfs. TIP: Use of the -v option flag with newfs will allow the administrator to see which parameters it passes to mkfs. Many file system parameters may be altered by using an option flag to newfs instead of manually invoking mkfs.

Mounting File Systems General Procedure for Mounting a File System
File systems can be mounted via several methods: manual mounting by invoking the /etc/mount command, mounting the file system at boot time via the /etc/[v]fstab file, or mounting via Volume Manager. General Procedure for Mounting a File System The general procedure for mounting a file system is as follows. 1. Format the disk drive. 2. Partition the disk drive. 3. newfs the partition. 4. Create a mount point for the file system. 5. Determine which method will be used to mount the file system (manual mount, [v]fstab mount, Automounter, or Volume Manager). 6. Mount the file system.

Mounting File Systems Options are given as a comma-separated list following the -o flag (e.g., mount -o rw,quota). Some of the more common options for the mount command are. Quota - Activates the user disk quota system when the file system is mounted Ro - Mounts the file system read-only -F fstype - Mounts a file system of fstype -a - Mounts all file systems with “mount at boot” (in the vfstab file) set to yes -o - Uses specific fstype options when mounting file system -p - Provides a list of mounted file systems in vfstab format -v - Provides verbose output when mounting file system(s) -O - Overlays the file system on an existing mount point -m - Mounts file system without making an entry in /etc/mnttab Nosuid - Disallows setUID execution for files in this file system

Mounting File Systems Mounting via the fstab
The [v]fstab file is used to mount file systems at boot time. The “v” is bracketed, as some versions of UNIX call this file /etc/fstab (primarily BSD UNIX), other versions of UNIX call this file /etc/vfstab (primarily System V UNIX), and a few versions of UNIX call this file /etc/checktab (HP/UX). This file is read by the /etc/mountall command when it is run as part of the system boot sequence. A quick way to add items to [v]fstab is to use the - p option to the mount command. It is also possible to add new file systems by editing the [v]fstab file and entering the required information manually. The [v]fstab file format may contain minor modifications on different variants of UNIX,. A tab or spaces separate the fields of this file. The following is a typical Solaris [v]fstab file.

Mounting File Systems Device to mount - Name of device to be mounted.
#device device mount FS fsck mount mount #to mount to fsck point type pass at boot options /proc - /proc proc - no - fd - /dev/fd fd - no - swap - /tmp tmpfs - yes - /dev/dsk/c0t3d0s0 /dev/rdsk/c0t3d0s0 / ufs 1 no - /dev/dsk/c0t3d0s6 /dev/rdsk/c0t3d0s6 /usr ufs 2 no - /dev/dsk/c0t3d0s5 /dev/rdsk/c0t3d0s5 /opt ufs 5 yes - /dev/dsk/c0t3d0s swap - no - /dev/dsk/c1t3d0s swap - no - Device to mount - Name of device to be mounted. Device to fsck - Raw device to be checked by the fsck utility. Mount point - Directory where the device should be added to the UNIX file tree. FS type - File system type. fsck pass - Number indicates the order which the file system will be checked. Mount at boot - Yes to cause file system to mount at boot. Mount options - Options to be passed to the mount command.

Mounting File Systems UNIX file systems (ufs) are the only file systems on which the file system checker (fsck) operates. If the fsck pass field contains a minus sign () or a zero (0), no file system integrity checking is performed. A file system with an fsck pass of one (1) indicates that the file system is to be checked sequentially (in the order it is listed in the [v]fstab file). Note that the / (root) file system is always checked first. File systems with an fsck pass number greater than one (1) are checked in parallel (simultaneously). For systems with a large number of disks spanning multiple disk controllers or disk busses, parallel file system checking is generally faster than sequential checking. For efficiency, use fsck on file systems of similar size on different disks simultaneously. Once the appropriate information has been entered in the [v]fstab file, you can mount all file systems by invoking the following command. # /etc/mount -a

Mounting File Systems The Volume Manager provides users with a means of mounting/unmounting removable media without granting system users root privileges typically required to mount/unmount a file system. Under Linux, you can add the “user” option to the list of options for a file system. This allows any user to mount/unmount the file system (an operation that usually requires root access). For example, the following fstab entry would allow any user to mount the /jaz file system located on the removable disk /dev/sda1. The nosuid option disallows execution of suid programs from this medium. /dev/sda1 /jaz ext2 defaults,user,exec,nosuid,noauto 0 0 usermount is a graphical tool developed by The usermount tool is available for several UNIX distributions that will allow users to manage removable media, such as floppy disks or zip disks. When the tool is invoked, it scans /etc/fstab for all file systems that have been configured to allow users to mount and unmount them. The file system can be mounted or unmounted by pressing the toggle button labeled Mount. usermount is available at

Creating and Mounting Identifying Mounted File Systems
Connecting a file system to the tree structure is called “mounting” the file system. UNIX provides several ways for the administrator to identify which file systems are currently mounted on the system. Three of the most common methods are: invoke /etc/mount command invoked with no arguments, Invoke the df command, and examination of the /etc/mnttab file The df Command Invoking the df command with no argument results in the display of information for all mounted file systems. glenn% df / (/dev/dsk/c0t3d0s0): blocks 9292 files /usr (/dev/dsk/c0t3d0s6): blocks files /tmp (swap): blocks 3288 files /opt (/dev/dsk/c0t3d0s5): blocks files

Creating and Mounting When df is invoked with a directory argument, the output format changes, as shown in the following. glenn% df / File system kbytes used avail capacity Mounted on /dev/dsk/c0t3d0s % / The most complete df listing is obtained by using the -g option glenn% df -g / / (/dev/dsk/c0t3d0s0): 8192 block size 1024 frag size 41328 total blocks free blocks available total files 9292 free files filesys id ufs fstype 0x flag 255 file name length NOTE: It is important to remember the differences among the three block sizes discussed in this chapter. A disk block is the basic unit of storage on the physical medium. This unit is often 512 bytes long, but not always. An allocation block is the basic unit of space in a file system. It is either 8,192 or 4,096 bytes in length. A fragment, often 1,024 bytes in length, is a portion of an allocation block.

Creating and Mounting The /etc/mnttab File
Another way to determine which file systems are mounted is by examination of the /etc/mnttab file. This file is created and maintained by the /etc/mount command. Every time a file system is mounted, an entry is added to the mnttab file. When a file system is unmounted, the entry is removed from the mnttab file. # cat /etc/mnttab /dev/dsk/c0t3d0s0 / ufs rw,suid,dev= /dev/dsk/c0t3d0s6 /usr ufs rw,suid,dev=80001e /proc /proc proc rw,suid,dev= fd /dev/fd fd rw,suid,dev=27c /dev/dsk/c0t1d0s6 /var ufs rw,suid,dev=80000e swap /tmp tmpfs dev=

Creating and Mounting The mount Command
The mount command allows the administrator to view which file systems are mounted, as well as providing a method of mounting file systems. When invoked without arguments, the mount command lists mounted file systems by their mount points, showing the device mounted at each mount point, the mount options used, and the time the file system was mounted. glenn% /etc/mount / on /dev/dsk/c0t3d0s0 read/write/setuid on Sat Apr 1 1:23: /usr on /dev/dsk/c0t3d0s6 read/write/setuid on Sat Apr 1 1:23: /proc on /proc read/write/setuid on Sat Apr 1 1:23: /dev/fd on fd read/write/setuid on Sat Apr 1 1:23: /tmp on swap read/write on Sat Apr 1 1:23: /opt on /dev/dsk/c0t3d0s5 setuid/read/write on Sat Apr 1 1:23:

Creating and Mounting Unmounting a File System
The complement to mounting a file system is to unmount it using the /etc/umount command. Exercise great care when unmounting file systems! Some file systems are required for proper system operation. Other file systems may be unmounted while allowing the system to continue to operate, but the system will not perform as expected. The syntax for the umount command follows. # umount mount_point or # umount device

Creating and Mounting The first form of the umount command unmounts the file system referred to by “mount point.” For example, umount /scratch would unmount the /scratch file system. The second form of the umount command unmounts the file system on the referenced disk partition. For example, if the /scratch file system is on the c0t2d0s1 disk partition, the operator could unmount it with umount /dev/dsk/c0t2d0s1. If you are uncertain about the effect unmounting a file system may have on the system, it is best to bring the system to the single-user state before invoking the umount command. In the case of a file server, unmounting a file system may also have an effect on nfs client machines on which the file system is mounted.

Creating and Mounting Volume Manager
Adding entries to the Solaris vfstab file works well for hard disks but is not suitable for removable media such as floppies and CD-ROMs. These devices tend to be mounted and unmounted much more frequently than hard disks, and the user performing this “mount” operation may not have the root privileges required to mount a normal file system. To handle such situations, Solaris uses the Volume Manager. Other OSs handle this situation by providing utilities under the desktop manager toolkit (such as KDE under Linux), mediad under Irix, and autodiskmount under MacOS X. Under Solaris, automatic detection of the media is limited to the CD-ROM device. The Solaris File Manager accomplishes this with a combination of a daemon (vold) and a configuration file (/etc/vold.conf), which specifies the actions to be taken for various removable devices and file system types. For floppy disks, Volume Manager is unable to detect the presence of new disks and must be informed that a new disk is present. This is accomplished by invoking the /bin/volcheck command. Volume Manager always mounts floppy disks under the /floppy directory it controls. CD-ROMs are likewise mounted under the /cdrom directory.

Creating and Mounting Configuring Volume Manager
Changing the actions taken and devices under control of Volume Manager is a simple matter of modifying the /etc/vold.conf file. # # Volume Daemon Configuration file # # Database to use (must be first) db db_mem.so # Labels supported label dos label_dos.so floppy label cdrom label_cdrom.so cdrom label sun label_sun.so floppy # Devices to use use cdrom drive /dev/dsk/c0t6 dev_cdrom.so cdrom0 use floppy drive /dev/diskette dev_floppy.so floppy0 # Actions insert /vol*/dev/diskette[0-9]/* user=root /usr/sbin/rmmount insert /vol*/dev/dsk/* user=root /usr/sbin/rmmount eject /vol*/dev/diskette[0-9]/* user=root /usr/sbin/rmmount eject /vol*/dev/dsk/* user=root /usr/sbin/rmmount notify /vol*/rdsk/* group=tty /usr/lib/vold/volmissing -c # List of file system types unsafe to eject unsafe ufs hsfs pcfs The lines beginning with a pound sign (#) are considered comments and are used here to help delineate the various sections of the configuration information. The first two sections, beginning with the comments Database and Labels, describe the database routines and disk label types Volume Manager recognizes. These two sections should not be modified. “Devices to use” Section The third section, marked by the comment Devices to use, lists the names and types of the removable media devices Volume Manager should monitor. Each line in this section starts with the keyword use, as follows. use cdrom drive /dev/dsk/c0t6 dev_cdrom.so cdrom0 The use keyword is followed by the type of device, either CD-ROM or floppy, and the keyword drive, as follows. Following the device type is the OS name for the device. Note that the CD-ROM device name specifies only the first five characters of the full special device name. Because Volume Manager will monitor and mount all available slices it finds on a CD-ROM disk, the only information items needed are the specific controller and target portions of the device name. Following the special device name is the name of the shared object used to manage the device. This must match the device type specified (e.g., if the device type is cdrom, the shared object must be dev_cdrom.so). Finally, the symbolic name used in the /device directory is listed. The first device of a given type has a 0 (zero) appended to its name, whereas the second is appended with a 1, and so on. For instance, a second CD-ROM drive located at target 5 on the built-in SCSI controller would be placed under Volume Manager control by adding the following line to the devices section of the vold.conf file. use cdrom drive /dev/dsk/c0t5 dev_cdrom.so cdrom1 Actions Section The next section, which begins with the comment Actions, specifies the actions to be taken when certain events occur. The basic events are the insertion of media into a drive (insert), removal of media from a drive (eject), and notification of problems (notify). An example entry in the actions section follows. eject /vol*/dev/diskette[0-9]/* user=root /usr/sbin/rmmount Entry Content Each line lists an event followed by a regular expression. When an event occurs, each line that begins with the name of the event (insert, eject, or notify) is checked. If the volume on which the event occurs matches the regular expression, the remainder of the action line comes into play. The remainder of this line includes the name of the user or group identification to be used to run the listed command with the listed arguments. In the previous example line, when the eject event occurs and the volume matches the regular expression /vol*/dev/diskette[0-9]/*, the command /usr/sbin/rmmount would be run with the root user permissions.

Creating and Mounting The rmmount.conf Configuration File
The /usr/sbin/rmmount command has its own configuration file named /etc/rmmount.conf. Although not often modified, this file allows the specification of additional actions to occur when a disk is mounted. A common use of this feature is to allow CD-ROMs mounted by Volume Manager to be automatically shared, or made accessible to other workstations on the network via NFS. To accomplish this, a share line is added to the bottom of the /etc/rmmount.conf file as follows. share cdrom* This line would share any CD-ROM mounted by Volume Manager without any restrictions. To control access the administrator can add options to the share line in a form similar to the share command. The lines beginning with a pound sign (#) are considered comments and are used here to help delineate the various sections of the configuration information. The first two sections, beginning with the comments Database and Labels, describe the database routines and disk label types Volume Manager recognizes. These two sections should not be modified. “Devices to use” Section The third section, marked by the comment Devices to use, lists the names and types of the removable media devices Volume Manager should monitor. Each line in this section starts with the keyword use, as follows. use cdrom drive /dev/dsk/c0t6 dev_cdrom.so cdrom0 The use keyword is followed by the type of device, either CD-ROM or floppy, and the keyword drive, as follows. Following the device type is the OS name for the device. Note that the CD-ROM device name specifies only the first five characters of the full special device name. Because Volume Manager will monitor and mount all available slices it finds on a CD-ROM disk, the only information items needed are the specific controller and target portions of the device name. Following the special device name is the name of the shared object used to manage the device. This must match the device type specified (e.g., if the device type is cdrom, the shared object must be dev_cdrom.so). Finally, the symbolic name used in the /device directory is listed. The first device of a given type has a 0 (zero) appended to its name, whereas the second is appended with a 1, and so on. For instance, a second CD-ROM drive located at target 5 on the built-in SCSI controller would be placed under Volume Manager control by adding the following line to the devices section of the vold.conf file. use cdrom drive /dev/dsk/c0t5 dev_cdrom.so cdrom1 Actions Section The next section, which begins with the comment Actions, specifies the actions to be taken when certain events occur. The basic events are the insertion of media into a drive (insert), removal of media from a drive (eject), and notification of problems (notify). An example entry in the actions section follows. eject /vol*/dev/diskette[0-9]/* user=root /usr/sbin/rmmount Entry Content Each line lists an event followed by a regular expression. When an event occurs, each line that begins with the name of the event (insert, eject, or notify) is checked. If the volume on which the event occurs matches the regular expression, the remainder of the action line comes into play. The remainder of this line includes the name of the user or group identification to be used to run the listed command with the listed arguments. In the previous example line, when the eject event occurs and the volume matches the regular expression /vol*/dev/diskette[0-9]/*, the command /usr/sbin/rmmount would be run with the root user permissions.

Creating and Mounting Mounting Non-ufs File Systems with Volume Manager Volume Manager is also able to handle file system types other than ufs. For instance, inserting an MS-DOS-formatted floppy and using File Manager or the volcheck command results in the disk being mounted under the /floppy directory on a mount point that bears the floppy volume name. Starting and Stopping Volume Manager UNIX makes it possible to disable Volume Manager and work directly with the CD-ROM and/or floppy drive. To disable Volume Manager, invoke the /etc/init.d/volmgt script with the stop option. To restart Volume Manager, invoke the /etc/init.d/volmgt script with the start option. The lines beginning with a pound sign (#) are considered comments and are used here to help delineate the various sections of the configuration information. The first two sections, beginning with the comments Database and Labels, describe the database routines and disk label types Volume Manager recognizes. These two sections should not be modified. “Devices to use” Section The third section, marked by the comment Devices to use, lists the names and types of the removable media devices Volume Manager should monitor. Each line in this section starts with the keyword use, as follows. use cdrom drive /dev/dsk/c0t6 dev_cdrom.so cdrom0 The use keyword is followed by the type of device, either CD-ROM or floppy, and the keyword drive, as follows. Following the device type is the OS name for the device. Note that the CD-ROM device name specifies only the first five characters of the full special device name. Because Volume Manager will monitor and mount all available slices it finds on a CD-ROM disk, the only information items needed are the specific controller and target portions of the device name. Following the special device name is the name of the shared object used to manage the device. This must match the device type specified (e.g., if the device type is cdrom, the shared object must be dev_cdrom.so). Finally, the symbolic name used in the /device directory is listed. The first device of a given type has a 0 (zero) appended to its name, whereas the second is appended with a 1, and so on. For instance, a second CD-ROM drive located at target 5 on the built-in SCSI controller would be placed under Volume Manager control by adding the following line to the devices section of the vold.conf file. use cdrom drive /dev/dsk/c0t5 dev_cdrom.so cdrom1 Actions Section The next section, which begins with the comment Actions, specifies the actions to be taken when certain events occur. The basic events are the insertion of media into a drive (insert), removal of media from a drive (eject), and notification of problems (notify). An example entry in the actions section follows. eject /vol*/dev/diskette[0-9]/* user=root /usr/sbin/rmmount Entry Content Each line lists an event followed by a regular expression. When an event occurs, each line that begins with the name of the event (insert, eject, or notify) is checked. If the volume on which the event occurs matches the regular expression, the remainder of the action line comes into play. The remainder of this line includes the name of the user or group identification to be used to run the listed command with the listed arguments. In the previous example line, when the eject event occurs and the volume matches the regular expression /vol*/dev/diskette[0-9]/*, the command /usr/sbin/rmmount would be run with the root user permissions.

Summary This chapter focused on the mass storage subsystem, one of the most critical subsystems. Topics included how to install a new disk drive, and formatting and partitioning a disk drive. Local file systems and their relationships to the UNIX file tree constitute a basic building block of a UNIX system. Understanding how file systems are created, mounted, checked, and tuned enables the administrator to effectively manage corporate disk space. More importantly, understanding how to mount, create, and unmount file systems on an active system can result in minimization of down-time for corporate users.

Summary The administrator should be able to Recognize basic disk components. The administrator should understand basic disk geometry. The administrator should understand partitioning and formatting. The administrator should recognize advantages and disadvantages of SCSI, IDE, and alternative disk systems. The administrator should recognize similarities and differences in popular Windows and UNIX file system structures. The administrator should understand how to create a file system. The administrator should understand how to make a file system available.

Serial Ports Chapter 9

Chapter Goals Understand serial port terminology.
Understand serial port capabilities. Understand serial port signals. Understand serial port configuration Understand serial port management. Understand modem connections and setup. Disabling serial port services. Understand new-technology serial ports.

Serial Ports Serial Ports
Serial ports are universal I/O ports. They are available on almost every computer. Serial ports are slow, but they are flexible. Serial ports can be used for terminal connections, printer connections, network connections, modem connections, keyboards, mice, and other input/output devices.

Serial ports use standard pin-outs for the connectors. The most common of these standard is known as RS-232. Proposed by the Electronic Industries Association (EIA). RS stands for Recommended Standard. RS-232 defines the pin-outs of the connectors and the voltage levels allowed on each pin of a serial port connection. RS-232 is functionally identical to the CCITT V.24/V.28 standards. RS-232 defines two types of signals; Data signals, and flow-control signals.

The RS-232 standard defines how the flow control signals interact to manage the flow of data across a connection. The full functionality of the RS-232 standard is rarely supported, as several of the signals are not required for simple communications connections. Traditional RS-232 uses 22 gauge stranded, twisted-pair cable. RS-232 signal voltages are defined to be +/- 12 volts DC. RS-232 connections terminate in a 25 pin D-connector (also known as a DB-25). The computer has the receptacle, while the cable has a plug. According to the standard, RS-232 will drive a 50 foot cable at 9600 baud.

Serial Ports Newer standards have emerged since RS-232 became the standard. RS-422/RS-423 use lower signaling voltages (+/- 5 volts DC) , and can drive longer lines. RS-422 is electrically compatible with CCITT recommendation V.11. RS-423 is electrically compatible with CCITT recommendation V.10. RS-449 is the standard which defines the pin-outs and connector characteristics for the RS-422/RS-423 standards. MOST RS-422/RS-423 implementations will connect directly to RS-232 devices and function properly.

Serial Ports RS-422 uses differential line drivers, and can drive several kilometers of cable. RS-423 uses single-ended line drivers and can drive up to a kilometer of cable. All of these standards use the same signals, so we will focus most of our discussion on the RS-232 standards.

Serial Ports RS-232 defines two cabling configurations: DTE (Data Terminal Equipment) and DCE (Data Communications Equipment). These cabling configurations determine which signals a device expects on what pins. Most computers, printers, and terminals are DTE equipment. Modems are DCE equipment. Cables for terminals connections are different from the cables used for modem connections!

Serial Ports

Serial Ports Although 25 pins are defined, many devices only use a small subset (4 to 9 pins). These devices require a software generated carrier signal.

Serial Ports Devices which provide for limited modem control use 9 pin connections.

Serial Ports Hardwired connections generally use a straight-through connection.

Serial Ports Some devices require a null-modem cable. This cable fools the device at each end on the link into thinking it is receiving the proper modem control signals, while in fact each device is generating it’s own modem control signals.

Serial Ports Some manufacturers have come out with alternate connectors for use with RS-232 connections: Apple uses a Mini-Din 8 connector, PC’s use DB-9 connectors, and some patch panels and other serial equipment use telephone style RJ-45 connectors.

Serial Ports Working With Serial Devices
When dealing with serial devices there are several complicating factors: You must set the communication speed (baud rate) of the device and the serial port. You must set the correct form of parity checking on the device and the serial port. You must set the number of stop bits to be used on the device and the serial port. You must set the word length on the device and the serial port.

Serial Ports Terminal Setup (Software)
The built-in terminal devices on a UNIX workstation are usually /dev/ttya (/dev/term/a) and /dev/ttyb (/dev/term/b). The modem control equivalents of ttya and ttyb are /dev/cua0 /dev/cua1. For any serial connection you must set up certain system parameters: You must tell the system to listen for logins on a terminal port. Dial-up modems listen for logins, but they must also monitor modem control signals to control the status of the link. Dial-out modems require setup information in /etc/remote so the tip and cu commands know how to talk to the modem.

Most terminals are used as login devices by the users. The sequence of events to start up a login session are: User enters login name at the getty prompt. Getty executes login login requests a password, and confirms it against /etc/passwd. login prints the message of the day from /etc/motd. login runs a shell and sets the TERM variable. The shell executes the appropriate startup files for the user. The shell prints the UNIX prompt and waits for input.

Serial Ports Managing Terminals 2|std.9600|9600-baud::sp#9600:
When the user logs out, init takes over and starts a new getty process. Getty reads configuration information from /etc/ttytab (BSD) or /etc/inittab (ATT) /etc/ttytab contains entries which specify the terminal port, the program to run on that port, the terminal type connected to the port, {on|off} and possibly [secure]. ttya “/usr/etc/getty std.9600” wyse50 on The getty program checks /etc/gettytab to determine what the “std.9600” entry means, and sets the line disciplines appropriately. 2|std.9600|9600-baud::sp#9600:

Serial Ports Managing Terminals
In the ATT model, getty uses the /etc/inittab file to determine how to set the serial port. The /etc/inittab file consists of entries with the format id:run-levels:action:process. A typical entry might be: 11:234:respawn:/etc/getty tty The getty program consults the /etc/gettydefs file to determine how to set the port disciplines: 9600# B9600 HUPCL # B9600 SANE IXANY HUPCL #login: #4800 The format of the entries is: label#initflags#finalflags#prompt#next

Serial Ports Managing Terminals The SAF allows you to
The Service Access Facility (SAF) - is one method for managing serial devices under Solaris. It is a suite of commands which interacts with the serial device driver to allow the system administrator to configure the port hardware, and the port monitor software. The SAF allows you to Manage and troubleshoot TTY devices Manage and troubleshoot network print service requests. Manage and troubleshoot the Service Access Controller. Add and manage “listen” port monitor services. Add and manage ttymon port monitor services.

The SAF is not a single program; it is a suite of programs and background processes which control other programs which do all of the work. The top-level SAF program is the Service Access Controller (SAC). The SAC is initialized at system boot. It is started by the scripts in the directory /etc/init.d. The SAC initializes the system environment by interpreting the /etc/saf/_safconfig script. This script allows the system administrator to customize the serial port parameters for the machine.

After the environment is set up, the SAC interprets the /etc/saf/_sactab file to start and customize the port monitors. Each port monitor is spawned as a new process. The SAC maintains control of these processes, and is therefore the parent process. Each child process started by the SAC invokes the appropriate /etc/saf/port_monitor/_config script to customize it’s own environment and start any processes required to enable the login process.

Solaris implements two port monitors; ttymon, and listen. ttymon is the program which monitors the serial ports, and directs data to/from the ports to the correct destination. The ttymon command uses the definitions in the /etc/ttydefs file to set line disciplines and baud rate for each port. Once the line disciplines are set, the ttymon hands control of the port over to the login process.

Serial Ports

The sacadm command is used to administer the SAC. sacadm allows the system administrator to add/remove port monitors, start/stop port monitors, enable/disable port monitors, install/replace configuration scripts, install/replace port monitor configuration scripts, and print port monitor information. sacadm accepts input from stdin, and uses this input to control the SAC. Non-privileged users may use sacadm to request the status of print jobs, port monitors, and system configuration scripts.

Serial Ports

The ttyadm command is used to format ttymon administrative information for interpretation by the sacadm and pmadm commands. The ttyadm command does not work with listen monitors.

Listen is the port monitor program which monitors the network for service requests from other hosts. Listen monitors may also manage some network services which are not controlled by the inet facility. For example the network printer services are controlled by the listen port monitor. The sacadm, pmadm, and nlsadmin commands are used to configure/administer the listen port monitor. We will discuss the listen port monitor in more detail in the section on printers, and again in the networking section.

The Service Access Controller

Admintool is another method for managing serial devices. It is a point and click GUI which interfaces to the SAF commands for you. Because admintool relies on the command line form of the commands, and sometimes you want to do non-standard things, it is best to discuss how to use the command line commands. Once we understand them, we may never use them again...but understanding them is important!

In order to connect a hardwired terminal to the system we must first: Set up the port monitor software. As root, use the sacadm command to enable login services on the port. NOTE: You must use the bourne shell to execute the sacadm commands, or they may fail or provide unexpected results. Configure the terminal. Test the setup to determine if the setup is correct.

To configure the software, first we check to see if a ttymon is already running on the port: sacadm -l -t ttymon If no ttymon is running, set one up: sacadm -a -p zsmon -t ttymon -c /usr/lib/saf/ttymon -v ‘ttyadm -V’ NOTE: The string zsmon is known as the Port Monitor Tag (PMTAG)

Check to see if a service running on the zsmon port monitor: pmadm -l If a service is running, remove it (Note, the SVCTAG is generally the port name such as ttya. The preceding command will tell which SVCTAG to use here). pmadm -r -p (PMTAG) -s (SVCTAG) Set the port line disciplines and start login for the terminal: pmadm -a -p zsmon -s (SVCTAG) -i root -fu -v \ ‘/usr/sbin/ttyadmin -V’ -m “‘/usr/sbin/ttyadm -l BAUDRATE \ -p “MESSAGE” -d /dev/term/(PORT) -T vt100 -i \ ‘terminal disabled’ -s /usr/bin/login -S -y’”

Serial Ports The stty command is a utility that allows the user, or administrator, to set specific terminal port characteristics. Typical uses of the stty command include setting the baud rate, size of the display, parity, and special characters (erase character, interrupt character, redraw character, and so on). stty also allows the user to view the current settings of these (and other) parameters. Viewing Port Settings Using stty The invocation of stty that allows the user to view port settings ison of: stty a or stty all or stty everything The second command lists several variants, because each version of UNIX seems to have its own flag to cause stty to display this information.

Serial Ports Terminal Problems and Solutions
Most terminal problems are caused by one of: You forgot to make init re-read the configuration files. Typing kill -1 1 (as root) will cause this to happen. Forgot to set soft carrier mode on 3 wire connections. Forgot to use the cu device for modem control connections. Wrong type of cable (wrong pinout, null-modem instead of straight through, bad cable) Port Monitor incorrectly configured. Wrong line discipline information at one end of the link (parity, baud rate, stop bits). Bad port/terminal

Serial Ports Terminal Problems and Solutions
Sometimes a program will wedge a terminal. Vi, and any other screen oriented software can exit non-gracefully and cause the terminal to be left in a strange state. Many times you can recover from this. On BSD systems, type reset On ATT systems, type stty sane Sometimes the terminal will not accept a <CR>, so you have to use <LF> or CTRL-J after the commands to get any action from the system.

Modems Modem Control Signals Hard and Soft carrier
UNIX systems expect to see the Data Carrier Detect signal (pin 8) active (+5VDC) when a device is connected and ready to communicate. If the hardware actually expects pin 8 to be active, then the device is said to be using “hard carrier”. Many systems employ software which pretends that the DCD signal is active. These systems are using “soft carrier”. Soft carrier simplifies the wiring, and is often adequate for terminal connections. Soft carrier is not adequate for modem connections, or for many printer connections.

Modems Modem Control Signals
The CTS/RTS signals are used to control data-flow between the devices. Flow control is essential for modems, and is also very useful for many printers. Many printers have limited data buffers. These printers have to tell the computer to stop sending data while they drain their buffers. Some printers use X-ON/X-OFF (Control-S, Control-Q) to signal the computer when to stop/start sending data. This method is not always reliable. Most printers prefer to use use the modem-control signals to control data-flow.

Modems Modem Control When a device is wired for modem control operation, the CTS/RTS signals define when each device may send data to the other. If DCD is true, and: a device sets it’s Clear-To-Send signal to true, then it is signaling the other end of the connection that it is ready to receive data. a device sets it’s Request-To-Send signal to true, it is telling the device at the other end of the connection that it is ready to send data. If the Data Carrier Detect signal transitions to false, the carrier has been lost, so the system should log the user out, and the connection should be terminated.

Modems Managing Modems
Modems take a little more setup information in the way of configuration files. The /etc/remote file contains information used for dial-out connections by the tip and cu programs. A typical entry might be: dial9600|9600 Baud \ Hayes:dv=/dev/cul0:br#9600:cu=/dev/cul0:at=hayes:du: systema:pn= :tc=dial9600 The /etc/phones file contains entries of the form: monet 8,,510, ,,,,xxxx-xxx cc

In order to connect a bi-directional modem to the system we must first: Set the PROM monitor to enable modem control signals. eeprom ttya-ignore-cd=true eeprom ttya-rts-dtr-off=true Connect the modem to the port with a straight through cable. DO NOT use a null-modem cable, nor should you cross any of the pins in the modem cable.

Modems Managing Modems Set up the port monitor software.
As root, use the sacadm command to enable login services on the port. NOTE: You must use the bourne shell to execute the sacadm commands, or they may fail or provide unexpected results. To configure the software, first we check to see if a ttymon is already running on the port: sacadm -l -t ttymon If no ttymon is running, set one up:

sacadm -a -p zsmon -t ttymon -c /usr/lib/saf/ttymon -v ‘ttyadm -V’ NOTE: The string zsmon is known as the Port Monitor Tag (PMTAG) Check to see if a service running on the zsmon port monitor: pmadm -l If a service is running, remove it (Note, the SVCTAG is generally the port name such as ttya. The preceding command will tell which SVCTAG to use here). pmadm -r -p (PMTAG) -s (SVCTAG) Set the port line disciplines and start login for the modem:

Modems Managing Modems Configure the modem.
pmadm -a -p zsmon -s (SVCTAG) -i root -v \ ‘/usr/sbin/ttyadmin -V’ -fu -m “‘/usr/sbin/ttyadm -p \ “MESSAGE” -d /dev/term/(PORT) -s /usr/bin/login -l \ BAUDRATE -b -S n -m ldterm,ttcompat’” -y “dial-in/out \ on serial port” Configure the modem. Test the setup to determine if the setup is correct.

Modems Using Dial-in Passwords
Some versions of UNIX provide a dial-in password, an additional aid for defending dial-in terminal access. The dial-in password is controlled by two files, /etc/dialups and /etc/d_passwd. 1. Create /etc/dialups. This file contains a single entry per line with the path of each dial-in modem line (e.g., /dev/term/a). 2. Create /etc/d_passwd. This file contains a single entry for each possible shell a dial-in modem user might use. The following is a sample d_passwd file. /usr/lib/uucp/uucico: passwd-goes-here: /usr/bin/csh: passwd-goes-here: /usr/bin/ksh: passwd-goes-here: /usr/bin/sh: passwd-goes-here: 3. Insert an encrypted password for each shell in place of the passwd-goes-here strings shown previously.

PPP A host can be a PPP client or a PPP server. If your host is dialing out to another server, your host is a PPP client. If other hosts are dialing in to your system, your host is a PPP server. Most operating systems provide tools for implementing both client and server sides of PPP. The process a user goes through to establish a PPP link to a typical PPP server includes the following steps. Dial into the server’s modem. Log in using a valid user name and password pair. At the shell prompt, issue the command ppp to start PPP on the server. Start PPP on the user’s system.

PPP Windows Point-to-Point Protocol (PPP)
The Microsoft PPP protocol is the Windows PPP client. The PPP protocol setup is part of the Network and Dialup connections control panel. The selections under this wizard are somewhat limited; the dial-up line can be a terminal-style dial-up, a PPP dial-up, or a SLIP dial-up line. The NETWORK tab of the dial-up control panel allows you to select between the PPP and SLIP connections.

PPP Linux includes the following utilities, used to configure the client end of the PPP link. Kppp: The kppp utility is a PPP setup and dialer tool used under the KDE desktop manager. WvDial: A PPP driver for Linux. This driver was designed with an emphasis on simplicity. RP3: Short for RedHat PPP. RP3 includes a “wizard” interface to guide the user through the setup/configuration of the PPP link. Linuxconf: A generalized tool for configuring and managing your Linux machine. Linuxconf includes a utility to help configure PPP.

New Serial Ports Two new serial bus technologies have recently joined the mainstream offerings on computer systems: the Universal Serial Bus (USB) and FireWire interfaces. These two interfaces are high-speed system interconnects that support devices beyond modems and terminals. Both interfaces allow you to add disks, tapes, and network adapters to the system via the USB/FireWire ports.

New Serial Ports USB Interface
The intent of the USB architecture is to provide a replacement for the aging serial and parallel ports on existing computers. The traditional serial bus requires an IRQ, I/O space, and memory space for each port, and only one device can plug into each port. USB uses one IRQ no matter how many devices are in use. USB cables consist of four wires. Two of the wires supply voltage and two are data signal wires. The bus operates at either 12 megabits per second or 1.5 megabits per second, depending on the attached device. The devices tell the bus what their speed is through the voltage cables. High-speed devices shift the positive voltage lead while slow-speed devices shift the negative voltage.

New Serial Ports FireWire Interface (IEEE 1394)
The IEEE-1394 Serial Interface (FireWire) is a versatile, high-speed, low-cost method of interconnecting a variety of personal computer peripherals and consumer electronics devices. The IEEE-1394 bus was developed in 1986 as Apple Computer’s alternative to the traditional COM ports, which had been used to connect printers, modems, external fixed-disk drives, scanners, and other peripherals to PCs. The FireWire interface delivers up to 200 Mbps of data/control information. Versions that support 400 Mbps and a 1.2-Gbps (gigabits per second) are under development.

Reference Good Reference for serial ports and Unix:

Summary Serial ports are low-speed communication channels provided by most computer systems. The hardware and signaling used on these ports are defined by standards, but the software employed by different operating systems is not. This often leads to confusion on the part of an administrator that has to deal with serial ports on many operating environments. This chapter examined generic serial port standards and terminology, as well as the configuration and management utilities supplied by Windows and several flavors of UNIX operating systems. Also covered were configuration and management procedures for using serial ports under the point-to-point network protocol. The chapter also examined how to disable serial port services on traditional serial ports. Whereas traditional serial ports are still used on most computer systems, two new serial port offerings allow users to connect an entirely new set of devices to the system using serial connections. The Universal Serial Bus (USB) and FireWire (IEEE1394) busses are both standards-driven serial interconnect bus specifications.

User Accounts Chapter 10

Chapter Objectives Understand problems associated with the creation of user accounts. Understand tasks required to add a new user account. Understand security issues related to user accounts. Recognize tools available for managing user accounts.

Users Many System Administrators rate tasks they have to perform on a “headache” scale. (How nasty will the headache be when I have to do task?) Installing and OS is usually a light headache. Installing applications is usually a light headache. Patches are usually a light headache. Account maintenance is generally a medium sized/nasty headache...

Users So far, we have discussed:
Booting/Halting a system Installing an OS Customizing/Patching the OS Installing applications License managers Filesystems Processes By now we should have a working system. All we need is users...

Users Users - background information
There are several things to consider before attempting to create/install user accounts on a system. Creating login names How is a login constructed? Users last name? Users first name? Combination of names? Random string? Alphanumeric string? It is best if the site has a policy about login names. Otherwise users will request login names that may not be acceptable (to management, society, ...).

Users Users - background information Assigning a homedir
On large systems there may be many “user” directories. The system administrator needs to think about how users are distributed across these file systems. Space requirements Project/Work Unit Association Other considerations (special needs)

Users Users - background information Creating UID’s
Each user must have a unique user-id. Most Unix systems use integers in the range of Are there special (reserved) userids? What happens at a large company/university where there are more than employees? Are UID’s reused? For example, if an employee leaves the company, is their userid assigned to the next person hired in?

Assigning a shell Shells are a very personal choice. But the administrator has to assign some shell program to each user. sh - standard with almost every UNIX csh - standard with almost every UNIX bash - Standard with Linux tcsh - Popular, but not generally shipped with system. ksh - used by many install programs

In addition to the items above, the administrator may elect (or be forced) to set constraints like: What workstations can the user access What hours can the user access the workstation Account expiration date How often user must change their password What are acceptable passwords

Format of password file (Unix) The Unix password file conforms to a very strict format: USER:PASSWD:UID:GID:GECOS:HOMEDIR:SHELL If the password file format is incorrect, one of the following situations may occur: Nobody listed after the error can login. Nobody can login The password file is automatically truncated by the system to remove the error.

Users Password file fields User - the login name assigned to the user.
Password - may be one of the following: NP - No password assigned [xX] - Look in some alternate location encrypted password UID - the UID assigned to this user GID - the login group this user belongs to Users may be in other groups (see /etc/group)

Users Password file fields
GECOS - This field is a list of comma separated informational items related to this user. Standard format is: Full name Office Phone Comments

Users Password file fields Sorting the password file
Homedir - the home directory assigned to this user shell - the shell program assigned to this user Make sure it is listed in /etc/shells! Sorting the password file Some sites want names alphabetically. Problem: What happens if an error occurs somewhere before the letter “r” in the password file? Some sites want ascending UID’s. Not real convenient when searching for a username. Some sites have several password files, and use some tool to create password files for individual systems.

Users The principle method by which an operating system determines the authenticity of a user is by a password. Good passwords are essential to the security of all operating systems. Choosing passwords, educating users in the use of passwords, and choosing and employing one or more tools to enhance password security are tasks a sysadmin will face when creating user accounts.

Users Both Windows and UNIX systems employ reusable passwords as their default. Reusable passwords have several problems. First, they are vulnerable, either through manual or automated brute force attacks, to discovery if unchanged for long periods of time.. Reusable passwords are vulnerable to their own quality; poorly chosen passwords are more easily guessed. If the user accesses the system using an insecure connection such as telnet or ftp, the user’s password is transmitted over the connection in clear text, which is easily intercepted if an attacker is listening.

Users The first approach to improve password securiy is to educate the users of your systems to the dangers of reusable passwords. Education on choosing good passwords and encouragement to change them periodically is universally applicable to all operating systems. Good password construction techniques include assembling passwords from words separated by punctuation characters or numbers, or assembling a password using the first letter of each word in a phrase of the user’s choosing. Semester breaks, seasonal changes, and holiday breaks can help provide cues to encourage periodic password changes.

Users Password aging (or password expiration) is another method to improve password security. The aging process allows the system manager to enforce the practice of changing account passwords on a regular basis. The downside to password aging is the psychological factor. Some users dislike changing passwords. Being asked to change with no warning may contribute to a user choosing a simpler, easily guessed password, or simply entering a new password and then changing back to the old password immediately afterward. Password aging is most effective when the account user understands the reasons for periodically changing a password and the elements of a good password, and is given a chance to choose a good password.

Users Other features present in some UNIX variants are incorrect password attempt counters and account inactivity timers. These can be employed to reduce the chances of success by an attacker guessing a user’s password or of an old unused account being exploited to gain access to a system. A password attempt counter records failed attempts to provide the system with a password. When a user attempts to log in, the number of failed password attempts is checked against a set limit. The user account is disabled if the limit is exceeded. Likewise, an inactivity timer records the last time an account was used.

Users In the case of the inactivity timer, when a user attempts to log in, the length of inactivity for the account is compared to a set limit and the account is disabled if it has been inactive for longer than the limit. Both of these tools have the downside of preventing access by valid users and of adding additional work for the system administrator as he spends time resetting password attempt counters or inactivity timers triggered by the forgetful or infrequent user.

Users The long-term solution to the problems of reusable passwords is passwords that are used just once and not used again. These one-time passwords make use of a shared secret typically held on a secure authentication server and a token held by the user, typically a small calculator or a program on a personal digital assistant (PDA), such as a Palm Pilot. Instead of requesting a password when accessing a system, under one-time passwords the system responds to a log-in request with a challenge in the form of a string of numbers and letters.

Users This string is entered into the token that produces another string, the response. The response is entered instead of the password to gain access. Both the challenge and the response are a mixture of the shared secret and a continually changing value, usually the current date and time, ensuring that the same combination of challenge and response are never used more than once.

Users This sophisticated and secure scheme is not without its own problems. None of the Windows or UNIX variants seem to come with one-time passwords built in. They must be added to the system as a separate product. All users making use of the system will be required to carry a token with them, with the resulting problems of loss and damage to the token and the frustration to the user when they are unable to gain access.

Users Alternative password token systems are also available.
Physical devices such as a smart card or dongle that carry authentication information or provide challenge/response authentication. The devices are read via special readers (smart cards) or are attached to a system via a connection such as a USB port (dongle). Such devices are generally used in highly secure systems for which the cost of the additional hardware for every user can be justified. Another technique is the use of biometric information such as the visual pattern of a fingerprint or the blood vessels in the retina.

Users This information is read from the person’s finger or eye via a special-purpose reader. Although believed to be very secure, biometrics suffer from problems such as how account revocation is performed, as the information being used for authentication is a permanent feature of the user. As with smart cards and dongles, biometric authentication is only seen in situations for which the cost of the additional hardware can be justified.

Users Under NT Workstation, there is a great point/click interface called the User Manager. User Manager lets the administrator add one account at a time on individual computers. User Manager lets the administrator force password changes, disable the user, give the user privileges, move the user to a new directory, ... How would an administrator (easily) add 20 accounts with User Manager? Under NT Server (or any system participating in an NT domain) the application is called User Manager for Domains. Same as user manager, but it works with a domain wide account database (registry).

Users UNIX suffers from the same account management design problems.
The standard tools for adding users are not set up to deal with “mass” account changes. The “old” method for adding/changing user information is to edit the /etc/password file. vipw is provided on some versions of UNIX so the person doing the editing can’t do stupid things. Solaris did away with vipw, so you have to use some other text editor if you plan to change the password file manually. Solaris provides admintool which can be used like the NT User Manager to add/change/delete one user at a time.

Users Solaris provides an extended version of admintool which can be used like the NT User Manager for Domains to add/change/delete accounts on all systems (one user at a time). Problem: How would the administrator install several hundred (or thousand) accounts on several hundred (or thousand) computers with these systems? A few possible answers: very carefully very crabbily they wouldn’t they would find a better way

Users To start up admintool, login as root, start OpenWindows, and type # admintool

Users Account Maintenance Packages
Several organizations have created account maintenance packages. These packages attempt to solve one or more problems with the standard account installation tools. In lab we will examine a few of these tools: Sun Microsystems - YP (Yellow Pages) also known as Network Information Service (NIS). M.I.T. - Athena Service Management System Oregon State - Asmodeus Purdue University - ACMaint

Summary This chapter explored the user account.
Sysadmins must pay attention to many tasks as part of account creation. Site policies regarding user account names, rights, acceptable use, … Password security Disk management Automation of account creation process.

System Security Chapter 11

Chapter Objectives Recognize the seven common sense rules of system security Understand file, and account security. Understand the use of monitoring/auditing tools for system security. Recognize the symptoms of viri, trojans, and worms.

System Security Computer Security is an oxymoron!
UNIX was not designed with security in mind. UNIX was developed as a research tool, and openness is still one of the major advantages (and weaknesses) of UNIX.. Personal computers and their Operating Systems, were not designed with security in mind. They were developed as personal systems which would only be used by one user. 1 Security = Convenience

System Security Seven common sense rules of security:
Don’t put files on your system that are likely to be interesting to hackers or nosy employees. Trade secrets, personnel files, payroll data, election results, etc., must be handled carefully if they’re on-line. Reasonable security can be attained using compress and crypt on sensitive files. Plug holes that hackers can use to gain access to your system. Read bulletins from your vendor, the security mailing lists and Usenet News groups that provide patches for security holes.

Don’t provide places for hackers to build nests on your system. Hackers often break into one system and then use it as a base of operations to get into other systems. World-writeable anonymous ftp directories, group accounts, and accounts with poorly chosen passwords all encourage nesting activity.

Set basic traps on systems that are connected to the Internet. Tools such as tripwire, crack, SATAN, tcpd, and COPS will help to keep you abreast of infestations. Monitor the reports generated by the security tools. A minor problem that is ignored in one report may grow into a catastrophe by the time the next report is sent.

Teach yourself about UNIX system security. A number of high-priced security consultants will happily come to your site and instill terror in you and your management about the insecurity of your systems. They’ll explain that for only $50K they can make your site secure. Prowl around looking for suspicious activity. Investigate anything that seems unusual, such as odd log messages or changes in the activity of an account (more activity, strange hours, activity while the owner is on vacation).

System Security Account Security
Password security is one of the most important areas the system manager has to monitor. Many users chose poor passwords. Many other users have no password on their account. Most users resist changing their passwords. Most versions of UNIX have implemented some form(s) of password protection: Shadow password files. Password programs which require the user to change passwords periodically. password programs which prevent simple passwords.

One method which can increase account security is to use an authentication system such as Kerberos Kerberos uses DES encryption of “tickets” (much like an AFS token) to authenticate a user. Kerberos replaces the password program and sends encrypted passwords (or challenge results) over the network. Kerberos can be set up such that all data is encrypted on the network. Kerberos is becoming more popular, and is being included in more Operating Systems.

The best security tool at any site is an alert administrator. Watch for users logging in at odd hours, or logged in while they are on vacation. Watch for off-site logins by local users. Scan the password file to look for users with UID or GID of zero.

System Security Never put “.” in the root path. File Permissions
Once you have established reasonable access security for a system you need to look at the system binaries to ensure they are secure. Are there any world writeable directories on the system? Are there setuid or set gid programs on the system? Have the modify dates on system binaries changed inexplicably? Search path security must be a concern for root. Never put “.” in the root path.

System Security File Permissions
Once you make the system files secure, you have to look at what the users do with their accounts. Are the user home directories “locked up”? Many users leave their account mode 777 if you don’t force them to do otherwise. Do the users have setuid programs in their path? If the user is in multiple groups, are the group permissions set correctly?

System Security Data Encryption
One cheap method of providing security is to use some form of data encryption for sensitive files. crypt is standard on UNIX systems, but is easy to break. The standard UNIX passwords are encrypted with crypt. Linux/BSD use MD5 password encryption. One of the major flaws of crypt is that many strings may encrypt to the same encrypted value, hence password crackers don’t have to have exact matches of a password, just something that encrypts to the same value! If you use crypt, compress the data first. Compressed data is usually un-intelligible, so someone trying to de-crypt compressed data will have a harder time cracking the data.

System Security Data Encryption
DES encryption utilities are available in the United States. They provide a very good encryption method, but are very difficult to deal with (most Operating Systems do not provide nice methods of incorporating DES encryption). pgp - Pretty Good Privacy - uses a much better encryption method than crypt (and some say better that DES), but is sometimes cumbersome to use. It is easier to tie pgp into the Operating System than DES utilities..

System Security Single User Security
One of the biggest security holes on workstations is the ability of the user to boot the system into single user mode. Sun Workstations have implemented ROM monitor security that allows the administrator set up three levels of security: None - no Monitor security enabled. Command - requires password for certain monitor commands (examine memory, boot). Full - requires password for all commands. The password for the full and command modes is not the root password. This password is stored in the system EEPROM, and should be a different password from the root password.

System Security Single User Security
PC systems have started to add in hardware security features. On these systems the administrator can limit access to the CDROM, floppy, memory commands, etc. The administrator can also limit which devices can be booted, and require a password for commands much like the Sun monitor. MacIntosh systems rely upon software to provide security. Applications like At Ease implement a login manager which requires passwords, and allows the administrator to limit access to devices/directories. MacIntosh systems provide no hardware level security.

System Security Dialup Modems
Another large security problem on any computer is external access. This external access can be via dialup modems, or network connections. For systems with dialup modems, set passwords on the modems such that a user has to know the password before they get connected to the system. If passwords are not possible, implement call-back facilities. The user dials up, enters a code, they hang up, then the system calls them back. Monitor dialup usage!

System Security One of the easiest ways to monitor system security is to read the log files! Most versions of UNIX place logs in /var /var/log – maillog, syslog, messages, sshd, authlog, secure, and other log files contain important information. /var/adm – messages Windows uses the Event Viewer to view the system logs. Set the system to record everything, and use event viewer to peruse the logs. Better yet, get syslog for Windows!

System Security Security Tools
The System administrator can take security one step further by using several public domain tools to periodically scan passwords, system and user files looking for vulnerabilities: COPS - (Computer Oracle and Password System) checks file/directory/device permissions, monitors the password and groups files, monitors the system startup scripts and crontab files, and mails the administrator a report. crack - password cracking program. SATAN/SAINT - checks well-known security holes in system binaries, and tries many means of gaining access to systems. Nessus - New Satan-like scanner (more thorough). Nmap – port scanner.

System Security Security Tools
tcpd - a TCP wrapper that provides logging for many TCP/IP programs. TRIPWIRE - computes checksums for files, stores them in a database, then on subsequent runs checks to ensure the checksums have not changed. If checksum has changed the administrator get a report and can look at the files in question. tiger - another SATAN clone from Texas A&M courtney - yet another SATAN clone the hackers tools - from rootshell, bugtraq, 2600, l0pht, underground web sites.

System Security There are many audit tools available for free download. The Center for Internet Security offers tools to check Solaris, Windows, and Linux hosts, as well as routers for common security problems. The System Administration, Networking, and Security Institute (SANS) has several tools for system auditing, and step-by-step guides to follow to secure your systems. The CERT organization publishes guidelines for system security.

System Security Viruses (vira? viri? viru?)
Viruses have (until recently) been a pox upon personal computers and MacIntosh computers. Unix virus code is more difficult to produce. Why? UNIX has “permissions” required to write files. UNIX is a much more complicated OS than MacOS or DOS/Windows. Until Linux not many hackers had access to home UNIX systems. UNIX runs on several architectures, while MacOS and DOS only run on limited platforms. This makes machine code impractical for the virus programmer.

System Security Viruses (General)
A virus is a piece of code that attaches itself to other programs or files. A virus becomes completely dependent on that program or file. Each time you run the program or open the file, the virus code is executed. With each execution the virus code has a chance to propagate. Viruses spread from system to system when the code/files are shared between the systems.

System Security Viruses It propagates.
There are two general types of virus programs; malicious, and non-malicious. A non-malicious virus does not intend to cause any lasting damage to the computer system. It propagates. It may print messages on the screen. It may utter noises from the speaker. It does not include any code to intentionally do damage to the computer system.

System Security Viruses
A malicious virus makes a concentrated attempt to do damage to the computer system. It may format your disk drive. It may scramble the FAT table. It may remove random files. It may encrypt the data on the disk.

A virus is not a worm, nor is it a Trojan horse. A Virus is a parasitic piece of code. It attaches itself to other code/files on the system. It relies on that piece of code in order to propagate/operate. When that code is executed so is the virus code. This gives the virus code the opportunity to propagate, and to perform other actions. A worm is a piece of code that propagates itself to other systems, but the code does not attach itself to programs or files on the infected systems. Worms are stand-alone programs that do not rely on a “host” piece of code to propagate/operate.

A Trojan horse is a program that appears to do one thing, but in reality does something else. It does not attach itself to other code/files, and does not rely upon other code/files to propagate/operate. For instance a game program that removes all of your files (on purpose) would be a Trojan horse.

System Security PC Viruses
PC viruses usually infect files with .exe, .com, and .ovr extensions. These files usually contain executable code. The virus code sometimes infects the command.com file, the hard disk boot sector, the hard disk partition tables, or floppy disk boot sectors. Some virus code is memory resident code. It goes memory resident then sits and waits for other programs to be pulled into memory. When these programs are in memory the virus infects them. Some virus code goes to great lengths to hide itself...for instance the strings in the code are variably encrypted to keep virus scanners from finding the virus.

System Security PC Viruses How is a file infected?
A user runs a program that is already infected. The virus code is executed, and hunts other files to infect. When an uninfected file is found, the running virus will append a code segment to the uninfected file (in many cases it inserts virus code at the end of the main code section). Once the code is in place the virus (still running from another program at this point) will do one of the following to make the new code segment executable:

Some of the things that virus code has been known to do: Change a FAT entry each time the system is booted. Use a random number generator...if the random number generated is N, reformat the disk. Cause odd screen behavior (all the characters fall to the bottom of the screen). If the infected program is opened by a virus scanner, the virus moves itself to memory, disinfects the file, waits until the scanner is done, then re-infects the file. Draw a Christmas Wreath, write Merry Christmas, and play “Oh Tannenbaum” (if the date is between Thanksgiving and Christmas).

On the 16th execution of an infected file, pick a random disk sector and write goo to it. Change the order of bytes in database files as they are written to disk. Files look fine on infected systems, but are useless on virus-free systems. Delete the host program if it is run on Friday the 13th. Monitor keyboard input looking for certain strings. If a string is found a profanity is echoed to the screen (and sometimes placed in the file you are editing instead of the string you typed). Watch the INT 09h (keyboard interrupt). If a keystroke is recognized while the virus is active, replicate the keystroke (make it look like a bouncy key).

Scan infected files for the string Microsoft. If found, change it to MACHOSOFT. Draw a phallic symbol on the screen and cause it to “march” across the screen. Create directories (with profanities for the directory names) on the system disk. Flip the screen on a horizontal axis. Demand a password before you can execute any programs. Change disk writes into disk reads (or vice versa).

System Security PC Viruses Format the system disks.
Trash the FAT table. Halt the system. Crash the system. These days, most viri immediately begin attacking other hosts in an attempt to further propagate. Many current viri also carry Denial of Service (DoS) attack code, which may be used by the attacker at a later date to cause infected hosts to attack another site on the Internet.

System Security Microsoft Word (Macro) Viruses
Recently hackers have found a new way to spread virus code. Many Word Processors, Spreadsheets, and other productivity tools include a macro package. Many of these macro packages are actually based on the BASIC programming language. Hackers have learned how to embed a virus code segment into Microsoft Word documents. Every time the document is opened, the virus code is executed as part of the Macro facility startup code. Each invocation of Word infects the document you are editing.

System Security Macro Viruses
Macro viruses will work on UNIX systems if the person who creates them knows UNIX commands and how to access UNIX calls from BASIC. If you have Word Processors, Spreadsheets, or Productivity tools which have the Macro capabilities make sure to turn off the auto-macro execution.

Summary Securing the individual systems is the first step toward providing a secure environment. Defense in depth – security should be implemented in layers – like an onion. Account and password security are basics that should not be ignored. SUID/SGID commands are evil. Single User security needs to be monitored. Become familiar with the tools available to monitor/implement security on your systems. Understand how viri, trojans, and worms work.

Disks and File Systems II
Chapter 12

Chapter Goals Understand how to create a file system.
Understand how to make a file system available. Troubleshooting disks and file systems. Repairing file systems. Tuning file system performance.

On most UNIX systems, the default type of file system created by newfs is a ufs file system. Two notable exceptions are Linux, which defaults to an EXT2 file system, and Irix, which defaults to an XFS file system. The syntax for invoking the newfs command: # newfs [mkfs options] /dev/rdsk/c#t#d#s# Invoking newfs with the -N option causes newfs to display the basic parameters of the file system without actually creating it. The newfs command will display information about the new file system as it operates. The first line printed by newfs describes the basic disk geometry. The second line of output from newfs describes the ufs file system created in this partition. Cylinder groups are a concept introduced in the Berkeley UNIX Fast File system. Cylinder groups provide a method by which file blocks are allocated close together on the disk to improve performance. TIP: Varying the size of the cylinder groups is one way to tune the performance of a ufs file system. The final two lines of newfs output list the locations of the superblock backups. The superblock is the head of the file index node or inode information used by the ufs file system. The inodes are “used” by routines in the Solaris kernel to allocate, read, write, and delete files. Backup copies of these superblocks are created in the event a system crash, power failure, or other problem leaves the main copy of the superblock damaged.

How newfs Connects to mkfs
As previously mentioned, the newfs command is a front end to mkfs. The newfs command invokes mkfs to perform the actual creation of the file system on the target device. The mkfs command requires a long list of parameters. TIP: Use of the -v option flag with newfs will allow the administrator to see which parameters it passes to mkfs. Many file system parameters may be altered by using an option flag to newfs instead of manually invoking mkfs. For most applications, a detailed knowledge of the mkfs parameters is unnecessary; newfs makes proper choices for the parameters it passes to mkfs. It is possible to build a file system tuned to store a large quantity of small, frequently changing files, such as those found in the Usenet net-news system. Such a file system would require more index nodes or inodes than are provided by the default options used by newfs.

Mounting File Systems General Procedure for Mounting a File System
File systems can be mounted via several methods: manual mounting by invoking the /etc/mount command, mounting the file system at boot time via the /etc/[v]fstab file, or mounting via Volume Manager. General Procedure for Mounting a File System The general procedure for mounting a file system is as follows. 1. Format the disk drive. 2. Partition the disk drive. 3. newfs the partition. 4. Create a mount point for the file system. 5. Determine which method will be used to mount the file system (manual mount, [v]fstab mount, Automounter, or Volume Manager). 6. Mount the file system.

Mounting File Systems Mounting via the fstab
The [v]fstab file is used to mount file systems at boot time. The “v” is bracketed, as some versions of UNIX call this file /etc/fstab (primarily BSD UNIX), other versions of UNIX call this file /etc/vfstab (primarily System V UNIX), and a few versions of UNIX call this file /etc/checktab (HP/UX). This file is read by the /etc/mountall command when it is run as part of the system boot sequence. A quick way to add items to [v]fstab is to use the - p option to the mount command. It is also possible to add new file systems by editing the [v]fstab file and entering the required information manually. The [v]fstab file format may contain minor modifications on different variants of UNIX,. A tab or spaces separate the fields of this file. The following is a typical Solaris [v]fstab file.

Mounting File Systems #device device mount FS fsck mount mount
#to mount to fsck point type pass at boot options /proc - /proc proc - no - fd - /dev/fd fd - no - swap - /tmp tmpfs - yes - /dev/dsk/c0t3d0s0 /dev/rdsk/c0t3d0s0 / ufs 1 no - /dev/dsk/c0t3d0s6 /dev/rdsk/c0t3d0s6 /usr ufs 2 no - /dev/dsk/c0t3d0s5 /dev/rdsk/c0t3d0s5 /opt ufs 5 yes - /dev/dsk/c0t3d0s swap - no - /dev/dsk/c1t3d0s swap - no - Device to mount - Name of device to be mounted. Device to fsck - Raw device to be checked by the fsck utility. Mount point - Directory where the device should be added to the UNIX file tree. FS type - File system type. fsck pass - Number indicates the order which the file system will be checked. Mount at boot - Yes to cause file system to mount at boot. Mount options - Options to be passed to the mount command. Options are given as a comma-separated list following the -o flag (e.g., mount -o rw,quota). Some of the more common options for the mount command are. Quota - Activates the user disk quota system when the file system is mounted Ro - Mounts the file system read-only -F fstype - Mounts a file system of fstype -a - Mounts all file systems with “mount at boot” (in the vfstab file) set to yes -o - Uses specific fstype options when mounting file system -p - Provides a list of mounted file systems in vfstab format -v - Provides verbose output when mounting file system(s) -O - Overlays the file system on an existing mount point -m - Mounts file system without making an entry in /etc/mnttab Nosuid - Disallows setUID execution for files in this file system

File System Check If the fsck pass field contains a minus sign () or a zero (0), no file system integrity checking is performed. A file system with an fsck pass of one (1) indicates that the file system is to be checked sequentially (in the order it is listed in the [v]fstab file). Note that the / (root) file system is always checked first. File systems with an fsck pass number greater than one (1) are checked in parallel (simultaneously). For systems with a large number of disks spanning multiple disk controllers or disk busses, parallel file system checking is generally faster than sequential checking. For efficiency, use fsck on file systems of similar size on different disks simultaneously. Once the appropriate information has been entered in the [v]fstab file, you can mount all file systems by invoking the following command. # /etc/mount -a

Mounting File Systems The Volume Manager provides users with a means of mounting/unmounting removable media without granting system users root privileges typically required to mount/unmount a file system. Under Linux, you can add the “user” option to the list of options for a file system. This allows any user to mount/unmount the file system (an operation that usually requires root access). For example, the following fstab entry would allow any user to mount the /jaz file system located on the removable disk /dev/sda1. The nosuid option disallows execution of suid programs from this medium. /dev/sda1 /jaz ext2 defaults,user,exec,nosuid,noauto 0 0 usermount is a graphical tool developed by The usermount tool is available for several UNIX distributions that will allow users to manage removable media, such as floppy disks or zip disks. When the tool is invoked, it scans /etc/fstab for all file systems that have been configured to allow users to mount and unmount them. The file system can be mounted or unmounted by pressing the toggle button labeled Mount. usermount is available at

Creating and Mounting Identifying Mounted File Systems
Connecting a file system to the tree structure is called “mounting” the file system. UNIX provides several ways for the administrator to identify which file systems are currently mounted on the system. Three of the most common methods are: invoke /etc/mount command invoked with no arguments, Invoke the df command, and examination of the /etc/mnttab file The df Command Invoking the df command with no argument results in the display of information for all mounted file systems. glenn% df / (/dev/dsk/c0t3d0s0): blocks 9292 files /usr (/dev/dsk/c0t3d0s6): blocks files /tmp (swap): blocks 3288 files /opt (/dev/dsk/c0t3d0s5): blocks files When df is invoked with a directory argument, the output format changes, as shown in the following. glenn% df / File system kbytes used avail capacity Mounted on /dev/dsk/c0t3d0s % / The most complete df listing is obtained by using the -g option glenn% df -g / / (/dev/dsk/c0t3d0s0): 8192 block size 1024 frag size 41328 total blocks free blocks available total files 9292 free files filesys id ufs fstype 0x flag 255 file name length NOTE: It is important to remember the differences among the three block sizes discussed in this chapter. A disk block is the basic unit of storage on the physical medium. This unit is often 512 bytes long, but not always. An allocation block is the basic unit of space in a file system. It is either 8,192 or 4,096 bytes in length. A fragment, often 1,024 bytes in length, is a portion of an allocation block.

Creating and Mounting The /etc/mnttab File
Another way to determine which file systems are mounted is by examination of the /etc/mnttab file. This file is created and maintained by the /etc/mount command. Every time a file system is mounted, an entry is added to the mnttab file. When a file system is unmounted, the entry is removed from the mnttab file. # cat /etc/mnttab /dev/dsk/c0t3d0s0 / ufs rw,suid,dev= /dev/dsk/c0t3d0s6 /usr ufs rw,suid,dev=80001e /proc /proc proc rw,suid,dev= fd /dev/fd fd rw,suid,dev=27c /dev/dsk/c0t1d0s6 /var ufs rw,suid,dev=80000e swap /tmp tmpfs dev=

Creating and Mounting The mount Command
The mount command allows the administrator to view which file systems are mounted, as well as providing a method of mounting file systems. When invoked without arguments, the mount command lists mounted file systems by their mount points, showing the device mounted at each mount point, the mount options used, and the time the file system was mounted. glenn% /etc/mount / on /dev/dsk/c0t3d0s0 read/write/setuid on Sat Apr 1 1:23: /usr on /dev/dsk/c0t3d0s6 read/write/setuid on Sat Apr 1 1:23: /proc on /proc read/write/setuid on Sat Apr 1 1:23: /dev/fd on fd read/write/setuid on Sat Apr 1 1:23: /tmp on swap read/write on Sat Apr 1 1:23: /opt on /dev/dsk/c0t3d0s5 setuid/read/write on Sat Apr 1 1:23:

Creating and Mounting Unmounting a File System
The complement to mounting a file system is to unmount it using the /etc/umount command. Exercise great care when unmounting file systems! Some file systems are required for proper system operation. Other file systems may be unmounted while allowing the system to continue to operate, but the system will not perform as expected. The syntax for the umount command follows. # umount mount_point or # umount device The first form of the umount command unmounts the file system referred to by “mount point.” For example, umount /scratch would unmount the /scratch file system. The second form of the umount command unmounts the file system on the referenced disk partition. For example, if the /scratch file system is on the c0t2d0s1 disk partition, the operator could unmount it with umount /dev/dsk/c0t2d0s1. If you are uncertain about the effect unmounting a file system may have on the system, it is best to bring the system to the single-user state before invoking the umount command. In the case of a file server, unmounting a file system may also have an effect on nfs client machines on which the file system is mounted.

Creating and Mounting Volume Manager
Adding entries to the Solaris vfstab file works well for hard disks but is not suitable for removable media such as floppies and CD-ROMs. These devices tend to be mounted and unmounted much more frequently than hard disks, and the user performing this “mount” operation may not have the root privileges required to mount a normal file system. To handle such situations, Solaris uses the Volume Manager. Other OSs handle this situation by providing utilities under the desktop manager toolkit (such as KDE under Linux), mediad under Irix, and autodiskmount under MacOS X. Under Solaris, automatic detection of the media is limited to the CD-ROM device. The Solaris File Manager accomplishes this with a combination of a daemon (vold) and a configuration file (/etc/vold.conf), which specifies the actions to be taken for various removable devices and file system types. For floppy disks, Volume Manager is unable to detect the presence of new disks and must be informed that a new disk is present. This is accomplished by invoking the /bin/volcheck command. Volume Manager always mounts floppy disks under the /floppy directory it controls. CD-ROMs are likewise mounted under the /cdrom directory.

Creating and Mounting Configuring Volume Manager
Changing the actions taken and devices under control of Volume Manager is a simple matter of modifying the /etc/vold.conf file. # # Volume Daemon Configuration file # # Database to use (must be first) db db_mem.so # Labels supported label dos label_dos.so floppy label cdrom label_cdrom.so cdrom label sun label_sun.so floppy # Devices to use use cdrom drive /dev/dsk/c0t6 dev_cdrom.so cdrom0 use floppy drive /dev/diskette dev_floppy.so floppy0 # Actions insert /vol*/dev/diskette[0-9]/* user=root /usr/sbin/rmmount insert /vol*/dev/dsk/* user=root /usr/sbin/rmmount eject /vol*/dev/diskette[0-9]/* user=root /usr/sbin/rmmount eject /vol*/dev/dsk/* user=root /usr/sbin/rmmount notify /vol*/rdsk/* group=tty /usr/lib/vold/volmissing -c # List of file system types unsafe to eject unsafe ufs hsfs pcfs The lines beginning with a pound sign (#) are considered comments and are used here to help delineate the various sections of the configuration information. The first two sections, beginning with the comments Database and Labels, describe the database routines and disk label types Volume Manager recognizes. These two sections should not be modified. “Devices to use” Section The third section, marked by the comment Devices to use, lists the names and types of the removable media devices Volume Manager should monitor. Each line in this section starts with the keyword use, as follows. use cdrom drive /dev/dsk/c0t6 dev_cdrom.so cdrom0 The use keyword is followed by the type of device, either CD-ROM or floppy, and the keyword drive, as follows. Following the device type is the OS name for the device. Note that the CD-ROM device name specifies only the first five characters of the full special device name. Because Volume Manager will monitor and mount all available slices it finds on a CD-ROM disk, the only information items needed are the specific controller and target portions of the device name. Following the special device name is the name of the shared object used to manage the device. This must match the device type specified (e.g., if the device type is cdrom, the shared object must be dev_cdrom.so). Finally, the symbolic name used in the /device directory is listed. The first device of a given type has a 0 (zero) appended to its name, whereas the second is appended with a 1, and so on. For instance, a second CD-ROM drive located at target 5 on the built-in SCSI controller would be placed under Volume Manager control by adding the following line to the devices section of the vold.conf file. use cdrom drive /dev/dsk/c0t5 dev_cdrom.so cdrom1 Actions Section The next section, which begins with the comment Actions, specifies the actions to be taken when certain events occur. The basic events are the insertion of media into a drive (insert), removal of media from a drive (eject), and notification of problems (notify). An example entry in the actions section follows. eject /vol*/dev/diskette[0-9]/* user=root /usr/sbin/rmmount Entry Content Each line lists an event followed by a regular expression. When an event occurs, each line that begins with the name of the event (insert, eject, or notify) is checked. If the volume on which the event occurs matches the regular expression, the remainder of the action line comes into play. The remainder of this line includes the name of the user or group identification to be used to run the listed command with the listed arguments. In the previous example line, when the eject event occurs and the volume matches the regular expression /vol*/dev/diskette[0-9]/*, the command /usr/sbin/rmmount would be run with the root user permissions.

Creating and Mounting The rmmount.conf Configuration File
The /usr/sbin/rmmount command has its own configuration file named /etc/rmmount.conf. Although not often modified, this file allows the specification of additional actions to occur when a disk is mounted. A common use of this feature is to allow CD-ROMs mounted by Volume Manager to be automatically shared, or made accessible to other workstations on the network via NFS. To accomplish this, a share line is added to the bottom of the /etc/rmmount.conf file as follows. share cdrom* This line would share any CD-ROM mounted by Volume Manager without any restrictions. To control access the administrator can add options to the share line in a form similar to the share command.

Creating and Mounting Mounting Non-ufs File Systems with Volume Manager Volume Manager is also able to handle file system types other than ufs. For instance, inserting an MS-DOS-formatted floppy and using File Manager or the volcheck command results in the disk being mounted under the /floppy directory on a mount point that bears the floppy volume name. Starting and Stopping Volume Manager UNIX makes it possible to disable Volume Manager and work directly with the CD-ROM and/or floppy drive. To disable Volume Manager, invoke the /etc/init.d/volmgt script with the stop option. To restart Volume Manager, invoke the /etc/init.d/volmgt script with the start option.

File System Repair Most versions of UNIX, by default, provide very similar file system capabilities. The default file system does not provide any extraordinary safeguards against file loss due to events such as power failure or system crashes. These file systems rely on their understanding that everything will get written to disk, and nothing bad will happen. In the event that something bad does occur, a few utilities are provided to clean up the resulting mess.

File System Repair Older versions of UNIX used to have three utilities which were used to check the consistency of various portions of the file system structures: icheck – this utility was used to check the inode structure to ensure that the proper blocks were used, and unused. dcheck – this utility was used to check that all of the data blocks for a given inode were properly linked. ncheck – this utility generates a list of filenames and inodes given a file system name. It was used to scan the filesystem, and list all of the filenames, and inodes in that file system.

File System Repair Current versions of UNIX have a tool that combined the functionality of these three utilities into a single (automated) tool: fsck – File system check utility Fsck is a multi-phase file system checker. Phase 1 checks that all of the right blocks are used (or unused) within the file system. This phase also checks that the size of the file (as recorded in the inode) agrees with the size of the data stored in the “used” blocks. Phase 2 of fsck checks to ensure that the directory and file name structure is coherent. Phase 3 of fsck checks to ensure that the directories are connected to the file system tree in the proper places, and that all links are properly referenced in the inode structure. Phase 4 checks to ensure that the link counts and reference counts are correct. Phase 5 checks individual cylinder group utilization, and reports file system statistics.

File System Repair There are two categories of file system damage:
Recoverable File System Damage This type of damage can be repaired using the fsck utility. Generally caused by improper shutdown, or system crashes. File system data, or meta data has not been stored on the disk, and the file system state is inconsistent. Fsck can generally fix these problems using information stored in alternate superblocks. Any orphaned files/directories are placed in the lost+found directory at the top of the file system. Since the file name is not stored in the inode, these files are stored using the inode number for the file name.

TIP: It is often faster (and easier) not to reconnect zero-length files. Zero-length files may occur if a program creates a temporary file, opens it, and then removes it while the file is still open. The result is a file that does not belong to any directory but is still available to be written and read by the program. Under normal operations the file is cleaned up when the program exits.

File System Repair Restoring Files Versus Repairing a File System
Sometimes the file system damage is severe enough that it would take fsck several passes to repair the damage. In such cases, it might be more productive to newfs the file system, and reload the contents from backups. MAKE SURE THAT YOU HAVE A GOOD BACKUP OF THE DATA BEFORE MAKING THE DECISION TO NEWFS AND RELOAD!!!

File System Repair Unrecoverable File System Damage
Some types of disk corruption are not repairable using fsck. Superblock unreadable. Head crash Other hardware failure

File System Repair Journaling File Systems
The benefit of using a journaled file system is that the system is more immune to data loss the nature of which is the result of a power failure or system crash. Large file systems often suffer significant data loss when a system crashes. Journaling file systems provide significant improvement in (reduced) reboot time, and data retention on large file systems. A drawback of using a journaled file system is that you have to reserve disk space for the journal. On most systems, the journal is a small meta-partition on the disk. Linux provides support for the following journaling file systems: BeFS (BeOS File System), HTFS (SCO High Throughput file system), JFS (IBM journaling file system), NSS (Novel Storage Services), VxFS (Veritas File System), XFS (IRIX Extended File system), and the EXT3 file system. These are the most popular journaling file systems under Linux. The ext3 file system has become the standard on newer releases of Linux. The ext3 file system introduces several options for journaling that were not available under ext2. These options allow the sysadmin to tune the journal. The sysadmin can make the decision to tune the file system for performance (speed), or to tune the file system for reliability (data integrity). When tuning ext3 file systems for speed, the administrator can choose among the following modes.

Windows File System Check
Windows also provides a file system check program. Some versions of Windows refer to this program as scandisk, while other versions refer to it as checkdsk. Performs the same functions as fsck under UNIX. The Windows chkdsk utility hides many details from the administrator. The simple way to check a Windows disk for errors is to right-click on the disk in the My Computer window, and select the Properties item. Under the Properties item, select the Tools tab. You will be given the following three choices of tasks you can perform on the disk.

Windows File System Check
Error-checking: Allows you two options: the ability to scan the surface of the disk and attempt to repair bad blocks, and the ability to automatically repair file system errors as they are found. Orphans are placed in the top level of the file system and given names like “FILE0000, DIR0001, …” Backup: Allows you to run a file system backup or restore operation. Defragmentation: Allows you to clean up file system storage blocks used to store fragments of files. A file fragment exists because the file did not contain enough information to completely fill a multiple of disk sectors. When this occurs, only a portion of at least one disk sector is filled by the file. Over time, the file may be altered, and the space consumed by these fragmented sectors begins to add up. Another cause of file system fragmentation is the removal of files. This operation leaves clusters of data sectors empty in a field of sectors in use for other files. The defragmentation operation cleans these fragmented sectors, and causes the files to occupy contiguous sectors (if possible).

Recognizing Failing Disks
Soft Errors These are typically bad spot appearing on the disk surfaces. This is expected. Beware of large numbers of bad spots appearing over a short period.

Soft errors can usually be repaired using the format utility. Make sure that you have a good backup of all data before attempting this! Use non-destructive scans whenever possible. Use read then write back mode if you must do write testing.

Hard Errors Hard errors are typically caused by head crashes, cabling problems, or electronics failures WARNING: Whenever a fatal disk error is reported, the administrator should be very concerned about the integrity of the files on the disk drive. Steps must be taken to rectify the problem immediately, or data may be destroyed.

Repairing Disk Errors Perform a full backup of the failing disk, or better yet, the entire system. Reboot the system to determine if the failure is due to corrupted system information. If the block number of a bad spot is known, use the system’s format utility to map out the spot on the drive. If there are several bad spots on the drive, use the surface verification portion of the format utility to perform nondestructive surface analysis of the drive to search for and optionally repair bad spots. Replace the drive with a known good drive. Copy all data to the new drive. Note that this option can be time consuming and expensive. NOTE: The repair option does not work with IDE disk drives. The IDE subsystem should handle bad- block mapping on its own.

Improving Disk Subsystem Performance
File System Optimization Optimize file systems across multiple spindles and controllers. Optimize file system structures for the type of files to be stored on the file system. The default newfs settings are good for general purpose file systems. But they are also very inefficient for certain types of applications. File systems containing primarily large files require fewer inodes. This leads to a lot of lost space. File systems containing primarily small files require more inodes. This leads to a problem where there is space left on the device, but no file system structures are available to address the unused space! TIP: Due to the performance characteristics of SCSI and IDE disk subsystems, it would be advisable to incorporate SCSI-based disk drives in any high-performance disk subsystems. The high- end SCSI drives typically outperform their IDE counterparts in such applications. NOTE: A growing number of modern SCSI disks are “smart” in that they have a sophisticated internal controller and memory buffer that hide certain performance characteristics. These disks provide high performance, but are not readily tunable. The internal controller and memory buffer mask the effects of selected adjustments such as rotational delay factors. TIP: It is always a good idea to verify that the file system has been backed up to tape before making changes. If something goes wrong, the backup medium could be used to reload the files once a new file system is created with the desired parameters.

File system tuning can provide only limited performance improvements. Performance tuning is critical to the first type (active files), and probably not very important for the archive server. In most instances, disk farms are set up to provide high-speed access to important data. Typical applications include database systems, medical images, and other space-intensive information services. In a few instances, the disk farm is used for long-term archival storage. Because the information on these systems is not accessed very often, high performance is not always the driving criterion in file system tuning. Although tunefs is capable of changing many characteristics of the disk subsystem, it is not a do-all/save-all I/O subsystem fix-it tool.

The tunefs command allows you to “tune” file system parameters as you build a file system (more/less inodes, more/less free space, …). Tuning for Special Disks and Disk Controllers By default, newfs uses the information in the disk label to calculate several factors related to the ability of the disk, controller, and CPU to read or write information. As the disk rotates, each block in the track moves past the disk heads. If the controller and CPU are fast enough, blocks may be written or read in the order they come under the heads. Slower controller/CPU combinations must skip one or more blocks between read/writes to keep up with the I/O demands of the system. The newfs and tunefs commands allow the rotational interleave aspect of the file system to be adjusted by calculating the required time for a single block read to be processed. Some disk controllers are capable of writing or reading multiple blocks in a single operation due to high-speed buffer memory located in the controller.

Tuning for Small and Large Files Applications that consistently read and write very small (or very large) files can often benefit from file system tuning. Large files are often split between cylinder groups. A cylinder group is a collection of cylinders used by the disk I/O routines in the kernel to improve disk performance by grouping a file’s data blocks close together on the disk. When a large file is split over two or more cylinder groups, the file’s data blocks are spread across the disk. Consequently, extra seek time is required. Adjusting the maximum number of blocks that can be allocated to a single file within a cylinder group may help reduce this problem.

Tuning for Small and Large Files It is also possible to adjust basic allocation block and fragment sizes on the file system. Larger allocation block and fragment sizes favor large files by reducing the time required for file allocation at the expense of reduced space efficiency. If an application stores small files (exclusively), a smaller allocation block will improve speed, and a smaller fragment size will improve space utilization efficiency by avoiding the allocation of blocks that are much larger than the data to be stored.

Tuning for Storage Space Efficiency Versus Speed The disk storage routines in the UNIX kernel have two strategies available for disk allocation: time and space. Time efficiency refers to the time required to allocate space and write files. Optimizing time is wasteful of space because transfers often result in gaps being created in lieu of long, continuous disk writes. Space efficiency refers to the efficient use of scattered blocks on the disk. Optimizing space wastes time because a file is allocated to blocks scattered around the disk, and the disk heads must move more frequently to read or write a file. NOTE: The space-versus-time storage strategy routines are automatically set by newfs, depending on the allocated minimum free space. The defaults are to use space optimization when the minimum free space is less than 10% of the disk blocks, and to use time optimization when the minimum free space is 10% or more of the disk blocks.

Summary Understanding how file systems are created, mounted, checked, and tuned enables the administrator to effectively manage corporate disk space. More importantly, understanding how to mount, create, and unmount file systems on an active system can result in minimization of down-time for corporate users. The sysadmin should understand typical failure modes, and how to repair these problems. Performance tuning is also a big part of the system administrator’s duties.

System Backups and Disaster Recovery
Chapter 13

Chapter Goals Understanding the importance of backups.
Understand the issues associated with backups. Understand backup strategies and scheduling. Understand the basics of backup devices. Understand the basics of backup media. Understand the various types of backup software.

Importance of System Backups
Which Files Should Be Backed Up? OS Binaries? Applications? Configuration Files? User files? Log files? Generally, full backups of everything are easiest to manage, but backup of system files is creating extra work for yourself. Possibly full dump when installed, then again after patches/upgrades. Backup of just user files is not enough. Should dump the log files, and configuration information. TIP: One method of determining which files change frequently is to use the Tripwire program. Tripwire can produce a list of files that have changed subsequent to the creation of the tripwire database. This list should be parsed to ensure that files that change are backed up to tape. NOTE: The examples in this chapter assume computer system operation seven days a week, and thus the need for seven backups per week. In some instances, corporate computer systems are idle on weekends, enabling the administrator to use a five-day-per-week backup schedule.

Importance of System Backups
How Often Should Backups Be Performed? Need to determine what level of data loss is acceptable: Web sales? - need very fine grain backups. Banking/Insurance? - very fine grain. Research and development? - fine to medium grain. University? - medium grain. Mom and Pop? - coarse grain.

Backup Strategy and Scheduling
Types of Backups Full backup– dump every file to dump media. Partial (incremental) backup – dump all files that have changed since last lower level backup to dump media. Unix uses a multi-level partial scheme (level 0 is a full, level 1 – 9 are incremental). All files that have been modified since the last ufsdump at a lower dump level are copied to the dump media. For instance, if a "level 2" dump was done on Monday, followed by a "level 4" dump on Tuesday, a subsequent "level 3 dump on Wednesday would contain all files modified or added since the "level 2" (Monday) backup. A "level 0" dump copies the entire file system to the dump media.

Backup Strategies There are several algorithms that might be used to schedule full and partial backups. The choice of algorithm dictates the amount of media required. The choice of algorithm plays a large role in the size of the restore window (how long is data available from a backup tape). Some of the more popular algorithms are: Volume/Calendar Backup Grandfather/Father/Son Backup Tower of Hanoi Backup To ensure that backups capture as much of the system data as possible, the interval between backups should be kept to a minimum. With these constraints in mind, it is time to examine a few of the more popular backup strategies. NOTE: To ensure successful dumps, many operating system manufacturers recommend that the system be shut down to the single-user init state.

Volume/Calendar Backup The volume/calendar backup strategy calls for a full system backup once a month. An incremental backup is performed once a week for files that change often. Daily incremental backups catch files that have changed since the last daily backup. A typical schedule would be to perform the full (level 0) backup one Sunday a month, and weekly level 3 backups every Sunday of the month. Daily level 5 backups would be performed Monday through Saturday. This would require eight complete sets of media (one monthly tape, one weekly tape, and six daily tapes)

Volume Calendar Su M Tu W Th F Sa Week 1 Tape A B C D E F G
Level Weeks 2, 3, 4 H Level Recovering from complete data loss with the volume/calendar scheme requires restoring from the most recent full backup, then restoring from the most recent weekly backup, and finally, restoring from each daily backup tape written since the weekly backup. An advantage to this backup scheme is that it requires a minimum of media, but this also points out one of the major problems with this backup scheme: tapes are immediately reused. For example, every Monday overwrites last Monday’s backup information. Consider what would happen if one of the disk drives failed during the second Monday backup. It would not be possible to recover all data, because the system was in the process of overwriting the backup tape when the drive failed.

Grandfather/Father/Son Backup The grandfather/father/son backup strategy is similar to the volume/calendar strategy. The major difference between the two schemes is that the grandfather/father/son method incorporates a one-month archive in the backup scheme. This eliminates the problem of overwriting a tape before completing a more recent backup of the file system. Implementing the grandfather/father/son strategy requires performing a full (level 0) dump once a month to new media. Once a week, an incremental (level 3) backup must be performed that captures all files changed since the last weekly backup. This weekly backup should also be saved on new media. Each day an incremental level 5 backup must be performed to capture files that have changed since the last daily backup. The daily backups reuse the tapes written one week earlier

Grandfather/Father/Son
Su M Tu W Th F Sa Week 1 Tape A B C D E F G Level Week 2 Tape H I Level Week 3 Tape H J Week 4 Tape H K Week 5 L M Level Week 6 Tape H G Week 7 Tape H I Week 8 Tape H J Week 9 Tape A Level 0

Grandfather/father/son
To maintain a one-month archive, the monthly full backup tape should be placed in storage. Each weekly full backup should be placed in storage. The second monthly full backup, should use new media. When the third monthly backup is due, the first month’s full backup media should be reused. The weekly backups are archived in a similar manner. This scheme requires two sets of monthly backup media, five sets of weekly backup media, and six sets of daily backup media. A total of 13 sets of media are required to implement this strategy with a one-month archive of information. To recover from complete data loss, first restore the most recent level 0 backup tape. Next, restore from the most recent of the level 3 backups, if that backup was written after the level 0 backup. When the level 3 backup has been restored, the operator would restore from each of the level 5 backups written after the level 3 backup. This backup strategy requires much more media than the simple volume / calendar strategy. Although media cost is increased with this plan, data survivability also increases.

Tower of Hanoi Backup The Tower of Hanoi backup strategy is a variation of “exponential backup.” Both strategies rely on functions of powers of 2. For example, the use of five backup tapes provides for a 32-day schedule. The use of six tapes would provide for a 64-day schedule. The Tower of Hanoi backup schedule provides outstanding data survivability and a minimum of media. Unfortunately, on a seven-day backup system, the scheduling of full backups as opposed to partial backups can become a problem for the operator. One way to avoid operator confusion is to perform a special level 0 backup on the first day of each month. This tape would not be one of the five tapes used in the backup cycle. Total media requirements in this scheme would be seven sets of media.

Su M Tu W Th F Sa Week 1 Tape E A B A C A B Level Week 2 Tape A D A B A C A Level Week 3 Tape B A E A B A C Level Week 4 Tape A B A D A B A Level Week 5 C A B A E A B Level Week 6 Tape A C A B A D A Level Week 7 Tape B A C A B A E Level Week 8 Tape A B A C A B A Level Week 9 Tape D A B Level

Tower of Hanoi Backup To recover from complete data loss, first restore from the most recent level 0 backup, and then restore from the level 1 backup if that backup was written after the level 0 backup. Next, restore consecutively from the most recent level 3 and 4 backups if both were written after the level 0 backup. Finally, restore each of the level 5 backups that were written after the level 0 backup.

Reasonable Alternative
The following four-week schedule offers a reasonable backup schedule for most sites. Performing a full dump on the first Sunday of the month provides a monthly snapshot of the system data. Using two sets of dump media allows the operator to store information for two full months. Note that in the example the Tuesday through Friday incremental backups contain extra copies of files from Monday. This schedule ensures that any file modified during the week can be recovered from the previous day’s incremental dump. To recover from complete data loss, restore the most recent full (level 0) backup tape. Next, restore from the most recent of the weekly (level 3) backups. Once the weekly backups are restored, restore from each of the daily (level 5) backups.

A Reasonable Alternative?
Su M Tu W Th F Sa Week 1 Tape A B C D E Level Week 2 Tape F B C D E Level Week 3 Tape F B C D E Level Week 4 Tape F B C D E Level

Backup Devices Backup devices must exhibit the following traits:
User ability to write data to the device. Media capable of storing the data for long periods. Support of standard system interconnects. Support of reasonable input/output throughput.

Backup Devices Tape Backup Devices Optical Backup Devices
Cartridge Tape Drive 8-mm Tape Drive Digital Audio Tape Drive Linear Tape Open Digital Linear Tape Jukebox/Stacker Systems Optical Backup Devices Magneto-optical Backup Devices Disk Systems As Backup Devices RAID Disk Arrays Problems with Disks As Backup Devices High-Density Removable Media Backups

Backup Devices Tape backup devices are probably the most common backup media in use. The media is relatively inexpensive, the performance is reasonable, the data formats are standardized, and tape drives are easy to use. These factors combined make magnetic tape backups an attractive option. Most current-generation tape drives offer “native” mode and compressed mode storage capabilities. Generally, the manufacturers claim a 2:1 compression ratio, but this value may vary based on the data to be stored. Binaries (images, compiled programs, audio files, and so on) may not be significantly smaller when compressed, whereas text files may compress very well. TIP: Many operators elect not to enable the compression hardware on tape systems, opting instead for software compression before the data are sent to the tape drive. In the event of a hardware failure in the tape drive’s compression circuitry, it is possible that the data written to tape would be scrambled. By using the software compression techniques, the operator can bypass such potential problems at the cost of a few CPU cycles.

Tape Backup Devices Cartridge Tape Drive
Cartridge tape drives store between 10 Mb and several Gb of data on a small tape cartridge. Most cartridge tape systems use SCSI interconnections to the host system. These devices support data transfer rates up to 5 Mb per second. The actual transfer rate from the tape drive memory to the tape media is typically about 500 Kb per second. 8-mm Tape Drive These tape drives are also small and fast, and use relatively inexpensive tape media. The 8-mm media can hold between 2 and 100 GB of data, depending on the drive model and type of tape in use. The 8-mm drives use the SCSI bus as the system interconnection. Low-density 8-mm drives can store 2.2 Gb of information on tape. and transfer data to the tape at 250 Kb per second. High-density 8-mm drives can store up to 80 GB of information on a tape at a 16 MB/second. “low” end, the 8-mm drives do not use data compression to store the data on tape. “high” end, advanced intelligent tape drives incorporate compression hardware and improved recording techniques to increase the amount of information that can be stored on the tape.

Tape Backup Devices Digital Audio Tape Drive Digital audio tape (DAT) drives are small, fast, and use relatively inexpensive tape media. Typical DAT media can hold between 2 and 40 GB of data. Although manufacturers of DAT devices have announced the end-of-life for these products, they will remain in use for many years. The various densities available on DAT drives are due to data compression. A standard DAT drive can write 2 Gb of data to a tape. By using various data compression algorithms, and various lengths of tape, manufacturers have produced drives that can store between 2 and 40 GB of data on a tape. DAT drives use SCSI bus interconnections to the host system, and typically offer 3 MB/second throughput.

Tape Backup Devices Linear Tape Open A consortium of Hewlett Packard, IBM, and Seagate developed the LTO technology. LTO encompasses two formats: the Ultrium, a high-capacity solution, and Accelis format, a fast-access format. The two formats use different tape drives, and tape cartridges. LTO Ultrium drives can store up to 100 Gb of data on a single tape cartridge at 16 Mb/second.

Tape Backup Devices Digital Linear Tape
Digital linear tape (DLT) backup devices are also relatively new on the backup market. These tape devices offer huge data storage capabilities, high transfer rates, and small (but somewhat costly) media. Digital linear tape drives can store up to 110 Gb of data on a single tape cartridge. Transfer rates of 11 Mb/second are possible on high-end Super-DLT drives, making them very attractive at sites with large on-line storage systems. Where 8-mm and DAT tapes cost (roughly) $15 per tape, the LTO, AIT, and DLT tapes can run as much as $150 each. However, when the tape capacity is factored into the equation, the costs of these high-capacity tapes become much more reasonable. Consider an 8-mm tape that holds (up to) 14 Gb on average versus a LTO cartridge, which can hold 100 Gb of data!

Tape Backup Devices Jukebox/Stacker Systems
Jukebox or stacker systems combine an automated mechanism with one or more tape drives. Stackers are sequential tape systems. Tapes are stacked in a hopper, and the tape drive starts by loading the tape at the bottom of the stack. When the tape is full, it is ejected, and the next tape is loaded from the stack. Many stackers do not have the capability to load a specific tape in the drive. Instead, these stackers simply cycle (sequentially) through the tapes until the last tape is reached. At this point they can either start the cycle over again or wait for a new group of tapes to be loaded into the hopper.

Tape Backup Devices Jukebox/Stacker Systems
Unlike stackers, jukebox systems employ multiple tape drives, and special “robotic” hardware to load and unload the tapes. Jukebox systems require special software to control the robotics. The software keeps track of the content of each tape and builds an index to allow the user to quickly load the correct tape on demand. Each tape is “labeled” with a bar-code decal (or something similar), and the mechanism contains a label reader that keeps track of what tape is in the drive. Many commercially available backup software packages allow the use of jukebox systems to permit backup automation.

Optical Backup Devices
Recently, optical storage devices have become another economical means of backing up mass storage systems. Compact disk read-only-memory devices (CD-ROM) are useful for long-term archive of information. Although the name implies that these are read-only devices, recent technology has made it possible to mass market the devices that create the encoded CD-ROM media. These CD-ROM writers (also called CD-recordables) make it possible to consider CD-ROM as a backup device. More recent versions of this technology have produced rewritable CD-ROMs (CD-RW or CDR).

Optical Backup Devices
One of the major decisions in choosing a backup device is the ability of the medium to store information for long periods. CD-ROM media offer excellent data survivability. Another advantage to the CD-ROM is the availability of reliable data transportability between systems. This reliability is possible due to the CD-ROM’s adherence to industry standardized data formats. Along with these advantages, the CD-ROM offers a few unique disadvantages. The foremost disadvantage to the CD-ROM as a backup device is the setup cost to create a CD. Setting up and creating a CD is a time-intensive operation. Some small sites may decide to back up to CD-ROM rewritable (CDR) media. The CDR format allows the reuse of optical media, thereby reducing the cost of backing up to optical devices. Unfortunately, the CDR is still a low-density solution, providing a mere 650 Mb of storage per disk. The setup and record time for CDR is comparable to CD-ROM media, making CDR less attractive for backups at large sites.

Magneto-Optical Backup Devices
Optical storage systems and associated media are typically expensive. They are also relatively slow devices. Consequently, optical storage systems are rarely used as backup devices at large sites. In contrast, magnetic tape (or disk) storage systems are inexpensive and fast. Unfortunately, the media is bulky and susceptible to damage and data loss. By combining the two storage systems into a single system, manufacturers have been able to provide fast, inexpensive, and reliable backup systems. Many of the magneto-optical systems are hierarchical, meaning that they keep track of how long a file has been in storage since the last modification. Files that are not accessed or modified are often eligible to be stored on the slower optical storage section of the system. Frequently accessed files are maintained on the magnetic storage section of these systems, which allows for faster access to files. Most magneto-optical storage systems use standard SCSI bus system interconnections. These systems can typically provide the same (or better) data transfer rates as SCSI tape and disk systems.

Disk Backup Devices Disk Systems As Backup Devices
One problem involved in using tape devices for backups is the (relatively) low data throughput rate. If the operator had to back up several gigabytes or terabytes of data daily, it would not take long to realize that tape drives are not the best backup method. Although optical backup devices offer high storage capacity, the optical devices are often much slower than tape devices. One popular method of backing up large-scale systems is to make backup copies of the data on several disk drives. Disk drives are orders of magnitude faster than tape devices, and therefore offer a solution to one of the backup problems on large-scale systems. However, disk drives are much more expensive than tapes. Disk backups also consume large amounts of system resources. For example, you would need Gb disks to back up Gb disks. Fortunately, there are software applications and hardware systems available to transparently perform this function.

Disk Backup Devices RAID Disk Arrays
One operating mode of redundant arrays of inexpensive disks (RAID) enables the system to make mirror image copies of all data on backup disk drives. RAID disk arrays also allow data striping for high-speed data access. Yet another mode stores the original data, as well as parity information on the RAID disks. If a drive should fail, the parity information may be used to recreate the data from the failed drive. Problems with Disks As Backup Devices When tape devices are employed as the backup platform, it is a simple matter to keep a copy of the backups off-site. When disk drives are employed as a backup media, the process of keeping a copy of the backup media off-site becomes a bit more complicated (not to mention much more expensive). In the case of a RAID disk array, the primary copy of the data is stored on one disk, and the backup copy of the data is stored on another disk. However, both disks are housed in a single box. This makes the task of moving one drive off-site much more complicated.

Disk Backup Devices RAID disk arrays have recently been equipped with fiber channel interfaces. The fiber channel is a high-speed interconnect that allows devices to be located several kilometers from the computer. By linking RAID disk arrays to systems via optical fibers, it is possible to have an exact copy of the data at a great distance from the primary computing site at all times. High-Density Removable Media Backups A relatively recent addition to the backup market is the high-density removable media drive. Examples of these devices include the Iomega ZIP and JAZ drives, and the Imation Superdisk drives. These devices are capable of recording 100 Mb to 2 Gb of data on a removable medium that resembles a floppy diskette. Until recently, UNIX could not make use of these high-density removable media devices. Many of these devices employ a parallel port interface. A few of them offer SCSI interfaces, allowing them to be connected to the external SCSI port on a workstation.

Unix Backup Commands Unix operating environments include a plethora of backup utilities. The [ufs]dump and [ufs]restore utilities are available under most UNIX variants. The dump application was developed to allow the backup of entire systems one at a time. The dump program allows the operator to specify files to be “dumped” (or backed up to tape), and options to use during the dump. In addition, dump enables scheduling of different levels of dumps on different days. The dump command also allows for dumps that occupy multiple tape reels. NOTE: It is important to note that most versions of dump are incompatible. For example, using ufsdump to back up a Solaris system makes it impossible to reload the data to a Linux system. The “on-tape” formats used by different versions of dump are simply incompatible. Such a tape would need to be reloaded using a Solaris host as the tape host. WARNING: Several releases of Solaris have included versions of ufsdump and ufsrestore that contain a buffer that is not bounds checked. This has allowed the creation of an exploit that gives a hacker root access to your system! Many security experts recommend that the file permissions of ufsdump and ufsrestore be changed to This disables the exploit, as the program no longer operates with special permissions, but it also means that the account used to run backups must be given read permission on the system disks.

UNIX Backup Commands dump [options] [arguments] files_to_dump
NOTE: The dump command requires that the user have read access privileges on the system disks. 0-9: These numeric values specify the dump level. All files that have been modified since the last dump at a lower dump level are copied to the media. b: Signifies the blocking factor to be used. The default is 20 blocks per write for tape densities of 6,250 BPI (bytes per inch) or less. The blocking factor of 64 is used for tapes with 6,250 BPI or greater density. The default blocking factor for cartridge tapes is 126. NOTE: blocking factor is specified in 512-byte blocks. c: Signifies that the backup device is a cartridge tape drive. The option sets the density to 1,000 BPI and the blocking factor to 126. d: Signifies the density of the backup media in BPIs. The default density is 6,250 BPI except when the c option is used. When the c option is used, the density is set to 1,000 BPI per track.

Unix Backup Commands D: Signifies that the dump device is a floppy diskette. f: Signifies the dump file. This option causes dump to use dump file as the file to dump to, instead of /dev/rmt/0. s: Signifies the size of the backup volume. This option is not normally required because dump can detect end-of-media. When the specified size is reached, dump waits for the operator to change the volume. The size parameter is interpreted as the length in feet for tapes and cartridges, and as the number of 1,024-byte blocks for diskettes. u: This option causes dump to annotate which file systems were dumped, the dump level, and the date in the /etc/dumpdates file. v: This letter signifies that dump should verify the content of the backup media after each tape or diskette is written. # dump 0fu /dev/rmt/0 /dev/rdsk/c0t3d0s2

Estimated 47952 blocks (23.41MB): Estimated size of the dump.
XX.XX% done, finished in H:MM: What proportion of the dump is completed, and how long the remainder will take to complete. 47948 blocks (23.41MB) on 1 volume at 1038 KB/ sec: This message tells how many blocks were dumped, and how many tapes (volumes) were required.

UNIX Backup Commands Now that file systems have been copied onto a tape, how is this information retrieved? UNIX provides an application to restore data from the backup media to the system mass storage devices. This application is called restore. /usr/sbin/restore options [ arguments ] [ filename ... ] Some of the most useful options to the restore commands follow. i: Places restore in the interactive mode. Commands available in this mode follow. add [filename]: Adds the named file or directory to the list of files to be extracted. cd directory: Changes to directory on the dump media. delete [filename]: Deletes the current directory or file from the list of files to be extracted. extract: Extracts all files on the extraction list from the dump media. i: Places restore in the interactive mode. Commands available in this mode follow. add [filename]: Adds the named file or directory to the list of files to be extracted. cd directory: Changes to directory on the dump media. delete [filename]: Deletes the current directory or file from the list of files to be extracted. extract: Extracts all files on the extraction list from the dump media. help: Displays a summary of available commands. ls [directory]: Lists files in directory (dump media) or the current directory, which is represented by a period (.). pwd: Prints the full path name of the current working directory. quit: Exits immediately. verbose: Toggles the verbose flag (the program prints a line for every action it takes). r: Restores the entire content of the media into the current directory. x: Extracts the named files from the media. b: Sets the restore blocking factor. f [dump file]: Tells restore to use the dump file instead of /dev/rmt/0 as the file to restore from. R: Resumes restore after volume is changed. t: Prints table of contents for dump file. n: Skips to the nth file when multiple dump files exist on the same tape. v: Displays the name and inode number of each file restored.

UNIX Backup Commands ls [directory]: Lists files in directory (dump media) or the current directory, which is represented by a period (.). pwd: Prints the full path name of the current working directory. quit: Exits immediately. verbose: Toggles the verbose flag (the program prints a line for every action it takes). r: Restores the entire content of the media into the current directory. x: Extracts the named files from the media. b: Sets the restore blocking factor. f [dump file]: Tells restore to use the dump file instead of /dev/rmt/0 as the file to restore from. R: Resumes restore after volume is changed. t: Prints table of contents for dump file. n: Skips to the nth file when multiple dump files exist on the same tape. v: Displays the name and inode number of each file restored. Note that the i, r, R, t, and x arguments are mutually exclusive. Only one of these arguments may be used at a time. i: Places restore in the interactive mode. Commands available in this mode follow. add [filename]: Adds the named file or directory to the list of files to be extracted. cd directory: Changes to directory on the dump media. delete [filename]: Deletes the current directory or file from the list of files to be extracted. extract: Extracts all files on the extraction list from the dump media. help: Displays a summary of available commands. ls [directory]: Lists files in directory (dump media) or the current directory, which is represented by a period (.). pwd: Prints the full path name of the current working directory. quit: Exits immediately. verbose: Toggles the verbose flag (the program prints a line for every action it takes). r: Restores the entire content of the media into the current directory. x: Extracts the named files from the media. b: Sets the restore blocking factor. f [dump file]: Tells restore to use the dump file instead of /dev/rmt/0 as the file to restore from. R: Resumes restore after volume is changed. t: Prints table of contents for dump file. n: Skips to the nth file when multiple dump files exist on the same tape. v: Displays the name and inode number of each file restored.

Unix Backup Commands Example restore Commands
# restore rbf 50 /dev/rmt/0 /dev/rdsk/c0t2d0s2 TIP: A side effect of using restore is that it creates a “symbol table” file in the file system where the files are restored. This file is named restoresymtable. It is wise to remove this file because it is usually quite large. Once the restore is complete, remove the file by issuing the command rm ./restoresymtable. WARNING: Failure to remove the restoresymtable file may come back to haunt you! If the restoresymtable is left on the disk and dumped to a full dump, it will overwrite the restoresymtable file created when you perform a restore. This will prevent proper restoration of any incremental dumps required to bring the system back into operation.

Unix Backup Commands # restore ibf 50 /dev/rmt/0
TIP: A side effect of using restore is that it creates a “symbol table” file in the file system where the files are restored. This file is named restoresymtable. It is wise to remove this file because it is usually quite large. Once the restore is complete, remove the file by issuing the command rm ./restoresymtable. WARNING: Failure to remove the restoresymtable file may come back to haunt you! If the restoresymtable is left on the disk and dumped to a full dump, it will overwrite the restoresymtable file created when you perform a restore. This will prevent proper restoration of any incremental dumps required to bring the system back into operation.

Unix Backup Commands Remote Backup and Restore
How can a file system dump be performed on a system without a backup device? The dump and restore commands allow input and output to be sent to the standard input and output streams. This flexibility allows the dump/restore output to be sent through the network to a system with a backup device. The -f option for dump and restore specifies the dump device. f dump file: This option tells dump to use dump file as the file to dump to. If dump file is specified as a hyphen ( - ), dump will dump to standard output. If the name of the file is of the form machine:device, the dump is carried out from the specified machine over the network using the rmt facility. NOTE: Because dump is normally run by root, the name of the local machine must appear in the /.rhosts file of the remote machine. TIP: A side effect of using restore is that it creates a “symbol table” file in the file system where the files are restored. This file is named restoresymtable. It is wise to remove this file because it is usually quite large. Once the restore is complete, remove the file by issuing the command rm ./restoresymtable. WARNING: Failure to remove the restoresymtable file may come back to haunt you! If the restoresymtable is left on the disk and dumped to a full dump, it will overwrite the restoresymtable file created when you perform a restore. This will prevent proper restoration of any incremental dumps required to bring the system back into operation.

Unix Backup Commands To perform a remote restore using the restore command, the operator can make use of the -f option again. f dump file: This option tells restore to use dump file as the file to restore from. If dump file is specified as a hyphen ( - ), restore reads from the standard input. NOTE: Because restore is also normally run by root, the name of the local machine must appear in the /.rhosts file of the remote machine. To copy a home partition to another machine with a remote restore, consider the following command, substituting the appropriate directory and device names. # dump 0f - /dev/rdsk/c0t2d0s2 | (rsh machine ; cd /home;restore xf -) TIP: A side effect of using restore is that it creates a “symbol table” file in the file system where the files are restored. This file is named restoresymtable. It is wise to remove this file because it is usually quite large. Once the restore is complete, remove the file by issuing the command rm ./restoresymtable. WARNING: Failure to remove the restoresymtable file may come back to haunt you! If the restoresymtable is left on the disk and dumped to a full dump, it will overwrite the restoresymtable file created when you perform a restore. This will prevent proper restoration of any incremental dumps required to bring the system back into operation.

Unix Backup Commands tar Command
What happens if the operator does not want to dump and restore complete file systems? For example, what if a user simply wants to make a tape of the data associated with one project? Most UNIX derivatives provide a standardized utility called tar. The tar command creates tape archives and provides the ability to add and extract files from these archives. % tar c -C /home/project include -C /data/project % tar cvf /dev/rmt/0 Create a tar archive on device /dev/rmt/0 % tar tvf /dev/rmt/0 List the contents of the tar archive on /dev/rmt/0 % tar xvf /dev/rmt/0 Extract the contents of the tar archive on /dev/rmt/0

Unix Backup Commands Another command that may be used to back up and restore files is cpio. The cpio command copies file archives “in and out.” The syntax for the cpio command follows. cpio -key [options] filename The key option to cpio determines the actions to be performed. The following flags are mutually exclusive. cpio -i (copy in): Extracts files from the standard input, which is assumed to be the product of a previous cpio -o. cpio -o (copy out): Reads the standard input to obtain a list of path names. The cpio command then copies those files to the standard output with path name and status information. Output is padded to a 512-byte boundary by default. cpio -p (pass): Reads the standard input to obtain a list of path names of files that are conditionally created and copied into the destination directory tree.

Unix Backup Commands % ls | cpio -oc >> ../newfile
NOTE: The find, echo, and cat commands can also be used as substitutes for the ls command to produce a list of files to be included in ../newfile. To extract the files from ../newfile, issue the following command. % cat newfile | cpio -icd % find . -depth -print | cpio -pdlmv newdir NOTE: When using cpio in conjunction with find, use the L option with cpio, and the -follow option with find.

Unix Backup Commands Yet another command available to use as a backup-and-restore utility is the dd utility. The dd command copies the input file to output, applying any desired conversions in the process. When complete, dd reports the number of whole and partial input and output blocks. dd [ option = value ] ....

Unix Backup Commands Do not use dd to copy files between file systems with different block sizes. Using a blocked device to copy a file will result in extra nulls being added to the file, in order to pad the final block to the block boundary. When dd reads from a pipe, using the ibs = X and obs = Y operands, the output will always be blocked in chunks of size Y. When bs = Z is used, the output block size will be whatever could be read from the pipe at the time.

Unix Backup Commands if = filename: Use filename as the input file. stdin is the default value. of = filename: Use filename as the output file. stdout is the default value. ibs = n: Use n as the input block size. 512 is the default value. obs = n: Use n as the output block size. 512 is the default value. bs = n: Use n as the input and output block size This supersedes the ibn and obn arguments. If no conversion is specified, preserve input block size. files = n: Copy and concatenate n input files before terminating. skip = n: Skip n input blocks before performing copy. iseek = n: Seek n blocks from the beginning of the input file before copying. oseek = n: Seek n blocks from the beginning of the output file before copying. count = n: Copy n input blocks. swab: Swap every pair of bytes. sync: Pad every input block to ibs.

Unix Backup Commands # dd if=/dev/rdsk/c1t3d0s2 of=/dev/rmt/2 bs=20b
# dd if=/dev/rmt/2 of=/dev/rdsk/c2t1d0s2 bs=20b

Windows Backup Commands
Like its UNIX cousins, Windows provides a utility to perform file system backups. The Windows backup-and-restore utility (backup.exe) provides for backups, and restores. In backup mode, the operator is given the ability to select which disk and/or files to back up, whether the local registry should be dumped, whether the backup should use compression, and what users may read the backup tape(s). Otherwise, the “menu” of backup options available to the operator is pretty limited.

The Options menu under the Tools menu allows the operator to determine the type of backup to be performed, whether data should be verified after the backup is performed, the amount of detail supplied in the log files, whether new media should be used, backup scheduling, and other configuration parameters for the backup utility.

The Windows backup utility also provides the interface to the restore function. In restore mode, the utility displays a catalog of the tape, allowing the user to select which files/directories need to be restored. The operator is also given the choice of where the file is to be restored. Although the GUI may simplify the setup of Windows backups, it also limits the choices available to the operator. Because this utility is based on the backup utility offered in the consumer versions of Windows, the sysadmin at a commercial site may decide that the Windows backup utility is not the first choice for backup software at the site. Many third-party backup utilities are available for Windows systems, including Amanda, Legato Networker, and the Veritas backup suite.

Dealing with Specific Backup Issues
Certain aspects of successful backup and restore strategies require special attention. For instance, how could the operator restore the root file system if the root disk had crashed and there was no way to boot the system? Many administrators are also concerned with how to automate backups to minimize time investment while ensuring successful backups. Next, what happens if a backup requires 2 Gb of backup media, but the backup device can write only 1 Gb to the media?

Restoring the Root File System One of the most difficult problems faced when using restore is restoring the root file system. If the root file system is missing, it is not possible to boot the damaged system, and there would not be a file system tree to restore to. One way to accomplish a root file system reload is by booting the system to the single-user state from the CD-ROM distribution media. Another way to reload the root file system would be to boot the system to the single-user state as a client of another system on the network. Another method of restoring the root file system is to remove the disk from the system, and attach it to a working system.

Multi-volume Dumps Two of the backup commands mentioned in this chapter also allow for multi-volume backups. The dump command and the cpio command allow a backup to be stored over multiple media sets. The other commands (tar and dd) will allow the user to split the backups onto several sets of media, but these commands require that the user perform much of the work manually. The cpio command watches for the “end of medium” event. When cpio detects this event, it stops and prints the following message on the terminal screen. If you want to go on, type device/file name when ready. To continue the dump, the operator must replace the medium and type the character-special device name (e.g., /dev/rdiskette) and press Enter. At this point, the operator may choose to have cpio continue the backup to another device by typing the device’s name at the prompt.

Multi-volume Dumps Using dump as the backup command is somewhat simpler. Like cpio, dump will detect the end-of-medium event and stop operation. The dump command will then wait for the operator to change the medium before it continues. Unlike cpio, dump does not need the name of the backup device to continue. The operator simply needs to confirm that the medium has been changed and that everything is ready for dump to continue operation.

Automated Backups Cheap and Dirty #!/bin/sh
# dump /, /usr, /var, /home, /opt, /orasoft # mt -f /dev/nst0 rewind dump 0bdfu /dev/nst0 /dev/ida/c0d1p2 dump 0bdfu /dev/nst0 /dev/ida/c0d2p1 dump 0bdfu /dev/nst0 /dev/ida/c0d3p1 dump 0bdfu /dev/nst0 /dev/ida/c0d4p1 dump 0bdfu /dev/nst0 /dev/ida/c0d5p1 dump 0bdfu /dev/nst0 /dev/ida/c0d1p3 mt -f /dev/nst0 offline # sh -x /dodump TIP: Although it is possible to perform the last file system backup to the “rewind” tape device (/dev/st0), this often leads to errors when the backup script is modified. If all backups use the “no-rewind” tape device, and the rewind and off-line operations are explicit system calls, the likelihood of operator errors should be minimized.

Cross Platform Backups
Several utilities are available for cross-platform backups: Veritas Legato Networker RaxCo Amanda – free –

Summary This chapter explored the commands that can be used to make backup copies of system data, why it is important to make such backup copies of data, and selected methods of avoiding data loss due to natural or other disasters. The authors hope that readers never have to use any of these backup copies to restore the operation of their systems, but such restorations are inevitable. Good backups require a lot of time and attention, but having a reliable copy of data is much more acceptable than the time and expense of rebuilding a system without such backup copies.

Managing Printers Chapter 14

Chapter Objectives Understand printing terminology and concepts.
Understand print server requirements and configuration. Understand print client requirements and configuration. Understand how to configure homogeneous printing. Understand how to configure heterogeneous printing.

EWWWWWW, YUCK, GROSS! Printing Printers
Managing printing can be quickly summarized in the words of Calvin (of Calvin and Hobbes): EWWWWWW, YUCK, GROSS!

Printing Printing Overview (in a perfect world)
User creates file, wants to print it. User calls system utility (lp, lpr, print) to print out the file. The utility sends the print job to a print spooler. The print spooler sends the job to the printer. Things rarely work this easily!

Printing Printers Local Vs Remote vs Network printers
A local printer is one which is connected to “this” system. Most local printers are connected to a serial port (RS/232, USB, or Firewire) or a parallel port. The local system needs to know the capabilities of the printer, and which port the printer is connected to. If this system is a print spooler it also has to know what other systems/users are allowed to send jobs to the printer. A remote printer is a printer connected to “some other” system. The local system needs to know what system the printer is on, how to send the print job to the other system, and the name of the remote printer.

Printing Printers A network printer is a printer connected to the network, but not necessarily associated with any system. Network printers include their own spooler, so all systems on the network could print directly to the printer. This can cause interesting problems. Usually have to load vendor drivers on every system. New manufacturers often get this part wrong!

Printing Printer Setup (BSD)
All printing processes are controlled by the lpd daemon, and the lpr program. Lpr accepts input to be printed and places it in a spool directory. Lpr selects where to store the print job, based on the name of the printer the user wants to send the job to. The print spool area is in /var/spool Lpr creates two files in the spool directory for each job. These files are named cfXXX and dfXXX where xxx is the print job number. The control file (cfXXX) contains reference and handling information for this print job.

The data file (dfXXX) contains the information to be printed. Once lpr places files in the spool directory, it notifies lpd that it needs to wake up and print the job. Lpd “finds” the entry in the spool directory and looks up the printer in the /etc/printcap database. The /etc/printcap file contains an entry for each printer the system has access to. The printcap file specifies the printer capabilities, which machine is the print spooler for the printer, the names/locations of any filters to be used for this printer, and line discipline information for this printer.

If printcap says the printer is local, lpd checks to see if a daemon is running for that printer (or starts a daemon if none is present). Once lpd knows the printer capabilities, and that this machine is the spooler, lpd creates a series of pipes between the spool file and the printer device driver. If a filter program is specified for this printer, lpd places connections to this filter between the print spool area and the printer. The (filtered) data is sent to the printer by the device driver.

Printing Printer Setup (BSD) If printcap says the printer is a network printer, or a remote printer, lpd opens a connection to the remote machine’s lpd, and transfers the data and control files to the remote machine. lpd then deletes the local copies of these files.

Printing lj254-grayscale:\ :sh:\ :ml=0:\ :mx=0:\
:sd=/var/spool/lpd/lj254-grayscale:\ :af=/var/spool/lpd/lj254-grayscale/lj254-grayscale.acct:\ :lp=|/usr/share/printconf/util/jetdirectprint:\ :lpd_bounce=true:\ :if=/usr/share/printconf/util/mf_wrapper: lj254-color:\ :sd=/var/spool/lpd/lj254-color:\ :af=/var/spool/lpd/lj254-color/lj254-color.acct:\

Printing Printer and Print Job Management (BSD)
The lpq command allows the users to view a list of entries in the print queue. lpq -P name views the entries for printer referred to as name. The lprm command allows a user to remove (their own) jobs from the print queue. The lpc command allows the administrator to manage the lpr/lpd environment. NOTE: lpc has the distinction of winning the “flakiest program of the year” award five times in 15 years! Lpc has not been improved (thereby getting it off the honors list), instead other programs have been released which are even flakier!

Printing Printer and Print Job Management (BSD)
lpc allows the administrator to: enable or disable queuing for a printer. enable (start) or disable (stop) printing on a printer. The abort command is a harsh version of stop (current job is not completed). Declare the printer down or up (these commands affect both spooling and printing). Remove all jobs from a printers queue (clean). Move a job to the top of the printers queue (topq). Manipulate lpd (restart). Get printer status information (status).

Printing System V Printing Overview
User wants to print file and invokes the lp utility. lp takes the input and places in the appropriate spool directory. lpsched determines when and where the file should be printed. lpsched launches a filter to format the output and send it to the printer. So far it looks just like lpr, right? The similarities end here!

Printing Printer Setup (System V)
All of the print commands are different between BSD and System V! To name a few: To print a file, use lp -d printer instead of lpr -P printer To remove a print job, use cancel instead of lprm To obtain print job status, use lpstat instead of lpq In order to remain consistently inconsistent, Sun created lpr, lpc, and lpq programs under Solaris. These programs are actually wrapper programs which call the appropriate System V commands and pass the data off to the lp system.

System V printer software defines destinations and classes of printers. A destination is (usually) a particular printer. A destination could also be a plain file that you want to append text to. Because lp uses exclusive locks on the printer “device” , this capability allows several users to append text to a file without concurrent access problems. A class of printers is a group of destinations. If you had two printers in a room, you could set them up as a class, and lp would print jobs to both printers (the first free printer gets the next job).

Printing System V Printing lp is the user-level print command.
lp (sometimes) copies (and sometimes links) the data to the spool directory files (/var/spool/lp/request/dest). Spool files are labeled xxxn where xxx varies depending on the OS. n is the print job number. lpsched takes the files in the spool directories and sends them to the appropriate device.

Printing Printer and Print Job Management (System V)
System V UNIX uses the lpadmin command to setup and administer printers. lpadmin is used to add/remove, start/stop, enable/disable printers much like lpc did in the BSD model. Most System V systems want lpsched stopped before lpadmin commands will work. As usual, Solaris had to be different. Solaris wants lpsched running before lpadmin commands will work.

lpadmin comes complete with a bag full of options: -d dest (make this the default printer) -x dest (remove printer dest) -p printer (tells lpadmin which printer to work with) -v device (append output for printer to file) -i interface (interface program for printer) -c class (add printer to class) -r class (remove class) -h (printer is hardwired) -l (printer is login terminal) -e dest (copy interface for printer to dest) -m model (copy model for printer to dest)

Once you add a printer with lpadmin, you have to tell the system to accept requests, and enable printing for that printer. Solaris also requires you to set the type of input that can be sent to a printer (any, simple, postscript, ...). This information is used to allow or deny printing based on the value of the magic number for the data file. Programs like Mentor that define their own file types cause problems with this model. You have to write a filter program to convert the “odd” files into a known/allowed file type in order to print them!

Printing #!/bin/csh -f lpsystem -t bsd -y "OIT print server" print.helios.nd.edu lpsystem -t s5 -y "CSE print server” babbage.cse.nd.edu lpadmin -p lp -s print.helios.nd.edu\!cse326 lpadmin -p lw384 -s print.helios.nd.edu\!cse384 lpadmin -p lj323 -s print.helios.nd.edu\!cse323 lpadmin -p eng_lab6 -s print.helios.nd.edu lpadmin -p eng_lab7 -s print.helios.nd.edu lpadmin -p eng_color1 -s print.helios.nd.edu foreach printer (lp eng_lab6 eng_lab7 eng_color1 lj323 lw384 ) lpadmin -p $printer -T unknown -I simple,postscript enable $printer accept $printer end lpadmin -d lp

System V printing software is a suite of programs to accomplish what BSD does with 3 programs: cancel - remove a print job accept/reject - tell system to accept/reject spooling jobs for printer. enable/disable - tell the system to allow/reject printing on this printer. Job is still spooled, just not printed. lpmove - move job to another printer. lpstat - get status of print job(s)

Printing Printing Problems and Solutions
The two basic print problems are: No Output: Check the obvious: Is the printer on? Does the printer have paper, ribbon, toner? Is the printer paper jammed? Will other jobs print? Check the lp user database. Determine if the print spooler can talk to the printer. Check the printer log files for clues.

Printing Printing Problems and Solutions Incorrect Output:
Check the printcap file (or lpadmin) to see if the printer type is correct. Make sure the line discipline matches the printer settings. Look at the filter files and see that they do what you think they are doing. Check the data file for odd character sequences.

Printing System software failure. Printing Problems and Solutions
Many times printing problems are due to software failures. These failures fall into two general categories: System software failure. lpd/lpsched has crashed/burned. Use the appropriate commands to stop the lp system, then restart the lp system and see if the problem disappears. If stop/restart does not work, try removing the first entry in the queue to see if lpd/lpsched work. If so, the problem is in the data file.

Printing Printing Problems and Solutions Data file problems.
Look for odd character sequences in the file. Try printing the file to another printer (same model if possible). Check filter program operation. Check job types allowed on the printer.

Printing Windows Windows also knows about local and remote printers.
Local printers are almost always connected to a parallel port. Local printers are added with the Printer Control Panel (Add Printer Wizard). You will probably need the OS media to install print drivers. Remote printers are handled similarly to the UNIX remote printers, but they require more setup: Use the Add Printer Wizard Add a printer port (defines remote spooler type) Add the printer like it was a local printer. If print server is a UNIX host, FIX the setup!

Printing Windows Unix does not like these control codes!
Windows/DOS wants to send printer control codes to the printer. These codes are part of the language the printer uses to speak to the PC. Unix does not like these control codes! On NT/Win2k systems (Win 95/98 have no TCP print driver): Go to the Document Defaults for the printer. Select the Advanced options. Select the Postscript Options. Set the system so that it does NOT send control codes. Set the system so that it does NOT send control-D after each print job.

Summary Configuring and managing printers should be easy.
Unfortunately, printer setup and management is not as easy as it should be. The lack of standards makes this task a problem for system administrators. Homogeneous printing is the simplest case. Heterogeneous printing is the most problematic. System administrators should understand how to: Configure print services under Windows, BSD and System V. Troubleshoot printing problems. Configure filters and advanced printing options.

Networks I Chapter 15

Chapter Objectives Understand basic network terminology.
Understand the basics of the TCP/IP protocol suite. Understand the basics of IP addresses. Understand basic IP routing. Understand the basics of ARP, and DNS. Understand the basics of layer 2 and layer 3 “routing”. Understand common network hardware.

Network Protocols Internetworking - the process of connecting two computer networks together. The interconnected networks may or may not use the same network technology. The interconnected networks may or may not be in the same location. The interconnected networks may or may not encompass the same hardware. The interconnected networks may or may not employ the same software. The Internet is one example of internetworking.

Network Protocols WARNING:
Networking seems to encompass every two, three, four, five, and six character combination of letters into an acronym.

Network Protocols (ISO)
The International Standards Organization adopted a networking model called the Open System Interconnect. This network model breaks the task of networking down into seven layers (then arranged them like a top-ten list): 7) Application layer - Provide end-user services 6) Presentation Layer - Deal with problems & compression 5) Session Layer - Authentication and Authorization 4) Transport Layer - Guarantee end-to-end (correct) delivery 3) Network Layer - Routing and Accounting 2) Data Link Layer - Transmit/receive packets & addressing 1) Physical Layer - The cable or media itself

Network Protocols (ISO)
The ISO/OSI model was the result of design by committee. The layers had little base in reality: They did not match real-world protocol stacks. The ISO/OSI model suffered a horrible “death” (nobody could make it work). Network theory courses still hold the ISO model up as the “right way to do things.”

Network Protocols (TCP/IP)
Internet Protocol (TCP/IP model) The TCP Protocol is designed around a simplified four layer approach: Link Layer - Network hardware and device drivers Network Layer - Basic Communications, addressing, routing The network layer protocol is the Internet Protocol (IP). Transport Layer - Communication among programs on a net. There are two data Transport protocols In TCP/IP: User Datagram Protocol (UDP) Transmission Control Protocol (TCP) Application Layer - End user application programs Utilities like ftp, ssh, rlogin, rsh, DNS, NFS, CIFS, …

In order for all of the computers on the Internet to communicate, we have to: Ensure that the computers speak the same language. The language used on the Internet is TCP/IP. IP is the Internet Protocol IP provides a communication channel, including addressing, and routing. TCP is the Transmission Control Protocol. UDP is the User Datagram Protocol.. TCP and UDP provide data delivery over the IP channel. Ensure that each network device has a unique address. Ensure that the computers have access to some form of bridging hardware in order to connect dissimilar network technologies.

Internet Protocol (Packets) As a packet travels through the levels of the TCP/IP protocol, each layer adds it’s own header information to the datagram. This process of each layer encoding it’s own management information into the existing datagram is called nesting, or encapsulation. Various headers contain the source and destination address, checksum, protocol specific information, and other handling instructions. At the receiving end the headers are stripped off by the appropriate level, the header contents are examined for special handling information, and the datagram is delivered to the appropriate application.

Internet Protocol Version 4 (IPv4) An IP address consists of four byte values separated by periods. For Example: This notation is also known as the dotted quad format. Each of the values must be in the range of (8 bits). An IPv4 address is therefore 32 bits (4 bytes * 8 bits/byte). There are five classes of IP Addresses in IPv4: Class A, B, and C addresses are used for single host addressing. Class D addresses are used for multicast connections. Class E addresses are experimental.

Internet Protocol (IPv4) Class A Networks - The first byte is in the range of The first four bits of the address are Binary 0 X X X There are 127 Class A networks. The first byte of a class A address is the network number. The remaining three bytes are the host address on that network. network host address Each Class A network can address up to 16 million hosts. All Class A networks are currently assigned and in use. (lie)!

Internet Protocol (IPv4) Class B Networks - The first byte in the range of The first four bits of the address are BINARY 1 0 X X There are 16,384 Class B networks. The first two bytes of a class B address are the network number. The remaining two bytes are the host address on that network. network host address Each Class B network can address up to 65,000 hosts. Notre Dame holds a Class B license ( X.Y) All Class B networks are currently assigned and in use. (lie)!

Internet Protocol (IPv4) Class C Networks - The first byte in the range of The first four bits of the address are X There are 2,097,152 Class C networks. The first three bytes of a class C address is the network number. The remaining byte is the host address on that network. network host address Each Class C network can address up to 254 hosts. Most of the Class C networks are assigned and in use.

Internet Protocol (IPv4) Class D Networks - The first byte in the range of The first four bits of the address are These addresses are used for “one to many” communications (multicasting). Class E Networks - The first byte in the range of The first four bits of the address are These addresses are reserved for experimental use by the IANA/IETF.

The numbers 0, and 255 have special meaning in some fields of IP addresses. A Zero host address refers to “this network” For example refers to the Class B network A host address of all ones is called the broadcast address. For example refers to all hosts on the Class B network. The address is the loopback address. This address is used for inter-process communications, and for network testing. All of the 127 network is reserved ( ).

Subnets and Supernets Subnets provide a way of chopping up large networks into smaller entities: Networks might be split up to segment traffic. Networks might be split up to facilitate better use of an assigned IP address space. A class A could be made to look like several class B/C networks. A class B could be made to look like several Class C networks. Even a Class C network can be sub-networked. To subnet a network, we apply a netmask. Standard netmask for Class A is Standard netmask for Class B is Standard netmask for Class C is By logically ANDING the address and the netmask, we can determine the NETWORK portion of the address. Discuss how packets get to a classful destination

Subnets Network routers look at the destination IP address, and the netmask for the address to make delivery (routing) decisions. Once the router determines the class of the destination address, it consults a table to find the appropriate netmask. Class A netmask is Class B netmask is Class C netmask is For example, a packet bound from a random host on the Internet, to my office host would generate the following operation: = = == or /16

The lab network is subnetted into several smaller networks. By “stealing” bits from the host number, we can make the network number larger. This allows us to make a class B or C network look like many smaller (classless) networks. These networks are denoted by the formula N.S.H (network.subnet.host) By using a 27 bit netmask we can divide a network up into several “32” host networks 27 bits of network address, 5 bits of host address. through is one such network. through is one such network. through is one such network. /27 denotes a host on a classless network which employs a 27 bit netmask. This is referred to as Classless InterDomain Routing (CIDR)

Subnets and Supernets Supernets allow us to aggregate several smaller networks into one larger routing entity: This is the opposite of subnetting. Supernetting is employed to minimize routing table entries. If an ISP has a customer who needs addresses for 400 hosts, a single class C address will not suffice. By combining two class C networks, the ISP can make a single routing entity: = = The first 23 bits are the same for both addresses so the ISP can advertise a single external route: /23 This only works if the ISP also owns and

Classless Inter Domain Routing (CIDR) CIDR is the result of incorporating subnetting and supernetting into the classful IP address structure. We are no longer limited to class A, B, and C addresses. By passing the netmask along with the address we can make arbitrarily large/small networks, as we see fit, to simplify routing and network design. CIDR allows simplified routing tables. CIDR is the basis of IPv6. You may also hear the term Variable Length Subnet Mask (VLSM). This is the practice of using various length subnet masks within a single network domain.

Internet Protocol (IPv4 trivia) We are running out of addresses under the current (IPv4) addressing scheme. If every class A, Class B, and Class C network address was in use using classful addresses, there would be ((127 * 16,000,000) + (16384 * 65,000) + (2,097,152 * 254)) (or 3,629,636,608) hosts on the Internet. (3.6 gigahosts) The remainder of the addresses are the “zero”, and “broadcast hosts (overhead). If subnetworking is in use, even more of the address space is lost to “overhead”. Real Soon Now a new version of IP will be released. This version is known as IPV6 (Internet Protocol version 6).

IPv6 Addresses go from 32 bit to 128 bit. Addresses will be colon separated hexadecimal quads: 0xFEDC:BA98:7654:3210:0123:4567:89AB:CDEF 0x0000:0000:0000:0000:0000:FFFF: Shorthand ::FFFF: IPv6 will not contain address classes – but prefix ranges will have meaning (geographic regions). IPv6 will use multicasts instead of broadcasting. IPv6 will use CIDR routing IPv6 will facilitate data encryption IPv6 contains provisions for new services (bandwidth reservation, guaranteed signal quality, more multicasting) IPv6 will provide 340 undecillion addresses 340 with 24 zero’s after it

Internet Protocol (packet delivery) The Internet protocol actually uses multiple layers of addressing to deliver packets. Protocol addressed packet delivery is referred to as ISO Layer 3 (Network layer) routing. In addition to the IP address, each network adapter card is assigned a unique hardware address (Media Access Controller or MAC address). Ethernet MAC addresses are 6 bytes long. MAC addresses of other network technologies vary from 2 bytes to 20 bytes in length. The mapping between the MAC address and the IP address is handled at the Link Layer of the TCP/IP stack by the Address Resolution Protocol (ARP).

Address Resolution Protocol By design, the network interface (the board in the host) wants to communicate with another network interface board. Network interface boards work with multiple protocols. This means that they must have a way of addressing other NICs that is independent of the software protocol address. All packets on the media are addressed to another MAC address. If the packet is bound for a host not known to the local host what happens? One way to resolve such a MAC address is for the host to send out a broadcast packet saying “Hi, I’m at MAC address x:y:z:a:b:c, how do I get to MAC address f:g:h:i:j:k?”. If the host with address f:g:h:i:j:k is on the same network, it will reply and the address is resolved.

Otherwise an intermediate can be programmed to reply “send the packet to me, and I will forward it for you.” In this case the packet is sent from the host’s MAC address to the MAC address of the intermediate! source addr = host MAC, destination addr = intermediate MAC The intermediate then forwards the packet on the way to the final destination. source addr = intermediate MAC, destination addr = next hop MAC The host software maintains a table (the ARP cache) of these MAC addresses. This is ISO layer 2 (Data Link Layer) routing (switching)

Internet Protocol (packet addressing) IP addresses identify machines. This allows us to get a datagram from one host to another. How do we deliver data to programs and services on these hosts? The TCP and UDP protocols extend the IP addressing concept through the use of “ports”. A port is a two byte number that identifies a particular service. These port numbers are mapped to services through the /etc/services file. Ports with numbers less than 1024 are called privileged ports. These ports are (supposed to be) only accessible by root, in an attempt to prevent impostors.

Internet Protocol (packet addressing) Because humans have a difficult time dealing with all of these numbers (MAC address / IP address / Port number), the computers/services are also allowed symbolic names. Computers do not understand these names…the computer wants to work with numbers. The names are mapped to numbers by a variety of means. The most commons means of mapping system names to IP addresses are the /etc/hosts file, Network Information Services (NIS), and the Domain Name Service (DNS). I will talk more about how these name services work in a few days.

Other Protocols NetBEUI Net Bios Extended User Interface
An extension of NetBIOS. Not a routable protocol, as it has no network layer. Can have bridged networks, but not routers. Relies on broadcasts for many functions. Connection Oriented - Connectionless communications Self configuration - self tuning Error protection Small memory overhead Active Directory cannot use NetBEUI.

Other Protocols NetBIOS over TCP/IP (NBT)
Replaces NetBEUI, allows applications to use TCP/IP Winsock Interface between socket based applications and TCP/IP. Server Message Block (SMB) networking. Used in previous versions of Windows. Basis for Windows file and print sharing. Uses NetBEUI - not routable. Relies on Windows Internet Naming Services (WINS). Being replaced by Common Internet File Service (CIFS). TCP/IP based networking for Windows! Both SMB and WINS are unpublished protocols. Can change on a whim!

Other Protocols AppleTalk
Originally developed by Apple as a printer sharing protocol. Later expanded to allow more complete network services. Very little administration required. Hardware address is used, no IP address required. Plug in a new machine, and it works! The new node sends a broadcast packet that says “Hi!, I’m Joe. I want to use address X. Does anyone object?” If there is no objection, Joe is now at address X. If there is an objection, the node with the lowest address sends back a message stating “Hello Joe. I’m sorry, but you will have to use Y as your address, as X is already in use.” Routers are very complex. Works with a variety of hardware and media. Twisted pair, coaxial cable, Ethernet, PC’s UNIX hosts.

Other Protocols EtherTalk Actually AppleTalk over Ethernet.
Two flavors are available: Phase 1 was Apple’s first Ethernet network. It was very buggy, and tended to flood the network with broadcast packets. Phase 1 also had it’s own packet types which were not known by TCP/IP. Phase 2 changed the broadcast packets to Multicast packets, and encapsulated their odd packets as acceptable packets.

Other Protocols LocalTalk
Is actually Apple’s AppleTalk protocol implemented on twisted pair cabling. AppleTalk was originally implemented with an odd coaxial cable. Network speed reaches a blazing 230 Kilobits/second! LocalTalk allows star topology with active or passive hubs and multiple hosts on a leg. Ethernet to LocalTalk bridges are very common. MacIP is used to encapsulate Ethernet packets in LocalTalk packets.

Other Protocols AppleTalk
AppleTalk addressing uses a multi-layer address system like IP. The MAC address is hardware based. The Node number is dynamically assigned by AppleTalk Address Resolution Protocol (AARP). AppleTalk networks are grouped into zones. Each AppleTalk entity has an object name (Billy Bob’s Office Printer), an object type (LaserWriter) as well as the zone name. The zone entities are bound to network and node numbers by the AppleTalk Name Binding Protocol (ANBP).

Other Protocols IPX IPX is the Internet Packet Exchange Protocol.
IPX was developed by Novell for the NetWare product. Novell is the most common network protocol in use for PC’s. Novell is in the process of converting the Novell Network to use TCP/IP protocol. Current IPX implementations use standard Ethernet packet headers. Older versions of IPX used non-standard Ethernet packet headers, and would not co-exist on a network with non-IPX Ethernet packets.

Other Protocols IPX IPX was derived from The Xerox Network System Internet Datagram Protocol (XNS IDP). IPX uses a UDP like packet type. Headers have an unused checksum field, a packet length, packet type, a hop count, and the network, node, and socket numbers of the source and destination machines. IPX packets are thrown away after 15 hops! IPX is not a standardized protocol! It is a proprietary protocol and is subject to frequent unannounced changes. Novell Loadable Modules (NLM’s) are available to add functionality to Novell IPX based networks.

Other Protocols IPX Routing Information Protocol (RIP)
The IPX protocol has many “helper” protocols: Routing Information Protocol (RIP) Sequenced Packet Exchanger : reliable delivery (SPX) ECHO (a packet echo facility) ERRORS (an error reporting facility) Packet Exchange Protocol (PEP) VERY inefficient, as it requires an ACK for each packet before the next packet is sent! On top of PEP are the Network Core Products which provide authentication, file service, RPC, print spooling, accounting). Service Advertisement Protocol (SAP) (address broker)

Other Protocols DECnet
DECnet is an implementation of the Digital Network Architecture (DNA) DECnet first appeared in The first version to support Ethernet was DECnet phase IV released in 1984. DECnet Phase V was released in 1991 and is referred to as DECnet/OSI. It supports TCP/IP, OSI, and Digital’s Network Services Protocol (NSP).

DECnet Addressing is somewhat different from the other protocols: DECnet addresses are independent of the transport media. A DECnet address is a one byte “area” and a two-byte node number. An area is a logical grouping. One area may equate to one or more networks. One network may contain one or more areas. The machine’s address is derived from the area and node number, not the hardware MAC address. All interfaces on the system use the same address!

Until DECnet Phase V all routing tables were static. Static routing limited DECnet to small network configurations. DECnet Phase V implemented dynamic routing via DECdns which is actually a distributed routing protocol. The routing is performed by DECnet routers. A level one router routes information within one area. A level two router routes information between two areas.

Protocol Translators As you may have guessed by now, there are ways to make systems running these “other” protocols talk to a TCP/IP network. Some of these protocols include TCP/IP modules. Other protocols use a trick called “tunneling” to allow them to “talk on” TCP/IP networks. Tunneling is a form of packet encapsulation. In order for tunneling to work, the source and destination machines have to be on the same type of network. There may be one (or many) other types of networks between these two hosts and their networks. Another method of interconnecting dissimilar networks requires special hardware/software which acts as a translator (bridges).

Network Hardware Working With Current Network Hardware
So far all we’ve talked about is the software side of networking. We saw that there are many different protocols in use on current communications networks. There is also a hardware component to networking. Unfortunately, there are almost as many hardware standards as there are protocols. We will talk about four types of network hardware: Ethernet Token Ring FDDI (token ring in disguise) ATM

Network hardware has to take proximity into account. Local Area Networks (LANs) consist of machines in close proximity to each other. Example: Notre Dame campus, or networking within a small company building. LANs typically employ high speed technologies ( 1Mb - 10 Gb / second throughput). Metropolitan Area Networks (MANs) - consist of machines within a metropolitan area. Notre Dame could also be considered a Metropolitan Area Network. MANs typically operate at lower speeds (56 Kb Mb / second throughput).

Wide Area Networks (WANs) consist of machines separated by large distances. Example the Internet. WANs typically operate at rates of 56 Kb to 622 Mb / second throughput. The type of hardware selected for a network must be capable of working within the boundaries of the particular network.

Ethernet - developed by Xerox in the 1970’s. Still has bugs! Ethernet is the most common network technology. Ethernet employs Carrier Sense Multiple Access with Collision Detect to determine who gets to talk at any given time. Ethernet does not include built-in error detection/correction. That is left to the software! Most of the protocols we discussed run on Ethernet hardware. Ethernet is a LAN technology that the users wanted (desperately) to become a WAN technology.

There are many flavors of Ethernet available: Thicknet - 10Base-5 - Screaming Yellow 50 Ohm Coaxial cable. Attachment Unit Interface (AUI) connectors (DB15). This is the oldest form of Ethernet. Length Limit 500 Meters / segment. Up to three segments connected via repeaters. 10 Mb/s shared bandwidth

Thinnet - 10Base-2 - cheapernet, Cheap coaxial cable cheap BNC style connectors. length limit: 200 Meters/segment. Up to two segments connected via repeater. Multiport repeaters allowed. 10 Mb/s shared bandwidth

10Broad36 - Broadband Ethernet. Not used very often EXPENSIVE Multiplex Ethernet packets onto a broadband carrier system. 36 Kilometer length limit Cable modems use similar technology.

10BaseF - Fiber based Ethernet. Two fibers required (one for transmit, one for receive) Optical to copper repeaters handle the collision detection. Typical segments 2.2 Km maximum. Multiple segments may be connected via repeaters Two repeaters/route maximum 10 Mb/s shared bandwidth

10 BaseT - Twisted pair Ethernet Category 4 or Category 5 twisted pair wiring, or fiber. Star topology - all hosts connect to hubs/routers/switches. Length limit: 100 meters per connection, 500 meters between the two most distant hosts (if shared bandwidth). Cheap RJ45 connectors (telco style) 10 Mb/s shared or switched bandwidth Switched connections allow full 10Mb/s to the host instead of shared bandwidth. Connections can be “full duplex”

100BaseT - Twisted pair Ethernet Category 4 or category 5 twisted pair wiring, or fiber. Star topology - all hosts connect to hubs/routers/switches. Length limit: 100 meters per connection Cheap RJ45 connectors (telco style) 100 Mb/s switched bandwidth Switched connections allow full 100Mb/s to the host instead of shared bandwidth. Half, or Full Duplex connections.

Token Ring Networks Token Rings utilize a special data structure called a token to determine who gets to talk. Token Rings are typically built on a copper based media. Token Rings are very common on PC systems, but not found very often on UNIX systems (with the exception of FDDI/CDDI). Token Ring systems have two modes of operation: receive and transmit. Typical Token Rings run at 1, 4, 10, or 16 Mbit/second.

Fiber Distributed Data Interconnect (FDDI) FDDI is a token ring in disguise. FDDI uses fiber optical cabling instead of copper. Copper Distributed Data Interconnect (CDDI) is FDDI over copper. FDDI is capable of 100 Mbit/second data rates. Single Attachment Stations (SAS) require a pair of fibers and have little fault tolerance. SAS FDDI networks are star-topology networks. Dual Attachment Stations (DAS) provide for fault tolerance and require two pairs of fibers. DAS FDDI networks are ring topology networks.

Automatic Teller Machines (ATM) ATM networks have been in use for many years by the banking industry. Users put a card in a slot and can magically get money out of the ATM machine. OOPS. Sorry. Wrong ATM!

Network Hardware ATM is part of a larger network:
SONET (Synchronous Optical Network) is used for (extremely) high speed connections between telephone switches. Current Telco operations can handle 100 Gigabit/second over SONET. Test frames currently running at 350+ Gb/second! Computer network hardware is available which allows you to use SONET connections between systems. SONET is VERY expensive! Picture of SONET with ATM/ISDN/DSL/Voice

Asynchronous Transfer Mode (ATM) The basic foundations for ATM were developed by people who know about wide area networks and packet switching: Long Distance Telephone carriers. ATM is the underlying technology behind the Broadband Integrated Services Digital Network (B-ISDN). B-ISDN is part of the “send a fax from the beach, tuck your kids into bed from around the world” technology. ATM is currently running with 622Mbit/second links. High-end Internet links are running at 155 Mbit/second. NOTE: Most hosts cannot drive such links at speeds over 350 Mbit/second. Fill those buckets

Network Hardware 25 Mbit/second IBM standard
Working With Current Network Hardware ATM comes in a variety of speeds. For example: 25 Mbit/second IBM standard 45 Mbit/second Digital Service-3 (DS3) (T-3) 51 Mbit/second SONET(OC-1) 100 Mbit/second Taxi interface 155 Mbit/second Optical Carrier-3 (OC-3) 622 Mbit/second Optical Carrier-12 (OC-12) 1.2 Gbit/second Optical Carrier-24 (OC-24) 2.4 Gbit/second Optical Carrier-48 (OC-48) Speeds are based on Telco transmission rates.

ATM encompasses the Integrated Services Digital Network (ISDN), ISDN is used for (relatively) high speed connections to homes and businesses. A typical ISDN connection is actually a multiple-channel connection over telephone wire. ISDN uses two B channels, and a D channel. The B channels are 64 Kb/second data channels. The D channel is a 9.6 Kb/second signaling channel. Current technology allows you to “bond” the two B channels together and use 4x data compression to get throughput up to 512 Kb/second.

xDSL technology (new) is similar to ISDN. ADSL (Asymmetric Digital Subscriber Loop) has one channel running at high speed, and one running at low speed (for example 512Kb/sec one direction, and 128 Kb/sec the other direction). ADSL has been tested at rates up to Mbit/second (same speed as a T1 link). ADSL runs over standard telco wiring (ISDN and DSL require some tweaks to run over telco infrastructure).

Because ATM is a telephone protocol, it has some odd “features” when used for data networking. ATM is a connection oriented service. No packets can be sent until a channel is opened. Ethernet/FDDI/Token Rings are all “connectionless”. IP is also connectionless. ATM sends/receives fixed length data cells, as opposed to the other technologies we discussed which send/receive variable length packets. Ethernet exchanges byte packets FDDI exchanges byte packets ATM exchanges 53 byte “cells” Each cell has a 5 byte header and 48 data bytes.

ATM Fun with International Standards: The European telephone industry wanted ATM to use 16 byte cells for voice traffic, but would compromise up to 32 bytes. The United States telephone industry wanted 128 byte cells for data, but would compromise down to 64 bytes. The CCITT split the difference, and ATM cells were defined to be 48 bytes. Because headers were already defined as no more that 10% of the cell, headers became 5 bytes.

Network Hardware ATM Result:
The ATM cell size is a poor choice for voice (packets are too big; bandwidth is wasted) The ATM cell size is a poor choice for data (packets are too small; bandwidth is wasted with excessive overhead). Welcome to the fascinating world of International Standards!

Summary Configuration, management, and troubleshooting network connections is a major portion of any system administrator’s job. The system administrator needs to: Understand basic network terminology. Understand the basics of the TCP/IP protocol suite. Understand the basics of IP addresses. Understand basic IP routing. Understand the basics of ARP, and DNS. Understand the basics of layer 2 and layer 3 “routing”. Understand common network hardware.

Network Configuration and Management
Chapter 16

Chapter Goals Examine and understand network configuration files.
Examine and understand network configuration utilities. Examine network monitoring utilities. Examine simple troubleshooting utilities.

Host Configuration General Network Configuration Procedure
To connect a host to the network, the administrator needs the following information. · Host name for the system · Domain name for the system · IP address for the system · Netmask for the network (if applicable) · Default router (gateway) for the network · Name service used on the network · Name or address of the machine providing name service Once you have this information, you can configure the machine and “plug it in” to the network.

Host Configuration Every operating system stores network configuration information in files. Fortunately, some of these files are common across multiple versions of UNIX. Some of these files specify information about the host’s address and host name, or unique setup parameters. Other files specify which network services the host will allow, and which other hosts on the network provide services the host may require. Many operating systems also provide access to the TCP/IP network stack variables in order to allow advanced network configuration.

Host Configuration Common UNIX Configuration Files
Network configuration information is stored in several files on the system. Most of the OS installers ask for the previously listed information and configure the system for network operation. Where is all of this information stored? How do you make changes to the network configuration without reloading the operating system?

Host Configuration /etc/hosts File
One of the most frequently used network administration files is the /etc/hosts file (/etc/inet/hosts on System V machines). Even Windows systems have a version of the hosts file, called lmhosts. The file is a registry of IP addresses and associated host names known to a system. At a minimum, it must contain the loop-back address ( ) and the IP address for the host. The hosts file is one of the resources consulted by applications in order to resolve a host name to an IP address when communications are requested. The format of host file entries follows. IP address<Tab>Fully.Qualified.Name<space>[host_alias]* grumpy.plc.com grumpy loghost Note the following in regard to the hosts file. A host may have several “aliases.” In the previous code, the host may be addressed as grumpy.plc.com,its fully qualified host name. The names grumpy or loghost are nicknames that it will also answer to. All hosts connected to the corporate network need not be listed in the hosts file. Typically, only those hosts routinely contacted are listed. For security reasons, root is the only user who can edit the /etc/hosts file. If a host routinely communicates with many hosts (e.g., more than a dozen) on the network, maintaining a large hosts file can become cumbersome. If this is the case, using an on-line distributed name service database system, such as the Domain Name System (DNS) or Network Information Service (NIS+), should be considered. WARNING: Trailing blank characters on a line in the hosts file may cause that entry to fail.

Host Configuration /etc/hostname.if_name File
Many versions of UNIX use files in the /etc directory to aid in the configuration of individual interfaces on the system. For example, Solaris uses files with the generic name /etc/hostname.if_name to simplify system configuration at boot time. The device name of the network interface is substituted for the if_name portion of the file name. For a host with an on-board hme Ethernet device, connected to a single network, the /etc/hostname.hme0 file would contain the host name to be used by that interface. Machines connected to multiple networks would have multiple /etc/hostname.if_name files. Solaris also uses a file called /etc/hostname6.if_name to configure any Ipv6 interfaces on the system. Each network interface will probably have a unique host name assigned to it. For example, a multi-homed machine with an hme0 and le0 interface on separate networks might be called thishost on one network interface and thishostthat_subnetwork on another. The /etc/hosts file should list both addresses for the host in order to facilitate mapping the unique interface names to an IP address. The following example shows the host name files for a host with two hme interfaces connected to two different networks. The host is registered as wazoo on one network and wazoo-206 on the second network. # more /etc/hostname.hme0 wazoo # more /etc/hostname.hme1 wazoo-206 WARNING: The name in the hostname.if_name file must resolve at boot time. It is wise to use IP addresses instead of the host’s name. Alternatively,] you can have an entry in the /etc/hosts file for each hostname.if_name entry on the machine. Failure to use resolvable names will result in interfaces that cannot be configured at boot time.

Host Configuration /etc/nodename File
System V machines may also employ another file to maintain an “alias” for the host on the network. The /etc/nodename file contains the “alias” name from /etc/hosts. For a multi-homed host, this allows the host to respond to service requests from all connected networks by a single host name. This requires users to remember only one name for the host, no matter which network interface they use to contact the host.

Host Configuration /etc/services file
The /etc/services file contains a list of network ports and services that correspond to those ports. For example, port 25 is defined as the SMTP port, whereas port 80 is reserved as the hypertext transport protocol daemon (httpd) port. To add a new service to a host, the administrator must add a port number and service name pair to the /etc/services file. In general, ports numbered 0 through 512 are reserved Internet protocol ports. These port numbers are assigned to particular services by the NIC. Port numbers between 512 and 1024 are generally recognized UNIX network service ports. These ports are not reserved, but are generally treated as though they were reserved port numbers. Port numbers above 1024 are unassigned, and may be used for local network services as required by the site. NOTE: The use of ports not assigned by the NIC may vary from site to site. Some sites may reserve a group of ports above 1024 for internal use. Checking with the local network administrator before assigning local ports and/or services is recommended.

Host Configuration /etc/inetd.conf File
UNIX provides two types of network service daemons: persistent daemons, which are started by run control scripts and are always running, and “part time” services that are only launched when required. These “part-time” services are controlled by the inet daemon (inetd, or xinetd under Linux). The persistent inetd daemon reads the inetd.conf file when it is started. The inetd.conf file tells inetd the ports it should listen on. Once inetd is running, it monitors incoming network packets for service requests on the ports under its control. When a request is received, inetd launches the daemon listed for this port in the inetd.conf file. You may want to limit the service requests a machine answers. This is done by removing the service from the /etc/inetd.conf file (or by removing the file from /etc/xinet.d) and restarting inetd/xinetd. Conversely, to add a new service to a host, add information to the /etc/inetd.conf file (or add the appropriate configuration file to the /etc/xinet.d directory) and then restart inetd/xinetd. TIP: It is sometimes possible to send a signal to the inetd process to cause it to reread the configuration file. This is achieved by sending a kill -HUP signal to the process ID (PID) of the running inetd process. For example, if the inetd process is running with a PID of 73, the command kill -HUP 73 should cause the inetd process to reread the configuration file.

Host Configuration /etc/resolv.conf File
Most versions of UNIX use the information in the /etc/resolv.conf file to configure the name service client on the host. The file consists of keywords and values. Some of the more common keywords follow. domain: DNS domain of this host nameserver (up to three allowed): IP address of the name server(s) this host should contact. The preferred name server should be listed first. search: List of up to seven domains the system should search when trying to resolve an unqualified host name.

Host Configuration /etc/nsswitch.conf File
The /etc/nsswitch.conf file, also known as the service switch file, is used to tell the system which order it should try to resolve host names. Linux also uses the /etc/host.conf file for this purpose, and BSDI uses the /etc/host.conf file to determine resolution order. These files consist of keywords and values. Some of the more common entries follow. hosts: files dns ipnodes: files dns passwd: files ethers: files netmasks: files bootparams: files services: files aliases: files netgroups: files The files entry tells the system to check the configuration files located on the host’s file systems. The dns entry tells the host to try to resolve host names using the DNS if the host name was not found in the local configuration files. Some systems allow for more complicated processing of the service switch file. For example, many operating systems allow the administrator to explicitly state what should happen in the case of lookup failures. Solaris and HPUX allow the following result/action values in the service switch file. [NOTFOUND=action]: Causes the lookup to perform the action if the preceding service could not perform the resolution [SUCCESS=action]: Causes the system to perform action upon a successful lookup [UNAVAIL=action]: Causes the system to perform action if the resolution method was not available [TRYAGAIN=action\]: Causes the system to perform action if the resolution method was busy, or not responding Note that the action taken upon satisfying the condition may be return or continue. The return action tells the system to return a failed status, whereas the continue action tells the system to try the next resolution method in the list. In addition, the TRYAGAIN keyword allows the action forever, with an optional limit on the number of times the action will actually be retried.

Host Configuration Common UNIX Configuration Commands
Different versions of UNIX provide several methods for the administrator to enter system network configuration information. During the installation of the operating system, the installation procedure may prompt you for network information and build the files as required for the installation. Once the system is up and running, other methods and utilities are available for updating network information.

Host Configuration ifconfig
The ifconfig command is used to bind the IP address, host name, net mask, broadcast address, and other network configuration parameters to a particular network interface. The ifconfig command is run at boot time by the startup scripts called by the init process. Unfortunately, every vendor has added its own options to the ifconfig command, with the list of options growing daily. This fact makes it almost impossible to tabulate all options available for every operating system environment. You can use the ifconfig command to examine and/or modify interface parameters while the system is up and running. When issued with the –a flag, ifconfig prints the configuration information for all interfaces. Note that IPv4 and IPv6 information is listed separately on dual-stack hosts. Because the implementation details may differ on various versions of UNIX, it is best to consult the ifconfig manual page on your system for more information on this command.

Host Configuration route
The route command is used to add and manage static routing tables on the host. Static routes are, as the name implies, routes that should not change very often. Many sites configure their systems to send all packets to the site/building/group router nearest the host’s location. The routers then decide how to deliver the data to the final destination. The route command allows the administrator to manually add a static route to this “default gateway” router. The generic call to the route command is as follows. route [-f] keyword [type] destination gateway [metric] The –f flag is used to flush the routing table of all entries. Some operating systems use route –flush instead of route –f. The keyword field indicates the operation to be performed. Keywords available in all versions of the route command include the following. add: Add the specified route. delete: Delete the specified route. Some versions of route also support the following keywords: get: Look up and display the route for a destination. change: Change some aspect of the route (for example, change the gateway). flush: Remove all entries from routing tables. Monitor: Continuously monitor and report changes in the status of routing tables, routing hits and misses, and suspected network partitioning. The type field indicates whether this route is a host route or a network route. Because the route command may not have knowledge of local subnet masks, the administrator should always specify whether the route is a host or network route. Note, however, that some versions of the route command will consult the /etc/networks and /etc/netmasks files in an attempt to determine local subnet masks, and therefore assign the “proper” type of route if the type is not specified. Note also that some operating systems require a hyphen before type field. The values allowed in the type field are therefore limited to the following. [-]host: Route to a specific host [-]net: Route to a network

Host Configuration The destination field contains the IP address of the route’s destination. This could be a host address (for example, ) or a network address (for example, ), as specified by the type field. The gateway field specifies the address of the router that provides the gateway service for this route. This field may contain the IP address of a host, the IP address of a network, or the string default. The IP address of may also be used in place of the string default. Packets bound for a destination that does not have an explicit route in the host’s routing tables use the default route. The metric field gives the administrator a way to assign precedence to the routes in the routing table. For example, a host with multiple network interfaces may have static routes to multiple gateway routers. If one of these routes included a path with higher bandwidth, the administrator might want to force the traffic to use this route unless the link was down. By assigning a low metric value (typically 1) to the preferred route, and a high metric value (something greater than 1) to the slower link, the system would use the preferred route most of the time.

Host Configuration OS-specific Network Configuration Information
WARNING: Check the manual page for the route command on your system for any nonstandard behavior in that environment. For example, the BSDI kernels do not allow a metric value, but will gladly accept the value at the end of the command as a net mask. This is rarely what the administrator had in mind when configuring the host! OS-specific Network Configuration Information There are no specifications that force UNIX OS vendors to use common file names and content to configure the system. This includes the numerous network configuration files on today’s UNIX hosts.

Host Configuration Solaris /etc/defaultrouter
Solaris provides a plethora of files that are involved in the configuration of networking. In fact, Solaris is probably the most difficult OS to deal with when configuring networking due to the number of configuration files and utilities that seem to be randomly scattered through the file systems. /etc/defaultrouter This file contains the IP address of the default router (gateway) for this host. A sample defaultrouter file might appear as follows. This entry would tell the host that in the absence of a specific routing table entry for the destination host route all packets to the router at for delivery. The default router has also been called the “router of last resort,” as the host will attempt to find a specific route to the destination before it will send the packet to the default router.

Host Configuration /etc/defaultdomain /etc/netmasks
This file is used to specify the default NIS[+] domain for this host. The NIS domain name may be different from the DNS domain name. /etc/netmasks When a network is divided into subnets, the net mask may not be obvious. The /etc/netmasks file associates a subnetwork with the net mask used to create the subnetwork. This allows the system to automatically determine the broadcast address for the subnet. Typical content for a netmasks file might resemble the following example.

Host Configuration /etc/networks
The networks file is used to associate symbolic network names with Internet protocol addresses. While largely unused, some applications rely on the (sparse) information found in this file. # The networks file associates Internet Protocol (IP) # network numbers with network names. The format # of this file is: # network-name network-number nicnames . . . # The loopback is used for intra-machine communication loopback # # Internet networks arpanet arpa # Historical

Host Configuration /etc/init.d/network
The /etc/init.d/network file is the first of the network startup scripts invoked by init at boot time. The services launched by the network script include the multicast routing daemon, and the DHCP client daemon. The script also call ifconfig (to configure network interfaces). The interfaces must be properly configured and available before any other network services may be started.

Host Configuration /etc/init.d/inetsvc
The /etc/init.d/inetsvc file is the next network startup script invoked by init at boot time. This script starts many of the Solaris network daemons. The inetsvc script starts the NIS daemons to provide NIS, the named binary to provide DNS, and the Dynamic Host Configuration Protocol (DHCP) server daemon. The inetsvc script also configures a multicast route to be used by multicast services, and launches the inetd daemon to manage non-persistent service daemons. If you want your hosts to send a log entry for every network connection request to syslog, change the last line of the inetsvc script to invoke inetd with the –t flag (in addition to the –s flag). This enables the trace option of inetd. All incoming network connections generate a log entry in the /var/adm/messages file Feb 12 14:30:14 grumpy inetd[251]:[ID daemon.notice] ftp[13370] from Feb 12 14:30:14 grumpy inetd[251]:[ID daemon.notice] ftp[13370] from This syslog entry includes several important pieces of information about this network connection attempt. · The Date field tells when the message was logged. · The Hostname field gives the name of the host (grumpy) that sent this log message. · The Process field tells what process running on hostname generated this message. In this case, the inetd process, running on grumpy, with process ID of 251, sent the message. · The Severity field tells the severity level of this notice (daemon notice). · The Subprocess field lists the command invoked by inetd as a result of this connection request. In this case, the inetd service launches ftpd on host grumpy. The ftpd process invoked has a process ID of · The Remote host field lists the IP address of the host that made this network connection request.

Host Configuration /usr/sbin/ndd
Solaris and HPUX provide the ndd command to allow the administrator to get and set driver configuration parameters. For example, if you want to use a host as a packet forwarding system, the kernel must be configured to provide this service. The appropriate kernel configuration may be accomplished via the ndd command. In particular, you should use ndd to turn on packet forwarding at the IP protocol stack level. To accomplish this task on a Solaris host, you would use the following command. # /usr/sbin/ndd -set /dev/ip ip_forwarding 1 Conversely, the following command will disable packet forwarding on a Solaris system. # /usr/sbin/ndd -set /dev/ip ip_forwarding 0 Other values often modified include the TCP high water and low water marks, and the type of link in use (half/full duplex, “autobaud”/10/100/1000 Megabit Ethernet capabilities). The ndd command may be used to probe the following devices. /dev/tcp: TCP protocol stack variables /dev/udp: UDP protocol stack variables /dev/ip: IP protocol stack variables /dev/icmp: ICMP protocol stack variables /dev/rawip: ICMP protocol stack variables /dev/arp: ARP protocol variables /dev/le: Lance Ethernet device driver variables /dev/hme: 100 Mbit Ethernet device driver variables /dev/eri: Gigabit Ethernet device driver variables To see what variables are available under a specific device, invoke ndd as follows. ndd /dev/{devicename} \? This will cause ndd to query the driver and produce a list of variables that the driver lists as available to be viewed/set using the ndd interface.

Host Configuration Hosts with Multiple Interfaces
Quite often you will encounter systems with more than one network interface. This situation may be required for many reasons. Sometimes the host requires more bandwidth than can be provided by one interface. Other times the system needs to localize traffic to a specific network segment, or the system may need to answer to multiple “names” on the network. These hosts impose some interesting problems on the system administrator.

Host Configuration Multi-path Capabilities
Systems that contain several network interfaces connected to the same network are called multi-path hosts. These hosts often have very high availability or bandwidth requirements. For this reason, the system architects might install multiple network interface adapters, and connect them to the same media. In the case of a high-bandwidth setup, multiple network interfaces are assigned the same IP address and host name. Under Solaris, this may be accomplished with the ifconfig adapter group groupname command. This invocation of ifconfig allows the administrator to group interfaces into a virtual “larger” network connection. This group of interfaces acts as a single link, but splits the bandwidth load across many links, thereby providing better overall bandwidth. In the case of high-availability setups, the interfaces may be configured to provide automatic “fail-over,” which provides a “hot spare” situation for the network interfaces. This option is configured through the ifconfig –failover option. NOTE: Different vendors implement multi-pathing in different ways. Consult your vendor information to determine the specifics of how your operating environments implement/configure multi-pathing. The following example shows the host name files from a Solaris host using Sun’s multi-path mode of operation. This configuration provides better bandwidth, and redundancy for the host by “bonding” two interfaces. If one interface fails, the system will continue to run with half the bandwidth previously available to it. Note that both interfaces are on the same network and have the same host name. The interfaces are added to an interface group by directives in the hostname.if_name file. # more /etc/hostname.hme0 wazoo group plc -failover # more /etc/hostname.hme1 wazoo group plc –failover NOTE: Not all operating systems allow the operator to place the same information in their hostname.ifname files. Consult the manual page for your OS to determine the appropriate values to place in your files.

Host Configuration Multi-homed Hosts
Hosts with network interfaces on several networks are referred to as multi-homed hosts. Such hosts may be configured to act as routers on the internal network. Because these hosts are connected to multiple networks, it may be desirable to have them forward packets from one network to another to facilitate communications. This process is sometimes referred to as packet forwarding, or ip forwarding. NOTE: Packet forwarding will require considerable processor overhead, and is usually best left to routers designed to perform this function. The administrator can use the route command to set the metric for a route, or the ndd command to set the metric for an interface. The result is the same: one route is preferred over another due to the weight (metric) assigned to each route/interface. Note that configuration settings made using ndd or route do not persist across reboots.

Host Configuration /etc/system
The /etc/system file is a dumpster for things that don’t fit elsewhere. This file is read at boot time, and is used to configure everything from network interfaces to virtual memory to executable stack limits. On the networking side, this file is used to configure network interfaces. Placing directives in this file will cause the configuration settings to be applied each time the system reboots. One example of extraordinary network configuration is a network interface configured for “non-auto sensing” operation. By default, Sun network interfaces perform auto-speed and auto-duplex sensing of the network equipment to which they are connected. This situation sometimes leads to deadlocks when a host tries to auto-sense the type of connection it is using. Directives in the /etc/system file can force a Solaris system to disable the auto-sense capabilities of the interface, and force the interface to operate in a fixed speed/duplex mode. Note that the same results could be obtained using the ndd commands (shown as comments in the following example).

Host Configuration /usr/sbin/sys-unconfig
; Set interface not to negotiate speed ; same as ndd –set hme:hme_adv_autoneg_cap=0 set hme:hme_adv_autoneg_cap=0 ; set interface to 100 megabit full duplex ; same as ndd –set set hme:hme_adv_100fdx_cap=1 set hme:hme_adv_100fdx_cap=1 /usr/sbin/sys-unconfig The Solaris /usr/sbin/sys-unconfig command allows the administrator to change the network information of the host. This command removes all network-specific information files, and halts the machine. When the machine is rebooted, a portion of the SunInstall program is invoked to prompt the administrator for the new network connection information. Once the new information is entered, the system reconfiguration is complete, and the system is ready for use.

Host Configuration PPP Under Solaris Red Hat Linux
The Solaris operating system provides a point-to-point protocol daemon called aspppd. The ppp daemon is used to provide PPP service over dial-up modem links [or PPP over Ethernet (PPPOE), as used by some virtual private networks] and Network Address Translation systems. Red Hat Linux The Linux operating system attempts to place most of the configuration files in a common location. In general, under UNIX, the /etc directory usually contains system startup scripts and configuration files. But many vendors create multiple subdirectories under /etc to segregate and contain the files/scripts required to configure the system. Whereas most versions of Linux use the BSD conventions for configuration files, RedHat Linux does things a little differently. Under Red Hat Linux, this subdirectory is /etc/sysconfig. The /etc/sysconfig directory contains scripts and data files required to configure many system services, including networking.

Host Configuration The linuxconf Command The /bin/linuxconf command is the top-level Linux configuration tool. This tool contains links to several second-level configuration tools. One of the tools linuxconf can invoke is the netconfig command. WARNING: The linuxconf command is also available as an inetd service. The linuxconf command has been known to be less than bulletproof, and many administrators disable the ability to launch the linuxconf command via inetd.

Host Configuration The netconf Command The Network Script File
The /bin/netconfig command, is the primary network configuration GUI under Linux. This tool includes menus that allow the administrator to configure IP addresses, net masks, metrics, and other operational parameters of the network interfaces, as well as network protocol stacks. This tool often launches other utilities to perform these tasks. The Network Script File The /etc/sysconfig/network file contains information that is “generic” to all interfaces on the host. The following are a few of the keywords and typical values. NETWORKING=yes # enable networking on host FORWARD_IPV4=”no” # yes if host routes packets HOSTNAME=”grumpy” # hostname for this host DOMAINNAME=”plc.com” # domain of this host GATEWAY=” ” # The IP gateway for this host GATEWAYDEV=”eth0” # default link device

Host Configuration The ifcfg-ifname File
The /etc/sysconfig/network-scripts/ifcfg-ifname files supply the configuration information for each network interface. These script files contain a series of keywords and values parsed at boot time. The values are used to configure network interfaces, net masks, and host names; set default gateways; and perform other tasks required to bring the host up on the network. DEVICE="eth0" # The interface name BOOTPROTO="none" # Set to DHCP to use DHCP IPADDR=" " # Host’s static IP address NETWORK=“ ” # The network number BROADCAST=” ” # The broadcast address NETMASK=" " # The netmask ONBOOT="yes" # yes to configure at boot

Host Configuration The ifup Script The ifdown Script
The /etc/sysconfig/network-scripts/ifup script file is invoked at boot time by init. The script reads the interface files and parses the entries. The information from the entries is used to configure each network interface with the proper values. The ifdown Script The /etc/sysconfig/network-scripts/ifdown script file is invoked at shutdown time by init. The information from the entries is used to shut down each network interface. The network-functions Script The /etc/sysconfig/network-scripts/network-functions script file contains a “library” of functions used by the ifup and ifdown scripts. The functions include code for setting the net mask, host name, broadcast addresses, and gateways. The functions perform operations required to configure an interface up or down.

Host Configuration The /proc/sys/net Interface
The /proc/sys/net directory contains an interface to many internal features of the IP stack on the host. Typically, the files in this directory appear to be empty. Reading the file will give the current value of the variable. The administrator can edit these files, and set a value to tune many operational parameters of the IP stack. For example, by default network interfaces will accept redirect messages from network routers. This allows the router to optimize the network utilization by telling two hosts how to communicate with each other without involving the router. Unfortunately, this also leaves the system open to hijack attacks. The administrator can check to see if the system accepts ICMP REDIRECT packets by using the following. # cat /proc/sys/net/ipv4/conf/eth0/accept_redirects 1 If the command returns a 1 (as in the previous code), the feature is enabled on the eth0 interface. If the administrator decides to turn off the system’s capability of accepting ICMP REDIRECT directives on the eth0 interface, he/she could change the file using the following. # echo 0 > /proc/sys/net/ipv4/conf/eth0/accept_redirects The System Administration, Networking, and Security Institute (SANS) publishes step-by-step guides to assist an administrator with the task of securing operating systems. The SANS Step-by-Step Guide to Securing Linux contains many helpful tips for securing a Linux host on the network using the /proc interface files.

Host Configuration HPUX /etc/rc.config.d/netconf
HPUX achieves something that most of the other UNIX variants come close to: it manages to contain all network configuration parameters within one script. The /etc/rc.config.d/netconf script is the HPUX network configuration script. This script is invoked by init at system boot. NOTE: OSF/1 is another UNIX variant that employs a single network configuration script, named /etc/rc.config. /etc/rc.config.d/netconf To configure, or change the configuration of, network interfaces on an HPUX system you must edit the /etc/rc.config.d/network file. This file contains several variables that control the configuration of the network interface(s). In the following example, the host has two interfaces. Note that any host names used in this script must be defined in /etc/hosts, as the DNS service will not be running when this script is executed.

Host Configuration NET_CARDS=2 HOSTNAME=bamboozled
INTERFACE_NAME[0]=lan # Ethernet link layer encapsulation ROUTE_DESTINATION[0]=default # could also be net or host ROUTE_MASK[0]= ROUTE_GATEWAY[0]= ROUTE_COUNT=1 IP_ADDRESS[0]= SUBNET_MASK[0]= INTERFACE_NAME[1]=snap1 # link layer encapsulation ROUTE_GATEWAY[1]= IP_ADDRESS[1]= SUBNET_MASK[1]= GATED= # set to 1 to enable gated

Host Configuration HPUX Network Utilities AIX
In addition to the rc.config.d/netconf file, HPUX provides a few utilities that provide information about the system’s network links. /usr/sbin/lanscan: shows information about network interfaces. Note that ifconfig –a does not work, but you can use ifconfig with an interface name /usr/sbin/lanadmin: The lanadmin utility is a menu-based tool that allows the administrator to modify and monitor the network interfaces on the system. NOTE: HPUX will not allow an Ethernet network interface to be configured unless it is connected to the Ethernet media, and a link test is successful. AIX AIX uses a network configuration scheme that is more “Windows-like” than any of the other UNIX variants. Windows provides a GUI tool that allows the administrator to enter the information into a “database” called the registry. AIX stores the basic network configuration information in a database located in /etc/objrepos. This database cannot be readily edited by hand and must be accessed by the AIX-specific tools lsdev, chdev, and mkdev. A simpler alternative to AIX network configuration management is to use AIX’s system management interface tool (SMIT), which acts as a front end to the database tools.

Host Configuration IRIX
IRIX stores its basic network configuration information in several files in /etc and /etc/config. These files can be edited by hand, or via the system manager GUI interface found in the Toolbox menu or by running /usr/sysadm/bin/sysmgr. The following are some of the more important files. /etc/sys_id: Contains the system’s fully qualified domain name. This is used to locate the system’s IP address in /etc/hosts unless the value there is overridden by setting alternative values in /etc/config/netif.options. /etc/config/ifconfig-1.options, /etc/config-2.options, and so on: These files are numbered for each network interface and contain any additional options needed when the corresponding interface is configured by ifconfig during system startup. For example, this file might include a custom net mask for a specific network interface. /etc/config/netif.options: Contains values to override the name or IP address assigned to each network interface on system startup. This might be used to set unique host names for each network interface. /etc/config/proclaim.options: Contains the settings for the proclaim daemon that will gather an IP address and other configuration data from a DHCP server. /etc/config/static-route.options: Contains any default routes to be added at system startup.

Host Configuration BSDI
Like HPUX and Linux, the BSD kernel relies on variables set in a script file to configure the network interfaces. The system ships with default values set in the file /etc/defaults/rc.conf. Under BSD kernels, the administrator needs to edit the file /etc/rc.conf to set values that will override the values in the default file. If you need to set variables specific to a system, you can also create a file named /etc/rc.conf.local to contain host-specific settings. In this example, the host has two network interfaces (xl0 and xl1). One network interface connects to the network, and the other connects to the network (with a subnet mask of ). network_interfaces=”xl0 xl1 lo0” hostname=”poncho” ifconfig_xl0=” ” ifconfig_xl1=” ” defaultrouter=” ” static_routes=”backbone private” route_backbone=”-net ” route_private=”-net –netmask ”

Host Configuration MacOS X Windows
While similar to BSD-style UNIX, MacOS X moves the host configuration information to a different file, /etc/hostconfig. Under MacOS X, the other typical BSD network data files are found in their usual places in /etc. MacOS X also provides a GUI for managing the configuration information. Note the Location pull-down menu at the top of the network control panel. This allows several network configurations to be saved under different “locations,” and makes network reconfiguration on portable MacOS X systems easier. The padlock icon at the bottom left-hand corner of the control panel allows the system administrator to lock the network settings such that helpful users cannot “fix” the settings for the administrator. Windows Under Windows operating systems, many of the network configuration values are contained in the registry, in lieu of text files. This makes changing the values a matter of using the GUI-based tools provided by the OS, or for the really brave, the use of the REGEDIT.EXE utility to edit the registry. WARNING: Editing the registry is best left to Windows gurus. It is very easy to render the operating system non-bootable by making changes to the Windows registry.

Host Configuration The LMHOSTS File 172.16.205.101 happy #PRE #DOM plc
The \winnt\system32\drivers\etc\lmhosts file is the Windows equivalent of the UNIX /etc/hosts file. But as with many things Windows related, the format of the file is a little bit different than its UNIX counterpart. The Windows lmhosts file allows options not recognized in the UNIX hosts file. The following are a few of these directives. #PRE: Preload this entry #DOM <DOMAIN>: Windows domain controller for this host #BEGIN_ALTERNATE: Used to group include statements #END_ALTERNATE: Used to mark end of grouped include statements #INCLUDE <filename>: Include the named file as part of the hosts file #MH: Used to signify multi-homed hosts that have multiple IP addresses #SG: Special group keyword maps Internet groups by NetBIOS name The entries in the Windows lmhosts file typically do not specify the fully qualified domain name of the computer, as shown in the following example. happy #PRE #DOM plc sleepy dopey doc

Host Configuration Configuration Programs ipconfig
Windows provides a GUI-based Network Control panel that may be used to configure hosts network components. The Network Control panel allows the administrator to configure the interface manually or via the DHCP protocol. If manual configuration is selected, the administrator is presented with several menus of configuration options. If manual configuration is selected, the administrator will need to provide the IP address, net mask value, the IP address of the gateway for this host, the name service to be used, and the name server address. Other options allow the administrator to set a security policy, and enable network filtering based on the policies set by the administrator. ipconfig The ipconfig program displays the current settings used by the network adapter. When invoked with the /all flag, this command will show more verbose information about the network settings. Information available includes IP addresses, host names, packet counts, subnet masks, gateways, and domain name.

Host Configuration Using DHCP to Assign IP Addresses
A tool that simplifies IP configuration is the Dynamic Host Configuration Protocol (DHCP). DHCP automatically assigns an IP address to a host at boot time. Hosts that use the DHCP protocol to obtain their network configuration information are typically referred to as DHCP clients. Hosts that supply DHCP configuration information to other hosts are referred to as DHCP servers. DHCP Client Configuration In most cases, the simplest method of configuring a host as a DHCP client is to do so when the operating system installation process is invoked. Most installers contain a section that asks how the system will receive its network configuration information. Simply selecting the DHCP option configures the host to obtain its information from a DHCP server. Because systems tend to have many uses over their lifetime, it is often handy to know which files to edit to change the host’s idea of where it will get its network information. The following sections briefly describe the files/commands required to configure a host as a DHCP client.

Host Configuration Solaris
Configuring a Solaris host to be a DHCP client is relatively simple. The interface needs to be configured under the control of the dhcpagent program. The dhcpagent program is the utility that manages the network interfaces that use DHCP. From the command line, you can enter the following command. ifconfig interface dhcp Here, interface is hme0, le0, eri0, or one of the other Solaris-supported network interfaces. This command will place the interface under the control of the dhcpagent program. To make the system use DHCP when it boots, you need to modify/create a couple of files, as follows. /etc/dhcp.interface: Existence of this file causes the system to configure that interface for DHCP at boot time. /etc/hostname.interface: Can still exist, but can be empty if you plan to use DHCP. If the file contains a host name, the system will come up using the static IP address referred to by the name in /etc/hostname.interface, and then the DHCP service reconfigure the interface using a DHCP address later in the boot process. If you want to check the status of the dhcp client software under Solaris, use the dhcpinfo command. Additionally, you can examine the content of the /etc/dhcp/interface.dhc file to view the settings for a specific interface.

Host Configuration Linux AIX IRIX
You can make a Linux system use DHCP to obtain network information by editing the /etc/sysconfig/network-scripts/ifcfg-interface file, where the name of the interface is substituted for the word interface. Placing the following directive in the ifcfg-interface file will cause the system to use DHCP to configure the interface at boot. BOOTPROTO=dhcp AIX Configuring AIX to use DHCP is best done via SMIT. AIX provides very complete control over the DHCP client and the configuration information it is to receive from the DHCP server IRIX IRIX uses a daemon called proclaim to communicate with the DHCP server to obtain an IP address and other information. proclaim is started during system startup if the Primary on or Interface on option is present in the /etc/config/proclaim.options file.

Host Configuration HPUX
To make a HPUX system use DHCP, you need to edit the /etc/rc.config.d/netconf file. For each interface that will use DHCP, you need to set the DHCP_ENABLE[N] variable to 1, as shown in the following for interface 0 (zero). DHCP_ENABLE[0]=1 Note that if there is no DHCP_ENABLE variable for an interface, the kernel defaults the setting to 1. When DHCP is enabled, the host will receive its IP address, gateway address, net mask, and other network configuration information from the DHCP server. Under HPUX, the /sbin/auto_params script calls the dhcpdb2conf utility to modify the netconf file with the values provided by the dhcp server. Note that you can also use the SAM utility to configure the system to use DHCP. To monitor the operation of the DHCP client software under HPUX, use the /usr/sbin/dhcptools utility provided with the system software.

Host Configuration BSDI
To make a BSDI kernel use DHCP, you need to define a few values, and set a variable for each interface. This is done by editing the /etc/defaults/rc.conf file and adding the following two directives. dhcp_program=”/sbin/dhclient” dhcp_flags=”” Once these values are set, you need to edit the /etc/rc.conf file and add a line to cause each desired interface to use DHCP. This is illustrated for the xl0 interface in the following example. ifconfig_xl0=”DHCP” With these changes in place, the system will start the DHCP dhclient program at boot, and the xl0 interface will receive all network configuration information from the DHCP server. The dhclient.conf file allows you to customize the dhclient program’s operation, but such customizations are usually not required. Lease information is stored in the /etc/dhclient.leases file.

Host Configuration MacOS X Windows DHCP Server Configuration
Configuring MacOS X for DHCP is a simple matter of selecting DHCP from the list of choices in the Network Control panel. Windows Setting a Windows system to be a DHCP client is accomplished via the “Network Control panel” GUI. Select the appropriate network connection, right-click on it, and then select the Internet Protocol (TCP/IP) entry. Click on the Properties button, and then click on the Obtain an IP address automatically button. DHCP Server Configuration Configuring a system to be a DHCP server is more involved than making the system operate as a DHCP client. The server needs to be configured to know what addresses are available, which hosts may check them out, how long an IP address may be leased, and several other parameters. The following sections describe how to configure the DHCP server process under several operating system variants.

Host Configuration Solaris
To configure the DHCP Server service under Solaris, the administrator should use the dhcpconfig command. The dhcpconfig command is a front end to the dhtadm and pntadm utilities that build and maintain DHCP configuration tables. The dhcpconfig command allows the administrator to configure DHCP and Boot Relay services (required for remote DHCP), or to unconfigure the DHCP service. The dhcpconfig command will guide the user through several questions, collecting the information necessary to set up DHCP on the server. Once the information is collected by dhcpconfig, it will invoke the dhtadm and pntadm commands to create the DHCP database files, and start the DHCP service. If this DHCP server were required to provide DHCP service for remote networks, the administrator would have to set up/configure the BOOTP Relay service. The DHCP registration requests are sent as broadcast packets. By default, routers will not forward broadcast packets to other networks. For the DHCP registration request packets to get to the server, a relay service has to forward them through the router. As an example of a simple DHCP configuration, the astro.com administrators created a DHCP server named (aptly) dhcpserve. This machine provides DHCP service to clients on the network. The network has 10 client machines that obtain IP addresses via DHCP. When the administrator has completed the configuration process, the dchpconfig command will create two database files. The files created by the dhcpconfig command are stored in the /var/dhcp directory. The /var/dhcp/dhcptab file contains information about the server environment. The /var/dhcp/[IP_with_underscores] file contains the information regarding addresses leased out, and available addresses. If the network number for the DHCP network is , this file name would be /var/dhcp/192_168_0_0.

Host Configuration Linux, BSDI, and MacOS X
Most Linux distributions come with the ISC version of DHCP. The BSDI and MacOS operating systems also use the ISC DHCP server. The following discussion covers the ISC DHCP server, not the RedHat pump server. Once the DHCP package has been downloaded, built, and installed, the task of configuring the server begins. For DHCP to work, the system must be configured to provide multicast services, and there must be a route for “host” You can check the output of the ifconfig command to determine if the system supports multicast. By default, most Linux/BSDI kernels support multicast operation. To provide a route for the host, enter the following command (assuming your network device is eth0). route add -host dev eth0 If you get the message “ : Unknown host,” add the following entry to the /etc/hosts file. all-ones Linux, BSDI, and MacOS X Once the hosts file has been modified, try one (or both) of the following commands. route add -host all-ones dev eth0 route add dev eth0 Once the route has been added, you need to edit the /etc/dhcp.conf file to configure the DHCP server’s operation. If you are using the KDE window manager, you can use the kcmdhcpd GUI to configure the DHCP service. The following sample dhcp.conf file configures the server to provide client addresses in the through and through ranges. The default lease time will be 600 seconds unless the client requests some other value. The time limit on a lease is 7200 seconds (2 hours). The client will be instructed to use the subnet mask , and the broadcast address The client will also be told to use as its default gateway. The host will be told to use the name servers at and The client domain name will be set to plc.com. Windows clients will be configured with as their WINS server. default-lease-time 600; max-lease-time 7200; option subnet-mask ; option broadcast-address ; option routers ; option domain-name-servers , ; option domain-name "plc.com"; option netbios-name-servers ; subnet netmask { range ; range ; }

Host Configuration If you need to assign specific IP addresses to hosts, you can add multiple fixed address directives to the file. The format of these directives is shown in the following example. The sample code will assign the IP address to any host that advertises that its MAC address is 08:00:20:C0:FF:EE. host zircon { hardware ethernet 08:00:20:C0:FF:EE; fixed-address ; } When the snmpd.conf file is ready, create a zero-length file named /var/state/dhcp/dhcpd.leases. Once this file exists, start the DHCP server with the command /usr/sbin/dhcpd interface. If you leave off the interface directive, the server will start on the eth0 interface. Remember to add the dhcpd server to the appropriate startup file, to ensure that the service starts at system boot.

Host Configuration HPUX
The HPUX DHCP server is named bootpd. The first step required to set up a DHCP server under HPUX is to define the range of addresses the server will manage. This is accomplished using the dhcptools program, as follows. dhcptools -h fip= no=30 sm= hn=hpdhcpserver## This command defines the range of addresses to be used by defining the starting address (fip= ), the number of contiguous addresses (no=30), the subnet mask, and the host name of the dhcp server (hpdhcpserver). The command will create a file /tmp/dhcphosts, which can be incorporated into the /etc/hosts file. The easiest way to configure DHCP on a HPUX system is through the SAM program. Under SAM, select Networking and Communications | Bootable Devices | DHCP Device Groups Booting From This Server. At this point, the system should display any existing DHCP groups assigned to this server. If none appear, you need to add one, as follows. Use the ACTION menu, select Add DHCP Group. Fill in the information on this screen. This includes the following items. DHCP group name Subnet mask [subnet] Address pool Lease time Consult the dhcp manual pages for more information on these options.

Host Configuration Windows
Windows server products offer a DHCP server package. The DHCP Service package is not installed by default, and can only be installed on Windows Server-based operating systems. The DHCP snap-in provides a GUI tool for configuration and management of the DHCP service.

Host Configuration Network Monitoring and Troubleshooting
As with most computer operations, networks are bound to have problems. Troubleshooting networks can be a tedious process. One method of troubleshooting is to use monitoring tools that determine how the network is being used. In some cases, it may not be possible to monitor a network because physical connections may be damaged or gateways may be down. Another method of monitoring the network is to watch the console error messages generated by the machines connected to the network. Console Error Messages The error messages sent to the system console provide you with a lot of information about the health of the system and the network. Unfortunately, many administrators do not pay attention to console messages (or worse yet, close the console window, or leave the console window iconized). Fortunately, UNIX provides the administrator with a simple facility for capturing all console messages in a single location. The UNIX kernel uses the syslog facility to log messages to the system console. However, syslog also allows these messages to be sent to remote hosts.

Host Configuration /etc/syslog.conf File
The /etc/syslog.conf file controls the action of the syslog facility. The UNIX kernel defines several levels of message severity. Entries in the syslog.conf file configure the syslog facility to handle these different message categories. For example, a simple informational message may be ignored, whereas a system hardware error may be reported to the console with much fanfare.

Host Configuration Logging Messages to a Remote Host
In addition to controlling the local disposition of messages, the /etc/syslog.conf file also allows the administrator to send error messages to a central log host on the network. This procedure enables you to monitor one log file that contains messages from all machines on the network. It also makes life difficult for an intruder trying to cover his footsteps. To enable remote syslog capabilities, you should add a line similar to the following to the /etc/syslog.conf file. Once the previous directive has been added to the /etc/syslog.conf file, you can restart the syslogd process on the client machine by sending a kill -HUP signal to the process ID of the syslogd process. The kill -HUP signal will cause the syslog process to reread the configuration file, and restart with the new parameters. Once you have set up all hosts on the network to log errors to a single location, monitoring the error log is as simple as using the tail -f / var/adm/messages command on the log host. Several third-party utilities are available to parse message files, and alert you to messages you may have missed. The following are two of the more popular utilities. · logcheck: Now called Psionic LogSentry. LogSentry is available at This utility comes complete with installation and configuration information. The LogSentry utility is very similar to the log parser that comes with the TIS Guantlet firewall product. · swatch: Simple watcher developed by E. Todd Atkins at the University of California, Santa Barbara. Swatch is available at The distribution code includes installation and configuration information for this utility.

Host Configuration Network Monitoring
Although kernel syslog messages may provide some information about the health of the network, it is sometimes necessary to more closely examine the network. Simple Network Management Protocol (SNMP) A more sophisticated method of monitoring networks is to use a network management tool based on the simple network management protocol (SNMP). The SNMP package allows a network administration host to constantly monitor the network. Information available to the SNMP software includes network utilization, host error counts, host packet counts, and routing information. SNMP allows you to determine normal usage of the network and implement alarms to warn of impending problems. SNMP operates in a client/server mode. One machine on the network is designated as the SNMP network monitor station. It is configured to poll hosts on the local network in order to collect data into a central repository. The data may be made available to other packages in order to implement alarms, generate graphs of network utilization, and other off-line processing. The other hosts on the network are configured as SNMP clients. These hosts run a process that watches for polling requests from the network management station. When such a request is received, the SNMP agent code collects the data from the workstation’s kernel and forwards it to the management station. WARNING: SNMP has been perpetually insecure. The use of well-known “community strings” (passwords), and the existence of buffer overflows in many implementations, has made the use of SNMP somewhat dangerous. If your site uses SNMP, you need to take extra caution to block external access to the SNMP processes. Failure to do so may result in your systems becoming compromised by hackers.

Host Configuration Configuring SNMP
Under most operating systems, the default SNMP configuration is horribly insecure. For this reason, many sites disable the SNMP client code on their systems. If you must run SNMP, there are several things you should do in an attempt to protect the security of your systems. Change the public and private community strings. By default, the public string is public. Private community strings vary by vendor, but are usually easy to find. Access to the private string gives an intruder the capability to reconfigure your hosts/network equipment. Change these strings and protect them as you would the root password. The SNMP community strings are just as dangerous as a compromised root password! Block TCP and UDP ports 161, 162, and 1993 at your border routers. There should be no reason for someone outside your organization to access your site using SNMP. Keep current with patches. Watch for SNMP security advisories, and make sure your hosts are patched. If you generate OpenView or MRTG information for your network, do not allow it to be viewed without proper authentication. The data available from OpenView and/or MRTG packages often gives intruders important information about your network. With these rules in mind, the following sections briefly discuss how to configure the SNMP client on various operating systems.

Host Configuration SNMP Under Solaris
Under Solaris, the following four files are responsible for the configuration and startup of the SNMP package. · /etc/rc2.d/S76snmpdx: Startup script for the snmp daemon. · /etc/rc2.d/S77dmi: Startup script for the DMI processes that are part of the snmp package. · /etc/snmp/conf/snmpdx.acl: File containing a list of IP addresses allowed to contact the SNMP daemon on this system. The default file contains comments that explain how to add the IP addresses, and community strings for each host allowed to contact the local SNMP daemon. · /etc/snmp/conf/snmpd.conf: Text configuration file for snmpd. The administrator needs to edit the configuration file and set the read and write community strings to something unique to the local site, as shown in the following example. sysdescr PLC SparcStation syscontact sysLocation Poodle Lecture Consulting # system-group-read-community Myreadgroupstring #system-group-write-community Mywritegroupstring read-community Myreadcomstring #write-community Mywritecomstring trap localhost trap-community SNMP-trap #kernel-file /vmunix managers localhost Once the snmpd.conf file has been modified, make sure it is only accessible by root. If the file is readable by others, they will have access to your read/write strings, and therefore access to your systems. You can start the snmp utilities running by invoking the S76snmpdx script, followed by the S77dmi script with the start argument.

Host Configuration SNMP Under Linux SNMP Under HPUX
By default, most Linux installers no longer install the SNMP package. To use SNMP, you must install the SNMP utilities from the distribution medium, or from a downloaded RPM. If you do run SNMP, you need to edit the /etc/snmp.conf file to set the runtime parameters for the SNMP utilities. SNMP Under HPUX Under HPUX, the following two files are responsible for the configuration and startup of the SNMP package. /usr/sbin/snmpd: Startup script for the snmp daemon /etc/SnmpAgent.d/snmpd.conf: Text configuration file for snmpd The snmpd.conf file allows the administrator to define several variables that control the actions of the SNMP daemon. get-community-name: your_read_community_password · set-community-name: your_write_community_password · trap-dest: Name of the hosts that should receive trap notifications. There may be more than one trap destination. · location: Physical location of the host. · contact: address of the person to contact about the host. The HPUX SNMP daemon logs information to /var/adm/snmpd.log. Starting snmp with a log mask can control the amount of logging. See the manual page for snmp to determine the proper log mask for your site.

Host Configuration SNMP Under Windows
Under Windows, the SNMP package is not installed by default. To use the SNMP package under Windows the administrator must load the package from the distribution medium. This may be accomplished using the Add/Remove Programs control panel. Click on the Add/Remove Windows Components button, select the Management and Monitoring Tools option, and click on the Details button. Next, select Simple Network Management Protocol, and click on OK. Once the SNMP protocol has been installed, select Control Panel | Administrative Tools | Services GUI to select the SNMP agent. This will cause a pop-up window to appear. The pop-up window contains entries for the configuration and management of the SNMP process

Host Configuration Remote MONitor (RMON) Solstice Domain Manager
Extensions to the SNMP software packages have recently permitted more advanced monitoring of network usage. The Remote MONitor (RMON) package allows the administrator to monitor which applications are utilizing the network and which users are running these applications, giving you the ability to perform bandwidth utilization scheduling for the corporate network. RMON also provides you with the capability of monitoring disk space usage, processor utilization, memory usage, and other system monitoring functions. Solstice Domain Manager Tools such as Sun Microsystem’s Solstice Domain Manager package use the data collected by the SNMP software to perform higher-level network monitoring. These packages typically include utilities that have the capacity to “discover” systems connected to a network. The discovered systems are then used to construct an interactive schematic of the network. Alarms (thresholds) on numerous network “health” statistics can be set. If a system on the network fails, an alarm for that condition would be tripped, alerting the network manager of the failure by flashing the icon of the failed system on the schematic. Sun’s Solstice Domain Manager, shown in figure 16-10, is not bundled with Solaris. It is a separate product marketed by SunConnect, a division of Sun Microsystems.

Host Configuration HP OpenView Multi-Router Traffic Grapher (MRTG)
Hewlett-Packard’s OpenView product provides capabilities similar to Domain Manager, and is available for a wide range of platforms, including UNIX and Windows. OpenView employs SNMP to gather information about the network. A set of utilities included with OpenView also allows the operator to map the network, and to configure automated polling and trap handling using SNMP. Multi-Router Traffic Grapher (MRTG) The Multi-Router Traffic Grapher (MRTG) package is another tool that employs SNMP to collect data about the network. MRTG is configured to contact routers and collect performance/throughput statistics from each interface. This information is then parsed, and stored in a condensed MRTG format. The MRTG data is used to create graphs of input and output traffic for each network interface. MRTG allows for short-interval (typically 15 minutes) daily graphing, and monthly graphs of network activity. MRTG also allows the operator to graph other interesting network events, such as the number of incoming/outgoing messages processed by a mail server, or the number of web site visits seen by a web server.

Host Configuration Network Troubleshooting Network Sniffers
Tracking down network problems is similar to detective work. In time, administrators develop an instinct for where to seek clues. The following discussion is by no means an exhaustive troubleshooting scenario. It will, however, provide some basic tools and techniques that all seasoned network managers use. Network Sniffers Network sniffers are software tools that are often used by hackers to surreptitiously collect sensitive information from a network. But system administrators may also use a sniffer as a network-troubleshooting tool. These tools may allow the sysadmin to determine why a network connection is failing, or what application is consuming all of the network bandwidth. Vendor-supplied Network Sniffers Most operating systems ship with some form of network sniffer utility. Under Solaris there is the snoop utility. Under Windows you will find Network Monitor. HPUX ships with the nettl program. Each of these tools is specific to a single operating system, which makes them somewhat cumbersome, as the sysadmin needs to learn several utilities in order to perform one function. In addition to their “proprietary” sniffer applications, most of the UNIX operating systems discussed now ship with a third-party sniffer called tcpdump. However, because Solaris and HPUX do not include this application, let’s examine the snoop (Solaris) and nettl (HPUX) packet sniffers.

Host Configuration snoop
Solaris ships with Sun’s version of a network sniffer utility, snoop. The output from snoop is generally voluminous and somewhat cryptic. However, it is a good command to use when trying to determine whether two hosts on a network are communicating, or to identify the type of network traffic being generated. Some of the more common uses of snoop follow. Monitoring traffic between two hosts. For example, snoop can be very useful when troubleshooting two systems that cannot communicate. For example, a diskless client might issue tftpboot requests that are never answered. You could use snoop to capture packets from the diskless client to determine if the client is issuing “proper” requests. Next, you could monitor the boot server network traffic to determine if the server is replying to the boot requests, as follows. snoop -d hme0 between client_name server_name Monitoring traffic using a particular protocol. For example, a host on the network may not be able to resolve IP-to-MAC addresses. This typically means that the address resolution protocol (ARP) process is failing. You could use the snoop command to watch the network for ARP requests and the ensuing replies from the name server, as follows. snoop -d hme0 arp Monitoring traffic containing specific data. · Monitoring a network to determine which host is creating the most network traffic. The snoop command even provides a “cheap and dirty” means of determining which hosts are generating the most traffic on the network. You could start snoop and visually monitor which hosts are generating traffic (snoop -d hme0). Alternatively, you could generate some shell scripts to invoke snoop to capture a specified number of packets, and then analyze which hosts were sending and receiving packets during the sample window. For example, snoop -d hme0 -o /tmp/snapshot -c will collect 10,000 packets and save them in the /tmp/snapshot file. You can then use snoop -i /tmp/snapshot | grep hostname |wc -l to determine how many of the 10,000 packets hostname contributed. Figure shows snoop used to monitor network traffic. WARNING: By default, snoop is a root-restricted command because the network interface device special file is created with root read permission. Some applications require that the network interface run in promiscuous mode. This changes the read/write modes of the device-special file such that any user on the host can use the snoop command to capture packets. You may want to have the root crontab invoke a utility such as ifstatus periodically to determine the mode of the network interface(s) on your hosts.

Host Configuration nettl
HPUX ships with a network sniffer utility called nettl. Many consider this one of the most annoying and useless packet sniffers available. The nettl application is actually very functional, but configuring and learning the user interface of nettl are very cumbersome. The nettl utility is included in the HPUX Network Tracing and Logging package. Once the nettl utility is installed, it is started (by default) at boot time. To disable this boot-time startup, you should edit the /etc/rc.config.d/nettl file and change the value of the variable NETTL to 0. The nettl utility reads its configuration from the file /etc/nettlgen.conf. The nettlgen.conf file specifies the default settings for the nettl (packet capture) and netfmt (packet display) tools. Starting the nettl utility seems somewhat cumbersome. The example that follows shows how to start nettl to capture the first 1024 bytes of all input and output packets on the loop-back and Ethernet interfaces. This command captures only IP packets, due to the ns_ls_ip directive. This example would capture packets to the file /tmp/raw0. # nettl -tn 0x e ns_ls_ip -size tracemax f /tmp/raw0 To view the data just collected, the user would need to invoke the netfmt command with the options required to format the output as desired. The following example shows the use of the netfmt command to give a one-line trace analysis of all packets captured to the /tmp/raw0.TRC0 file. # netfmt -N -n -l -1 -f /tmp/raw0.TRC0 > /tmp/fmt-10 The nettl utility provides the ability to incorporate filters into the packet capture and analysis process. A filter is a small “program” or specification that tells the utility what packets to capture/display. The filters can be used to specify source or destination addresses, MAC addresses, protocols, ports, and other useful classifiers for the packet capture/display. Consult the manual pages for nettl, netfmt, and nettlgen.conf for more information on the use of the HPUX nettl utility.

Host Configuration Public Domain Sniffers
Although most vendors ship a network sniffer with their operating system, these tools are often geared toward capturing packets that are known to follow the rules set out for the TCP/IP protocol stack. These vendor-supplied utilities often do not give the user the capability of capturing packets based on very specific criteria. The vendor-supplied tools also present a variety of user interfaces that often disagree on how the menus and data should be presented to the user. Luckily, there are several good public domain sniffer packages available on the net.

Host Configuration Ethereal
Ethereal, shown in figure 16-14, is a user-friendly UNIX-based program that also runs on Windows. It comes in both a read-only (protocol analyzer) version as well as a capture (sniffing) version. The read-only version is useful for decoding existing packet captures, as it avoids the hassle of installing a packet capture driver on the system. Data can be captured from a live network connection, or read from a capture file. Ethereal can read capture files from an impressive array of other sniffers, and can “uncompress” compressed data from other sniffers on the fly. Live data can be read from Ethernet, FDDI, PPP, token-ring, X.25, or Classical IP over ATM interfaces. Captured network data can be browsed via a GUI, or via the TTY-mode tethereal program. Capture files can be programmatically edited or converted via command-line switches to the editcap program. Output can be saved to disk or printed. Data display can be refined using a display filter. Display filters can also be used to selectively highlight and color packet summary information.

Host Configuration tcpdump
The tcpdump utility is a general-purpose packet sniffer that runs on many operating systems. The tcpdump utility was originally developed by Van Jacobson, Craig Leres, and Steven McCanne, all of the Lawrence Berkeley National Laboratory, University of California, Berkeley. It is currently maintained as a public domain package, and is available at Although its user interface is not nearly as friendly as the Ethereal interface, tcpdump is one of the more popular network sniffers available. This tcpdump utility is also available for Windows, but the Windows version is called windump. The windump/tcpdump utility allows you to create filters to capture any type of packet you might imagine. The filter language used by tcpdump is easy to learn, and is often used in laboratory exercises to teach TCP/IP networking. tcpdump does not attempt to make the output easy to read. The output is very concise, and once you get used to it, very easy to read and decipher. For example, to capture one ICMP packet, with the Ethernet frame information included and in hexadecimal output format, you could use the following. # tcpdump -vvv -i hme1 -e -c 1 -x ‘icmp’ 14:21: :0:20:7e:80:69 8:0:20:9a:5d:bc ip 98: cse.nd.edu > grumpy.cse.nd.edu: icmp: echo request (DF) (ttl 255, id 56704, len 84) dd ff01 68cc 814a 1965 814a c98 e144 b a0b 0c0d 0e0f a1b 1c1d 1e1f a2b 2c2d 2e2f 3435 One of the most powerful features of tcpdump is its ability to use filters to narrow down the type of packet to be displayed. This filtering capability makes tcpdump an extremely powerful tool. If you want to capture specific types of packets, all you have to do is write a filter that uniquely specifies that type of packet. Once you have the filter written, call tcpdump with the filter option, and tcpdump will use your filter as part of the packet selection criteria. The format of the filters is pretty straightforward. The basic formula for a filter is as follows. <header> [<offset>:<length>] <relation> <value> The relational operators tcpdump understands are =, <, >, <=, >=, and !=. The logical operators it understands are the and (&), or (|), and not (!) operators. A simple example of a filter would be a filter for capturing all telnet traffic, such as follows. # tcpdump -i hme1 -x ‘tcp[2:2] = 25’ This tells tcpdump to look at the tcp header. Skipping bytes 0 and 1 (the source port), and looking at bytes 2 and 3 (the destination port), if this two-byte field contains the value 25, this is an SMTP packet! To make life simpler, tcpdump also includes some built-in macros that make writing filters even simpler.

Host Configuration netstat
The netstat program is available under most operating systems. netstat has a different set of command line flags under each OS, so it is usually best to consult the OS documentation for the capabilities of netstat on your system. In general, netstat can display packet counts, and configuration information for your system. Some of the typical uses of netstat include display of input/output packet counts per interface, display of TCP/UDP sockets in use on a host, display of the ARP table for a host, and display of the routing tables for a host.

Host Configuration ping
If a host cannot be contacted on a network, the first question to answer is whether the problem is specific to the host or the network. A very useful command for making this determination is ping. The command name stands for “packet Internet groper,” and is used to test reachability of hosts by sending an ICMP echo request and waiting for a reply. The command name is often used as a verb, such as in “Ping pop to see if it’s up.” In the example, the blues machine sent 10 packets (1,024 bytes of data, and an 8-byte ICMP header) to the pop.plc.com machine. The pop machine answered eight of those 10 ping packets, as shown by missing packets with sequence numbers of 1 and 7. The network appears to be fairly fast, in that other than the very first packet the average round-trip time for the packets is short. By logging on to several hosts on a network and “pinging” other hosts, you can quickly determine whether the problem is network or host related.

Host Configuration Rebooting the noncommunicating hosts will frequently solve the problem. If rebooting does not work, examining the files and physical components previously listed would be the next step. In the absence of network diagnostic equipment, replacing components may be the only way to track down the failure. If, on the other hand, no hosts reply to pings, the problem is specific to the network. Some of the more common network faults follow. Missing or damaged terminators Broken or damaged cable (may not be visible) Faulty connectors Damaged transceiver (may be jamming the network) Once again, in the absence of network diagnostic equipment, replacing components may be the only way to precisely identify the cause of failure. If a host on one subnet is unable to contact a host located on a different subnet, and there is no difficulty pinging hosts on the local subnet, the problem could be one of the following items. Malfunction of the router connected to the subnet Malfunction of the network on the other side of the router Malfunction of a distant router not directly connected to the subnet Malfunction of the remote host Failure of a component or connection between the local host and remote hosts To locate the problem, use the techniques discussed earlier in this section for each subnet in question. With subnetted networks, ping is often all that is required to locate (or at least narrow down) the source of a network failure.

Host Configuration traceroute
The traceroute utility does exactly what its name implies: it traces the route from point A to point B. This utility can be very useful when trying to determine why two hosts cannot communicate. For example, to trace the route from a specific local host to a distant host, the administrator could invoke the following command. traceroute fully_qualified_hostname The traceroute command prints an informational message about each “hop” along the route from the local host to the remote host. Routing loops and inoperative hosts are very easy to spot in the traceroute output. Note that under Windows this utility is called tracert.exe.

Host Configuration Host Configuration
Unfortunately, connecting a computer to the network is not the end of the network configuration and management task. Once the system is on the network, the sysadmin needs to be vigilant to ensure that the system is secure.

Summary This chapter examined configuration files and utilities involved in the management of computer networking. Topics discussed include some simple network configuration commands, as well as coverage of several of the network configuration files. Examples of these configuration files were presented to illustrate the information required to configure a system for network operation. Finally, the chapter explored ways to monitor and troubleshoot local area networks.

Network Security Chapter 17

Chapter Goals Understand the need for security policies
Understand security threats Understand types of attacks Understand security analysis Understand attack tools Understand network security defenses. Understand what to do if you have been attacked

Network Security Many security experts consider the term network security an oxymoron. Securing a non-networked computer is difficult, but securing a networked computer sometimes seems impossible. Connecting systems to a network opens all sorts of avenues for security compromise, and much like drivers on New Year’s Eve, the security of one sysadmin’s hosts is often at the mercy of the security practices of other administrators on the network. In addition corporate management is often oblivious to security concerns. Before the administrator can implement steps to secure enterprise systems, someone has to create policies regarding issues such as acceptable levels of vulnerability, acceptable levels of risk, and levels of necessary security. The policy group needs to determine if convenience of use outweighs data security. WARNING: This chapter is intended as a primer on network security. System administrators who intend to connect systems to the Internet securely will need to read further.

Network Security Policies
Long before a sysadmin begins implementing security measures, someone in a position of authority should have put pen to paper and created security policies for the site. Without approved policies, the sysadmin is acting without the authority to enforce any rules/changes that need to be made to ensure the security of systems/data. This is the subject of many books. Because each enterprise has different needs and goals, it is not possible beyond the range of best practice to stipulate what your policies should include. Each set of policies should be customized for the site. About the only guideline that seems to be somewhat universal is that the policies should stick to the KISS principle: Keep it simple, stupid! Very detailed, wordy policies are often not read/understood by users. Worse yet, a certain class of users reads the policy with the idea “what can I get away with” in the back of his mind.

Network Security Acceptable Use Policy
One policy every site should create is an acceptable use policy(AUP). Some sites spell out the details of every acceptable and unacceptable action on the part of users in an AUP document. Some sites reference other documents for details, and use the AUP for general guidelines and to make the broad statement that users should abide by the rules in the referenced documents. Because the officers of the enterprise should approve the AUP, a simple one-page document that references other rules and regulations is often the smart way to go. Such an AUP should rarely require change, so the officers should not have to discuss this document very often. However, the actual “rules of conduct” (the implementation of the policy) may change frequently, without the need for management approval. Most AUP policies remind users that the computing resources of the enterprise are supposed to be a friendly, ethical community.

Network Security Enforcement
Actions that might be considered hostile are not welcome. Such actions might include (but not be limited to) the use of network sniffers, abusive , denial-of-service attacks, visiting certain types of web sites from corporate hosts, perusing other users’ files or without permission, forging , profit-making activities, or masquerading as someone else on-line. The policy should point the user to another document that paints a broader picture of the activities explicitly prohibited, and the consequences of such actions. Enforcement Policies are useless unless they can be (and are) enforced. Many sites have their legal counsel read and approve the document before it becomes part of corporate standards. This step helps ensure that the policy would withstand a legal test, and that the policy makers did not “take the law into their own hands” and/or create a document that could be fodder for litigation.

Network Security Implementing Security Policy
Even if the policy is “legal,” and has been blessed by the appropriate deities, someone has to enforce the rules. This “someone” is often the system administrator. This is one of the more unpleasant parts of the system administrator’s job. Anytime the system administrator can hand this task off to others, it is usually tempting to do so. The sysadmin may have to collect the evidence, and show why the incident is against the policies, but it is always nice when someone else is tasked with “enforcing” the policy based on the evidence. Implementing Security Policy Once the site has agreed upon a security policy, the administrator needs to assess potential threats to the site and implement a strategy to minimize such threats. The following is a recommended general procedure for assessing and ensuring host security.

Network Security 1. Make sure hosts are up to date with the most current vendor patches. 2. Survey your hosts to determine what services they offer. 3. Once you know what services are offered, determine which services are mission critical and which are not required. 4. When you have sorted out the required/unwanted service list, turn off unwanted services by editing start-up scripts and/or the [x]inetd.conf file. 5. Once the unwanted services are turned off, you need to determine how you can protect the required services. 6. With access to services protected, you should look at what type of information the services pass on to the network. 7. Monitor security mailing lists such as bugtraq – available at: Watch for vulnerability announcements for any service your systems provide, and obtain/install bug fixes as soon as they are made available by the vendor of the service software. 8. Monitor your log files and watch for signs of suspicious activity.

Threats Before exploring how to secure a networked environment, let’s examine the types of threats you might find in such an environment. Is data the item at risk? Is the business at risk? Are resources at risk? How do the bad guys gain access? Simply being aware of potential threats is a good thing, but formal risk analysis requires that you also know how likely a given threat is and/or the impact such an occurrence might have on the business. You want to get the “most bang for your buck” when spending money on security matters. Protecting against an unlikely threat is not a wise investment. For more information on risk management, visit nistpubs/800-30/sp pdf The System Administration, Networking and Security Institute (SANS) publishes a “top 20” list of security problems.

Threats Who Is Attacking Us?
A key question that should be considered before jumping into the security chapter is “who is interested in attacking my site?” What do I have on my computer that is so interesting? It is very difficult to guess the motives or identities of external attackers. Unfortunately, not all attacks come from outside the enterprise. When an internal attack occurs, and is detected, the corporation will usually take action to discipline the attacker. Other than reprimand, this can include termination of employment, criminal proceedings, and/or civil litigation. Internal attacks can be much more difficult to detect than external attacks, as they occur inside corporate defenses. Much of corporate monitoring and data collection is performed at the border with the outside world. Although external attacks may be more easily detected, punishment of the perpetrator is often nearly impossible.

Threats Who Is Attacking Us?
External attacks are often undertaken from third-party sites. The attacker is hiding behind someone else’s system to attack your site. Even if you can trace the attack to the third-party site, you have to rely on that site to track the attacker to the next site he hides behind. If you get extremely lucky, and gather enough evidence to positively identify the perpetrator, punishment will often be impossible, as the perpetrator is a foreign entity. Worse yet is the fact that many companies will refuse to press charges, as they do not want the negative publicity. As far as security work goes, the best policy is to treat all attacks, whether internal or external, the same. You need to collect evidence with the idea in mind that the case will go to court. This means that the sysadmin needs to know and understand the legal issues involved with the rules of evidence.

Threats Every step taken to identify the attack and track the perpetrator needs to be handled within the limits of the appropriate laws. If your enterprise has in-house legal counsel, it would be wise to involve them from the very first signs of an attack. Theft of Data One of the important classes of threats is theft (or attempted theft) of information from compromised computers. Sometimes this may be part of an espionage activity by a party outside the enterprise. Sometimes it may be a disgruntled employee trying to see how much money employee X makes. Even activities such as reading someone else’s as it goes by on the network, or reading user files because they are improperly protected, might be considered “theft of data.”

Threats Theft of Assets
Protecting corporate data is one of the prime activities of the system administrator. Ensuring that data is stored securely on the system is certainly part of the administrator’s responsibility. If the system administrator is also responsible for the network, the responsibility extends to ensuring that the network is secure, and that prying eyes cannot collect data from the network. Theft of Assets Another important threat is one that attempts to steal assets using corporate computers. This could be the theft of credit card numbers, bank account information, or personal information about employees (identity theft). Some enterprises consider corporate data and corporate assets as one entity. Others consider these two separate entities, and have separate rules governing access to each.

Threats Theft of Services
Like theft of data, some portion of protection of assets falls on the shoulders of the system administrator. Other portions of this task may fall on web administrators, network administrators, and others in the enterprise. But more often than not, the system administrator has the responsibility for the protection of this information. Theft of Services A very large percentage of system compromises are not carried out with the intent to steal assets or data from systems. The vast majority of compromises are carried out to steal services from enterprise computers. The attacker does not care what is on the computer, and may not even look to see what is there. She broke in so that she could use your computer to attack someone else. If you join any of the hacker bulletin-board/IRC systems, you may be surprised to see others on the channel “trading” the fruits of their attacks.

Threats The attackers use your system to hide behind. They use your system to attack other systems. If they get caught attacking someone else, that “other” entity thinks you are responsible, as the attack came from one of your computers! The attacker packs up and moves to another compromised system to hide and start again. Quite often, your systems are used in concert with other compromised systems to enact distributed denial of service (DDOS) attacks on some other entity. When the attacker decides he has enough ammunition, he commands all of his compromised drones to attack some other site. Huge streams of network traffic coming from many seemingly unrelated sites blind the site under attack. The site is effectively “out of business” until administrators responsible for those systems can be convinced to shut down the attacking drones. This is often a very time-consuming and expensive problem.

Threats Local Versus Network Issues
The principal difference between network security and local security is the fact that you have some control over your local users, but you have very little or no control over users that come to your site through the network. You can, however, exercise some level of control over which files and services your users have access to, and which of your users have access to a specific computer. When you connect your computer to the network, you silently give much of your control to the designers who implemented the network, and to the network services your systems support. You might quickly learn that not everyone on the Internet wants to be a friendly neighbor.

Types of Attacks How do the bad guys gain access to your hosts?
In many cases they exploit well-known security holes in the system software. The generic sequence of events in most attacks is as follows. Perform reconnaissance: Often through the use of network scans Determine points of weakness: Analyze the output from the scan Exploit weak points: Attack the weak points found by the scan Hide the evidence: Patch the hole and “root kit” the system so that others cannot see that the machine has been compromised Burn, pillage, and loot: Use the compromised system for activities other than its intended purpose Sometimes these steps happen in very rapid succession (within seconds or minutes of each other). This is indicative of an automated scanning tool. Other times these steps may occur very slowly (over a matter of days or weeks). The slower scans are often intended to escape detection by staying “under the radar” of anyone watching error logs and other alarm systems.

Types of Attacks Host-provided Services
Hosts that provide services on the network do so according to rules that govern network communications. For the TCP/IP protocol, hosts are required to use an Internet Protocol address to identify themselves. This IP address is similar to a street address; it tells other computers on the Internet where this host is located. All communications bound for this host are sent to the host’s IP address. Extending the IP Address Through Ports Hosts on the Internet often provide services used by other hosts on the Internet. For example, the telnet, ftp, mail, http (web service), and ssh utilities are services provided by typical hosts. These services may be provided using the Transmission Control Protocol (TCP services), or the User Datagram Protocol (UDP services). These protocols provide a simple extension of the IP address scheme in order to provide “entry points” for network services. This extension is called a port. Every computer provides up to 65,536 TCP ports and up to 65,536 UDP ports where network services live. If you view the IP address as the address of a building, you could view the ports as doors into the building. What a building! It has 131,072 doors! And behind every door there is (potentially) a service provided by your computer. The UNIX file /etc/services lists some of the more common services provided by computer systems. It is important to note that not all of these services are provided by every computer on the Internet. Nor is it likely that all of the services provided by a computer on the Internet are listed in the /etc/services file. When you enable a network service daemon on your computer, you are telling it to listen on a specific port for connections to that service. There are several ways of starting these service daemons.

Types of Attacks Persistent Services
Persistent services are started at boot time by init scripts. These services bind themselves to a port, and are always running. When a remote system wants to connect to a service on the local host, it contacts the port number for the persistent service. The persistent service (typically) creates a copy of itself, starts the copy running on an ephemeral port, and directs the caller to talk to the copy of the service running on the new port. Typical persistent services are smtp ( ), httpd (WWW server), and inetd. The inetd daemon is a “super daemon.” It manages several other service daemons that are not persistent.

Types of Attacks inetd Services
The inetd daemon manages nonpersistent services. These services are launched upon demand by inetd. When the system boots, inetd reads its configuration file (/etc/inetd.conf or /etc/xinetd.conf) and binds itself to several ports. When a request comes in for one of the inet-managed services, the inetd binary launches the real service daemon, and connects the caller to the service (much like an old manual telephone switchboard). Typical inet-controlled services include tftp, ftp, telnet, rlogin, rsh, and ssh.

Types of Attacks RPC Services
Another method of providing network services is via the Remote Procedure Call (RPC) interface. Calling programs contact the rpcbind (sometimes called the portmapper) process to ask if the host provides a specific service. The rpcbind daemon checks its configuration files to see if the service is being offered, and if so redirects the caller to the port where the requested service is listening.

Types of Attacks Preventing Unauthorized Access to Services
One way hackers gain unauthorized access to your systems is to contact the services your computer is providing. For this reason, one of the best defenses against unauthorized access is to disable services you do not need to provide. Another good defense against unauthorized access to your computers is to put a wrapper around the service. The wrapper checks to see if the caller is authorized to connect to the service. One tool that provides this wrapper service, the tcp_wrapper utility. How do hackers find what services your computer is providing? They use a tool that can scan the network, probing each of the 131,072 ports on every IP address. These tools are known as port scanners, and they are used to implement network scans.

Types of Attacks Network Scans
One method of performing reconnaissance is to scan the “target” network. Each of the scanning tools released does a little bit more, or a little bit better job, than its predecessor. The types of tools and the success they provide are frightening. One of the things a sysadmin should do is download these tools and try them against his own hosts. This allows the administrator to harden the network based on the finding of the tools. Knowledge of these tools also helps the administrator understand what type of information the attacker is trying to gather, and what clues the system will give when under attack by someone else using this tool.

Types of Attacks Low and Slow
One of the most worrisome types of network scans is one that is barely perceptible. The attacker works very slowly, and very methodically, to gather information about the target. These scans are worrisome because someone is trying to gather information very discreetly. They are trying to stay below the system administrator’s radar (low), so they are very patient (slow). The attacker is often a skilled and very determined foe. Typically these attacks often lead to theft of important data or assets from the target site. These attacks can be very costly to the enterprise. If someone manages to steal all of the corporate secrets, the company could be out of business. Worse yet, if the attack is detected, and word leaks to the news media, the site’s customers (and possibly shareholders) may abandon the company due to lack of confidence.

Types of Attacks Fast and Noisy
The alternative to a low and slow scan is a fast and noisy scan. The tools employed for these scans can map out an entire Class B network space in a matter of minutes (fast). Well-instrumented target systems should spew reams of warning messages when these scans hit (noisy). Many times the scanning tools used in a fast and noisy attack have the ability to compromise a system as soon as vulnerability is found. Although these tools are very efficient, they give you plenty of warning that they have visited your site. Quite often the attacker is looking to compromise as many systems as possible to use for attacks on others, or as an army of drones in an upcoming attack. The attacker is often somewhat skilled in computing. They may have developed their own attack tool, and used your site as a test to see if it worked in the wild. These attacks can be very bothersome for the system administrator. Someone has to clean up the mess made by the attackers. This often means collecting forensic evidence, determining how to protect against such attacks in the future, and then rebuilding the infected systems from distribution media.

Types of Attacks Script Kiddies Script kiddiez and ankle biterz are just two of the demeaning epithets for attackers perceived as possessing few real computer skills. The scripted attacks are often fast and noisy. The attackers often use someone else’s scanning tools that they downloaded from the Internet, and the attacker may not even understand how the tool works. Many times the attacker “saw this tool on the net and decided to try it out.” Once they compromise a system, the attackers usually do not look for data to steal; the system was hacked for sport, and/or to use in attacks against other sites. These attacks are often the most vexing for the system administrator. The scripts used in the attack have little mercy. The attack tools blindly replace system binaries as part of their attempt to be stealthy once the system has been compromised. If the purpose of the attack is to assimilate a drone, or otherwise attack other hosts, the tool makes no attempt to limit its consumption of resources.

Types of Attacks Buffer Overflows
Many scripted attacks scan an entire network looking for a specific service to compromise. These attacks often look for a version of a network service known to have a security flaw. Quite often the flaw the attack seeks is a buffer overflow. Buffer overflow attacks take advantage of poor coding practice on the part of the network service developer. The developer did not take the time/effort to ensure that data read by the program/service would actually fit into the container provided to hold that data. When too much data is provided to such a program, the data overflows the buffer (container). If the vulnerable program operates with special privileges, this often allows the attacker to craft an attack that will give them access to your system with these elevated privileges. TIP: One of the best ways to protect against buffer overflow attacks is to limit services your hosts offer, and to keep up to date with security patches from your software vendors.

Types of Attacks Some operating systems provide a means of disabling “stack execution” on their systems. Buffer overflow attacks often rely on the ability to overflow the buffer with code that lives on the program stack. The code that overflows the buffer is typically a small program that will spawn a privileged shell. Once the buffer overflow has been accomplished, and the program tries to exit, the exploit code is executed, and the attacker has access to the system. These attacks rely on the stack allowing the execution of the exploit code.

Types of Attacks Disabling the ability to execute code from the stack can help defuse some of these attacks. For example, if the following directives are placed in the Solaris /etc/system file, the system will prohibit many of the buffer overflow attacks from executing exploit code for the attacker. These directives also command the system to log a message warning that someone attempted a buffer overflow attack. set noexec_user_stack=1 set noexec_user_stack_log=1 Unfortunately, this method is not foolproof, as there are ways to defeat this security mechanism. Fortunately, most of the “attack tools” do not (currently) implement methods to get around this defense.

Types of Attacks Other operating systems are compiled using special compilation techniques that are supposed to prevent buffer overflow attacks. There is a special version of RedHat Linux (Immunix), compiled with a StackGuard compiler, that is supposed to stop buffer overflows. Like the Solaris technique, this attempt has produced modest success, but the hacking community has found holes in this defensive strategy. Defense in depth may be the only short-term hope for elimination of successful buffer overflow attacks. NOTE: Buffer overflows also affect non-network services. Many buffer overflow exploits require that the attacker be logged in on your system. Once the attacker is logged in on a valid user account, he often exploits a buffer overflow in a setuid program to gain unauthorized privileges on the system.

Types of Attacks Social Engineering
One of the oldest, yet still widely successful, attack tools is social engineering. Many security consultants make use of social engineering tactics when performing security audits. One social engineering method has the attacker do something as simple as call an employee on the phone and ask for information that will help the attacker gain access to the computer. Access to the computer makes the task of compromising the computer much easier to accomplish. Another form of social engineering is “dumpster diving.” The attacker goes through the company trash looking for slips of paper that might contain user names, phone numbers, addresses, and sometimes passwords. Sometimes the attacker gets lucky and finds network drawings, printouts of router filters, or other critical information that can assist in attack planning and execution.

Types of Attacks Social Engineering
The best way to protect against social engineering reconnaissance is to educate your users about security. Utilities that require frequent password changes, or that use one-time passwords, also help limit the success of social engineering attacks. A system administrator that looks for odd log-in locations/times of users can help detect such attacks. A good paper shredder is also a handy tool to have on hand to secure (several facets of) an office environment.

Types of Attacks Sniffers
Packet sniffers are multi-faceted attack tools. The attacker may use a sniffer to perform social engineering. The attacker can listen to all conversations, and collect log-in names, passwords, and other information that will assist her when she decides to compromise a host. Wireless networks are extremely susceptible to this form of attack. Administrators that come across the output from packet sniffers might need to contact hundreds of users and make them change their passwords. Packet sniffers may also be used as part of the orchestration of much more technically challenging attacks. The attacker may capture secret encryption keys as she traverses the network. By recording the keys, and all communications using those keys, the attacker has means of decrypting the communication. Sniffers can also be used to provide information on how the attacker might hijack a communication session, or masquerade as a trusted host to gain access to private information.

Types of Attacks Sniffers
Most of the time sniffers are nearly impossible to detect. The sniffer does not generate any network traffic. They merely sit and listen to everything that goes by on the network. At some point the attacker contacts the sniffer, and collects the information for “off-line” analysis. If nobody notices the sniffer in action, it may be present on the network for months (or longer), collecting information for the attacker.

System Security Analysis
Every system administrator should be concerned about the security of his or her systems, but how do you determine how much security is enough? What should you do to ensure that your systems are secure? Defense in Depth One way to view the security of a well-secured system is to compare it to the layers of an onion. Security tools and techniques provide layers of protection from unauthorized use such that the inner layers may stop an attack that managed to get past outer layers. This is often called “defense in depth.” From a security standpoint, defense in depth of a computer begins with a secure local system (the core), followed by a layer of checks using tools such as tripwire. A layer of password controls and monitoring is an essential layer of system security, as is an outer layer of carefully configured services.

You also need to apply this defense in depth security model to the network equipment itself. Routers and switches and other network gear should be secured using the layered defense strategy. Secure hosts providing secured services to “secured users” on a secure network might allow a paranoid sysadmin to get a few hours of sleep at night.

Patches Before you attempt to test the security of your systems, it would be wise to install the latest patches available from the vendor. Keeping up with patches is a time-consuming, tedious process, but it is also one of the best ways to keep your system secure. Tripwire Another thing you may want to do before testing your systems is update your tripwire databases, and make sure you will be able to catch any files that change as a result of the security testing. Some of the test tools will attempt to create files on your system in order to “prove” that the tool was able to compromise the system.

Tools New security tools appear on the Internet every day. The tools discussed in the sections that follow are a miniscule sample of all that are currently available. These have withstood the test of time and remain popular and viable security assessment tools. A vigilant sysadmin should also download and try many other tools. Knowing how these tools work helps the administrator secure systems against attacks. Watching messages generated by these tools should also help the administrator recognize when the tool is used to attack hosts.

Entercept The Entercept package is a server-based intrusion protection package. The Entercept package is a multi-layer tool that protects applications, the operating system, and communications drivers. This protection is provided via a set of behavioral rules, system call interception, and http (web server) call interception. The Entercept package is available at

Crack Crack, although not a network scanner, is a very useful tool to have in the security toolbox. Crack is a password cracker. Although some may argue that it is better to have a password program that will not allow users to choose “bad” passwords, a good password cracker can be a very useful tool. If you think you have a good password program, periodic Crack scans can assess just how good the password program is. Crack employs various encryption algorithms and dictionaries to try to break the passwords on the system. Because the inner layer of defense in depth relies on strong user authentication, a good password cracker is essential. The Crack tool was developed by Alec Muffitt, and is available at ftp.cert.org

COPS Another tool that is not a “network” security scanner but is still a useful scanner is the Computer Oracle and Password System (COPS). The COPS scanner attempts to break passwords, check file permissions on the system, and locate setuid/setgid programs. COPS was written by Dan Farmer, and is available at

Center for Internet Security Scanner The Center for Internet Security (CIS) scanner project is a program that may be used as a ruler to judge how your system measures up as far as security is concerned. The CIS scanner checks your system against a list of settings known to provide reasonable security. For each setting your system meets or exceeds, you score points. For each setting your system falls below the recommended setting, you lose points. The final outcome of the scan is a score between 0 (low) and 10 (high), which provides a relative indication of how secure your system is. The CIS scanner is available at The CIS site also contains tools for checking your system for the SANS Top 20 security problems.

JASS The Solaris Security Toolkit, informally known as the JumpStart Architecture and Security Scripts (JASS) toolkit, provides a mechanism for minimizing, hardening, and securing Solaris operating environment systems. The primary goal of JASS is to simplify and automate the process of securing Solaris systems. JASS is available at

Nmap The Nmap security scanner is one of the most widely used security scanning tools available. Nmap is a port scanner that slices, dices, and otherwise wreaks havoc with your network. Nmap can generate various types of packets that probe the TCP/IP stack on your systems. Nmap can generate a list of open service ports on your system, penetrate firewalls, and even provide hauntingly reliable “guesses” at what operating system (complete with patch level and version number) is running on your host. The Nmap security scanner is available at

Nessus The Nessus project is a remote security scanner. Nessus employs Nmap to perform some of the tasks it undertakes, but also has plug-in modules that can test for well-known security problems. The Nessus developers are quick to develop modules used to test for the latest published security problems. Because Nessus is a remote scanner, the administrator can configure the tool to scan the entire network and report on all hosts it finds. Unlike many other scanners, Nessus does not rely on finding given services on their assigned ports. Nessus will probe every TCP and UDP port on a system, and if it finds something will probe that port further in an attempt to determine what service it has found. Nessus plug-ins are able to locate backdoor programs, DDOS agents, services that contain buffer overflows, insecurities in network file systems, database security problems, web server security problems, and many other common security holes. The Nessus scanner is available at

Saint The Security Administrator’s Integrated Network Tool (Saint is an updated version of the SATAN security scanner. Saint is a web-based tool that can be configured to locate systems on the network, and scan them for well-known security problems. Although the number of tests performed by Saint is smaller than the list of tests performed by the Nessus tool, Saint is still under active development, and is a reasonable tool to have in the security toolbox. Saint is available at

dsniff dsniff is a collection of tools for network auditing and penetration testing. The collection includes dsniff, filesnarf, mailsnarf, msgsnarf, urlsnarf, and webspy. The tools passively monitor a network watching for interesting data. dsniff also includes (arpspoof, dnsspoof, and macof) to facilitate the interception of network traffic normally unavailable to an attacker, due to layer 2 switching. The remaining two components of the dsniff package are sshmitm and webmitm. These utilities implement active man-in-the-middle attacks against redirected SSH and HTTPS sessions by exploiting weak bindings in ad hoc Public Key Infrastructure (PKI).

Root Kits Root kits are not tools for gauging the security of your network. In fact, they are tools used by attackers to hide their presence on compromised systems. The root kits come with Trojan versions of many system utilities. The real system utilities allow the administrator to list files, list processes running on the system, list active network connections, examine binary files for text strings, and perform similar functions. Luckily, root kit detectors are also available on the Web. The chkrootkit package checks for signs that a root kit has been installed on a system. The chkrootkit package checks for over 30 types of root kits, and checks over 60 critical operating system command binaries to ensure that they have not been altered. In addition, the chkrootkit package checks for network interfaces running in promiscuous mode, checks the lastlog and wtmp files for signs that they have been edited, and checks for loadable kernel module root kits. The chkrootkit package is available at

Defenses Network Services Access Control Methods
Computer systems offer a wide range of services to other entities on the network. By default most of these services do not employ encryption to keep prying eyes from monitoring the information they make available on the network. Most of these services do not (by default) create log entries detailing connections to the service. Access Control Methods One way to improve the security of system services is to limit access to the service. This can be accomplished (at least) two ways: (1) disable the service such that it is not available for use and (2) implement a list of hosts/users allowed to use the service and force the system to check every inbound request for this service to ensure that the user/host requesting the service has permission to use the service.

Defenses Not Using It? Turn It Off
The easiest way to control access to a network service is to turn it off. Problem solved; if the service is not running, it cannot be compromised. But this is not always an acceptable solution. On the other hand, there are wide ranges of services enabled by default, but these services are not required for normal operation of the system. Simple Services Almost every TCP/IP stack includes a group of services referred to as “simple services.” This group of services includes the time, chargen service, echo service, and discard services. All of these services listen on TCP and UDP ports. These services are not required for normal operation. These services should be disabled. Under UNIX operating systems this can be accomplished by commenting them out of the /etc/inetd.conf file (/etc/xinet.d for Red Hat Linux) and then causing inetd to reread the startup files. You can force inetd to reread startup files by invoking the following command. kill -HUP {PID for the inetd process}

Defenses On Windows systems, use the network control panel to remove the “simple TCP” services. Some operating systems also provide the capability of performing a “trace” on every incoming network request. This is a good function to enable. Under recent versions of Solaris you can enable this function by editing the file /etc/init.d/inetsvc and changing the invocation of the inetd program from inetd -s to inetd -s -t. Under other operating systems you may need to enable the auth daemon, or in a few cases download and install the portable ident daemon (pidentd) The pidentd daemon is available at

Defenses Other Unnecessary Services
Each operating system ships with a number of inet services that may not be needed. Services often disabled include : rquotad, rpc.rusersd, sprayd, walld, rpc.statd, ufsd, cachefsd, kerbd, gssd, and in.talkd. tnamed, uucp, exec, rexd, comsat, finger, systat, netstat, time, sadmind, linuxconf,

Defenses Point and Shoot (Yourself in the Foot)
There are several system services known to be “bad things” to run. These services are known to be security problems, yet they are run for several bad reasons: there are no better solutions, time does not permit replacing them, “it has always been done that way,” and “we can’t afford the down time to fix them.” Chief among these “bad things” that weaken security is to allow programs to pass information across the network in clear text. Another nemesis is a service that does not require authentication of the remote user. Yet another class of dangerous services is those that allow the remote user to alter the configuration of the local system. When these services are compromised, you have shot yourself in the foot (as the old saying goes). We all know better, but for one (bad) reason or another we do not remove the ammunition (fix the problem) before the trigger is pulled.

Defenses Plaintext Authentication
One type of service you should consider disabling is a class of services that perform plain-text authentication. These services pass the user’s log-in name and password across the network as unencrypted data. Anyone sniffing the network can collect this information and use it to gain unauthorized access to your systems. Services that allow plain-text authentication include rlogin, rsh, telnet, ftp, http, imap, and pop. Technically, it is a simple matter to disable these services. Comment them out of /etc/inetd.conf, or remove the binary program. If the service is not installed on the system, or is not available, it cannot be exploited.

Defenses Plaintext Authentication
On Windows 2000 systems, make sure the following registry key is set to the value 0. [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkStation\Parameters] "EnablePlainTextPassword"=dword: Politically, attempts to disable these services are met with stiff resistance. This is one of many instances in which strong policies can make the life of the system administrator easier. If the site’s security policy forbids the use of services that require plain-text authentication, the administrator is free to disable these services. However, keep in mind that you may need to provide a secure replacement for many of these services.

Defenses Other Problematic Services
The services discussed in the previous section are services that should not be offered. The system will function without these services, and/or there are secure versions of these services that can be installed in place of the insecure versions. Trivial File Transfer Protocol The Trivial File Transfer Protocol (tftp) is a simplified version of the ftp protocol. The tftp protocol was originally intended for use as an aid to boot-diskless workstations. Once the diskless system located its server, the operating system was downloaded to the workstation using tftp. tftp comes with several built-in security problems. For starters, tftp does not require any authentication. Anyone that can connect to a running tftp server will be able to download files. They may also be able to overwrite files in the tftp directory. Another problem with tftp is that it expects the repository of information it serves to be stored with UNIX permissions of mode 777 (read/write/execute for everyone). Unfortunately, many routers, switches, and other devices still employ tftp to upload and download configuration files, firmware, and software updates. If you must use tftp, it is strongly recommended you leave it disabled, turn it on when you need to use it, and then disable it when you are done. If you have access to source code for tftp, you should consider compiling the tftp daemon using tcp_wrapper libraries to provide access control and logging of tftp connections. Some Linux distributions, such as Red Hat, supply a tftp daemon with tcp_wrappers already compiled. Another way of providing some security for tftp is to create a chroot jail for tftp and its files. A chroot jail creates an environment in which the tftp binary is allowed to read/write only specific directories, and has limited permissions. If you are running Linux, and have the xinetd service daemon installed, you could create a chroot jail for tftp using an xinetd configuration entry similar to the following. service tftp_chroot { log_on_success = HOST PID DURATION USERID log_on_failure = HOST RECORD USERID no_access = socket_type = stream protocol = tcp port = 9000 wait = no user = root server = /usr/sbin/chroot server_args = /usr/etc/servers /usr/libexec/tftpd } NOTE: Many sites also run the regular ftpd in a chroot jail to improve its performance.

Defenses Common Desktop Environment
The Common Desktop Environment (CDE) is a windowing system. The original implementation was developed by Hewlett Packard, and was named HP-VUE. More recently, Hewlett Packard, Sun Microsystems, and IBM have collaborated to bring the package to all of their operating systems. The package was renamed the Common Desktop Environment. The CDE package includes several network daemons that facilitate use of the windowing environment across several hosts. Several of these services have been found to be insecure. However, turning off all of these services may render the windowing environment unusable. The following portions of the CDE environment may be turned off without completely disabling the environment. Some CDE functions may not operate with these daemons disabled.

Defenses Common Desktop Environment
rpc.ttdbserverd: tooltalkobject manager fs.auto: Font server kcms_serverd: Allows access to user profiles across a network. rpc.cmsd: Calendar manager dtspcd CDE subprocess control service

Defenses named The named binary is an implementation of the Domain Name Service (DNS) daemon. This daemon should be running only on hosts that provide your enterprise name service. Several recent attacks have been released against named. Some of these attacks make use of buffer overflow compromises to give the attacker elevated privilege access to your system. Other attacks use the DNS software to force the machine to participate in a distributed denial of service (DDOS) attack against other hosts on the network. NOTE: There are several packages available for providing name service. Some of these packages have (so far) been more secure than others.. The tcpd package provides two ways of protecting service daemons: library routines that may be compiled into the service daemon binary and a “wrapper” daemon that acts like a bodyguard for the actual service daemon. NOTE: The tcpd wrapper works for TCP services only. It cannot protect UDP services, and will not protect RPC services unless the modified rpcbind software is installed along with the tcp_wrapper software. The rpcbind daemon can also be replaced with a version of rpcbind that works in a fashion similar to the TCP wrapper software. The replacement rpcbind logs denied connections using syslog. This program is available on the CERT and COAST sites listed at the end of this chapter. Several current versions of UNIX include the tcp_wrapper, xinetd, and secure rpcbind utilities. Included in this group of operating system distributions are most versions of Linux, BSDI, and MacOS X. NOTE: The replacement rpcbind program is fairly dated and has not been updated recently.

Defenses Wrap It Up (tcpd)
Because it is impractical to disable all services, you need another way of limiting access to services such that only authorized users may use them. If you could somehow convince every application to check an access control list before it allowed a remote user access to the service, you might have a chance of providing the service with some assurance of security. The tcp wrapper program (tcpd) is a surrogate service daemon that can be used to protect other service daemons. Protecting Programs Using tcpd Library Routines The tcpd libraries provide a series of system calls programs can use to check whether a remote host has permission to contact a service running on the local host. When the service daemon is compiled, and linked using these libraries, it will check the /etc/hosts.deny file, and then the /etc/hosts.allow files, to determine whether the remote host has the appropriate permissions to use this service.

Defenses Protecting Programs Using the tcpd Daemon
The second method of protecting programs with tcpd is to force tcpd to “answer” anytime the service daemon’s port is contacted. One way of doing this is to edit the inetd.conf file and “replace” the actual service daemon with a call to tcpd. The tcpd program is called with the name of the actual service daemon as an argument. The tcpd binary checks hosts.deny, and then the hosts.allow files, to see if the caller has permission to contact the service daemon. If permission is granted, tcpd starts the service daemon, and the conversation progresses normally. Typical entries in the /etc/inetd.conf file might look like the following. ftp stream tcp nowait root /usr/sbin/tcpd in.ftpd -l -i -o telnet stream tcp nowait root /usr/sbin/tcpd in.telnetd If you are using the xinetd daemon, the configuration is a little bit different. For starters, the /etc/xinetd.conf file does not contain any useful information. Instead, look in the /etc/xinetd.d directory. You should find configuration files for each service managed by xinetd. The following examples illustrate equivalent xinetd configuration files for the previous telnet and ftp examples. The telnet information would be stored in /etc/xinetd.d/telnetd, whereas the ftp information would be stored in the file /etc/xinetd.d/ftpd. service telnet { flags = REUSE NAMEINARGS protocol = tcp socket_type = stream wait = no user = telnetd server = /usr/sbin/tcpd server_args = /usr/sbin/in.telnetd } service ftp { user = ftpd server_args = /usr/sbin/in.ftpd } These entries cause inetd/xinetd to launch the /usr/sbin/tcpd program anytime a host attempts to contact the in.ftpd or in.telnetd program on the protected host. Once the remote host has been authenticated, and tcpd has determined that the remote host is allowed to use the service, the tcpd daemon will call the actual service daemon with all appropriate arguments. To do this, it uses the information that appears to the right of the call to /usr/sbin/tcpd (or in the case of xinetd on the server args line).

Defenses /etc/hosts.deny
tcpd relies on two text files to configure access to services. These two files provide two methods of protecting the system: allow everything except what is explicitly denied, or deny everything except what is explicitly allowed. The /etc/hosts.deny file lists the services available, and the names/addresses of hosts not allowed to use the service. A site that used the “allow everything except that which is explicitly denied” logic might have hosts.deny files with entries similar to: in.ftpd: insecure-host.plc.com in.telnetd: all These two entries tell the tcpd package that the host insecure-host.plc.com is not allowed to contact the ftpd binary. The file also tells tcpd that all hosts are disallowed use of the in.telnetd program. Sites that use the “deny all except that which is explicitly allowed” strategy might place the following in the /etc/hosts.deny file to disallow all contact from the outside to any service protected by tcpd: ALL: ALL

Defenses /etc/hosts.allow
The /etc/hosts.allow file performs the opposite function of the hosts.deny file. Entries in this file tell the tcpd package to allow access to the listed services. The following are example entries: in.fingerd: .nd.edu ALL: .plc.com sshd: ALL rpcbind: / rpcbind: These entries tell tcpd that all hosts in the nd.edu domain can finger at the local host, that all hosts in the plc.com domain may use any service on the local host that is protected by tcpd, and that any host that connects to the sshd service is allowed to use this service. The last two entries tell tcpd that any host on the network is allowed to contact the rpcbind (RPC port mapper) service on localhost. Logging tcpd Messages One of the nice features of the tcpd package is that it allows you to log all refused connection attempts via syslog.

Defenses Services Protected Using tcpd Windows 2000 Access Control
It would be very difficult to compile a complete list of every program that could be protected by the tcpd package. Luckily, most hosts only offer a few services, and most of these services are common TCP-based daemons. Some of the more common packages wrapped using tcp-wrapper are portmap, rlogin, rsh, telnet, ftpd, lpd, and finger. Windows 2000 Access Control Under Windows 2000, you can use the Network control panel to limit access to the system’s services. Under the Internet Protocol TCP/IP item, click on the Properties button. Click on the ADVANCED button, and then select the Options tab. Select the TCP/IP filtering entry, and then select Properties. Enter the port access information you desire, and then click on the Enable TCP/IP filtering (All Adapters) button to enable the filters.

Defenses Providing Services on Alternate Ports
Some sites attempt to secure their network services by providing services on nonstandard (alternate) ports. Although this method may work for a while, it may not provide the desired protection in the long run. Security through obscurity does not provide much protection against tools such as Nessus and Nmap. These tools will be able to detect that something is listening on the port, and will report this fact to the attacker. The attacker can then probe the service in an attempt to determine what it is.

Defenses Alternate Versions of Service Daemons
Another way some sites improve the security of their systems is to employ alternate versions of network service daemons. Several Open Source and commercial entities provide service daemons that have been hardened against attacks. A few of the more common alternate service daemons are ftpd from wuftpd and pureftpd, telnet replacements from MindTerm and SecureCRT, and scp (a replacement for rcp that is distributed as part of many ssh packages).

Defenses Encrypt It Another method of securing network services is to force the service to encrypt all communications with other hosts. Although this method does not prevent a remote host from using the service, it does make it more difficult for someone running a sniffer to determine what the hosts are saying to each other. NOTE: If the “encrypted service daemon” contains a buffer overflow, it may still be possible for an attacker to gain access to the system. Older versions of the ssh program suffered such a fate. You should consider wrapping encrypted services with tcpd, or compiling these services using the tcp_wrapper libraries, when possible. The primary benefit of ssh is to prevent passwords and other information from being intercepted en route to a remote machine. ssh employs strong encryption and long keys to prevent this, as well as encrypted access keys on top of the normal password mechanisms. ssh also provides key management facilities that greatly reduce the need to use access control files, such as .rhosts, for most remote connections. It is also possible to tunnel other sessions through an ssh connection, thereby protecting these services. Some sites provide secure tunnels for services such as IMAP mail systems, the X-windows system, and FTP services, whereas other sites obtain site licenses for encrypted network tools, and completely disable nonencrypted services such as telnet. The ssh capabilities are also available for MacOS X and Windows systems. In fact, MacOS X includes the Open Source version of ssh, OpenSSH. There are also commercial and public domain versions of ssh for earlier versions of MacOS and for Windows. Commercial versions are available from F-secure (among others), and public domain versions are available from the following sources. · NiftyTelnet (for MacOS 9): freeware/niftyssh/ · PuTTY (for Windows): ~sgtatham/putty/ · Another very handy ssh tool is MindTerm. The MindTerm package is a Java applet that provides ssh versions 1 and 2 clients. The MindTerm package can be used as a command line utility or as a web-based applet. MindTerm is available at

Defenses ssh One solution to the clear-text problems of the r commands and the threat of snooping is to use a secure communications program that encrypts all data for transit. The ssh package is used at many sites as a drop-in replacement for the r commands, ftp, and telnet. Because there are also ssh clients for Windows and MacOS systems, the ssh package is useful for employees who require access to corporate computing facilities from remote sites (which may not be secure). The ssh package provides a secure remote communications channel. The ssh package can be obtained from The ssh package includes complete configuration and installation directions.

Defenses PGP The Pretty Good Privacy (PGP) package is a freely distributable public-key encryption package. PGP is available for UNIX, Windows, MacOS, Amiga, DOS, and most other operating systems. PGP has become one of the most widely used encryption tools. The PGP vendor (Network Associates) recently decided to discontinue distribution of its commercial version of PGP. Freeware versions remain available at A public domain version of PGP is also available. The Gnu Privacy Guard package, also known as GnuPG (or simply GPG), is a complete and free replacement for PGP. GPG is available at

Defenses Zebedee Zebedee is a package that allows you to establish an encrypted, compressed “tunnel” for TCP/IP or UDP data transfer. This allows traffic such as telnet, ftp, and X to be protected from prying eyes, as well as providing, via data compression, improved performance over low-bandwidth networks by compressing the encrypted data before sending it across the network. Zebedee provides full client and server functionality under UNIX/Linux and Windows. Zebedee employs algorithms that are either unpatented or for which the patent has expired. Zebedee is available from

Defenses Stunnel Stunnel is another program that allows you to encrypt arbitrary TCP connections inside SSL (Secure Sockets Layer). Stunnel is available for both UNIX and Windows. Stunnel can allow you to secure non-SSL aware daemons and protocols (such as POP, IMAP, and LDAP) by having Stunnel provide the encryption. The Stunnel source code is not a complete product; that is, you still need a functioning SSL library such as OpenSSL or SSLeay to compile Stunnel. This means that Stunnel can support whatever your SSL library can, without making any changes in the Stunnel code. Stunnel is available at One-time passwords do not rely on encryption to maintain the security of an account. Instead, the system generates lists of passwords that are good for one use only. Each time a user logs in, a different password is used. The downside is that a user can print out a sheet of passwords generated by the tool and carry the list around in his pocket. Most one-time password tools do not allow the user to select his own passwords. OPIE is available at

Defenses One-time Passwords in Everything
The One-time Passwords in Everything (OPIE) package is a password-hardening tool. It is particularly useful when the remote host does not offer any encrypted forms of remote user authentication. A standard exists for one-time password systems (RFC1938), and OPIE is one of the tools that implement this standard. OPIE is a successor to the S/Key tool from Bellcore (now called Telecordia Technologies).

Defenses Secure Remote Password The Secure Remote Password (SRP) package is another tool that can be used to encrypt network traffic. SRP is a lesser-known alternative to ssh. If both ends of the connection agree that they can use the SRP protocol, the connection is encrypted transparent to the user. This approach allows the user to keep using her favorite commands, and allows the sysadmin to do something other than install new versions of ssh every week. The downside of SRP is that it introduces yet another password file. The /etc/tpasswd file contains the SRP version of each user’s password. The sysadmin needs to replace the system’s password program with a program from the SRP distribution. This new version of password synchronizes the /etc/passwd and /etc/tpasswd files. SRP is available at

Firewalls Another approach to limiting access to your hosts is to pass all network traffic through a filtering router and/or firewall. This approach constitutes an attempt to deal with all possible avenues of access by carefully controlling the network traffic as it passes through network electronics. An advantage of this method is that it provides some measure of security for all services, including those added later or services created by individual users. A disadvantage of this approach is that the inspection of packets impedes the traffic flow across the network.. This configuration embodies the principle of defense in depth (internal hosts cannot talk directly to the outside world). Users must log in on one of the bastion hosts to talk to the outside. Similarly, outside hosts cannot talk directly to internal hosts. External hosts can, however, communicate with bastion hosts. Bastion hosts typically provide services such as telnet, ssh, httpd, , and ftp. Some sites install proxy servers on bastion networks to allow other services to pass through the firewall from the bastion host. Bastion hosts are often the target of attacks, as they are outside corporate defenses.

Firewalls The hosts inside the enterprise are protected by two firewalls. The border router often provides filtering to eliminate some of the attacks headed for the corporate network. This router is between the outside world and a set of “bastion hosts” on a network, referred to as the demilitarized zone (DMZ). The firewall is placed between the DMZ and the internal network. Instead of using two separate devices to implement this scheme, some sites use one router or firewall with three interfaces (to connect to the outside, the DMZ, and internal networks).

Firewalls Classification of Firewalls Packet Filters
There are three general firewall classifications (listed in order of increasing security): packet-filtering (plain and stateful) firewalls, circuit proxy firewalls, and application proxy firewalls. Packet Filters A filtering router/firewall conditionally passes network traffic between networks. The router filters are rules developed by the network manager. These rules tell the router which packets should be allowed to pass, and which packets should be rejected. Depending on the particular router, it may be able to pass traffic based on the source or destination IP address, the source or destination port number, or other information contained in the packet. A filtering router restricts access to a service on a system by allowing (or disallowing) network traffic to enter (or leave) the network.

Firewalls Stateful Filters Classification of Firewalls
There are certain types of network traffic that are very problematic for firewall systems. Among this traffic are so-called protocol benders, such as ftp and traceroute, and fragmented packets. Stateful firewalls boast the capability to handle these odd conversations. Protocol Benders The ftp protocol is particularly troublesome for firewalls. The ftp protocol uses a pair of connections to transfer files. One connection, initiated by the client, is used to send commands to the ftp service host. This connection is generally made between an ephemeral port on the client and TCP port 21 on the server. When the client asks for a file from the server, the server opens a connection to the client system’s TCP port 20.

Firewalls A nonstateful firewall might not allow the server to open this port, as the idea of a firewall is to block unwanted connections from external hosts. A stateful firewall keeps track of conversations initiated by hosts “behind” the firewall. When such a host opens an ftp connection to an external system, the firewall keeps track of this connection in a special state table. When the remote ftp server attempts to open the ftp data connection on port 20, the firewall consults its open connection table and allows/disallows the connection to proceed based on the information found in the table.

Firewalls Fragmented Traffic
Another type of traffic that is a problem for many firewalls is a conversation that includes fragmented packets. Packet fragmentation occurs as a natural part of transmitting data across the network. As large packets are forwarded to networks that only transport small packets, the packet is fragmented into smaller pieces for transport. The destination host is supposed to reassemble these fragments into a complete packet. Intermediate routers are not supposed to reassemble these packets as they traverse the network. Unfortunately, the hacker community also determined that it could fragment attack packets into small pieces, and sneak them through many firewall systems. When the target host reassembled the attack packet, the hacker could compromise the system. Stateful firewalls can reassemble fragmented packets and then determine if they should be allowed to pass through the firewall.

Firewalls Nonstateful Firewalls Application Proxy Firewalls
With an understanding of stateful firewalls, the definition of a plain (nonstateful) firewall is pretty easy to discern. Plain firewalls do not keep any state information regarding current connections. These firewalls are incapable of detecting problems that deal with fragmented packets or protocol bender applications. Application Proxy Firewalls Another firewall design is called the application proxy. An application proxy does not allow any traffic through the firewall. The application proxy behaves as a server to clients on the trusted network, and as a client to servers outside the trusted network. A client on the trusted network sends connection information to the proxy firewall. The firewall applies its policy rules to determine whether to allow the requested connection. If the request is permitted, the proxy firewall will send the request to the destination. The source IP address on the packets sent to the remote host will be that of the firewall, not that of the original client.

Firewalls By operating at the application layer, application proxy firewalls provide finer granularity when it comes to policy rules. For example, specific URLs can be blocked from certain subnets, or FTP clients can be restricted from performing a Put, but permitted to execute a Get. An added advantage of application-layer proxy operation is the ability to require strong authentication before allowing the connection to proceed. Application proxy firewalls also possess the ability to create detailed logs of security events. One drawback to the application proxy is that proxies must be provided for each application. Several Internet applications –(including FTP, , and news) are bundled into most browsers. These applications can be handled by configuring the browser to talk to the firewall. Custom applications and network applications not bundled into a browser will require custom firewall configurations.

Firewalls Circuit Proxy Firewalls
Although application proxy firewalls provide the highest level of security and finest-grain control, they can also be the most complex to configure. In addition, because they act as relay agents for all clients on the network, performance can be problematic. Circuit Proxy Firewalls Circuit proxy firewalls are a variant of application proxy firewalls. Circuit proxy firewalls relay TCP and UDP connections between (trusted and untrusted) networks after authenticating end points. The best-known implementations of circuit-level gateways employ an IETF standard protocol, SOCKS. SOCKS firewalls require modifications to applications or to client TCP/IP stacks. Most browsers have built-in SOCKS support, and modified protocol stacks are also available for various flavors of UNIX, various flavors of Windows, and MacOS. Circuit proxy firewalls require a significant administrative effort to implement in a sizable enterprise.

Firewalls Types of Firewalls Host-based Firewalls
Under each classification of firewall there are two types of firewalls. Host-based Firewalls Host-based firewalls are programs installed on each computer. These programs intercept traffic that comes in to the host via the network interface. The package checks a rules file to see if this packet should be allowed to continue its journey to the system’s TCP/IP stack for processing. If the packet is on the “allowed” list, it is passed to the TCP/IP stack for normal processing. If the packet is not on the “allowed” list, the firewall package may log a copy of the packet complete with an error message, and set off alarms. The firewall package should not allow such packets to be passed to the TCP/IP stack.

Firewalls ipchains The ipchains utility employs an ordered set of rules to determine if the packet should be allowed to pass to the host’s TCP/IP stack for further processing. The ipchains package defines three default chains, but the administrator is free to declare other chains in addition to the following three default chains. Input: This set of rules examines every packet bound for this host. Output: This set of rules examines every packet originating on this host. Forward: This set of rules examines every packet that must be forwarded to another host on the network.

Firewalls The ipchains rules result in one of the following actions.
Accept: The packet is okay; allow it to pass to the appropriate chain. Deny: The packet is not okay; silently drop it in the bit bucket. Reject: The packet is not okay; but inform the sender of this fact via an ICMP packet. Masq: Used for IP masquerading (network address translation). Redirect: Send this packet to someone else for processing. Return: Terminate the rule list. NOTE: The ipfw (ipfilters/iptable) package under BSD operating systems provides similar functionality to ipchains. Consult the manual page for ipfw for more information on this package.

Firewalls BlackIce Defender
TIP: An easy-to-use interface to ip chains, called brickhouse, is available for MacOS X. See Brickhouse makes creating rules easier by including common settings and common names for specific protocols and sockets. BlackIce Defender The BlackIce Defender package is one of a plethora of personal firewall utilities for Windows operating systems. It operates in a manner similar to ipchains/ipfw. The user builds a set of rules the system uses to determine if a packet should be allowed to continue to the IP stack. Other packages that provide the same functionality are Personal Firewall and Network Ice.

Firewalls Tiny Firewall
The Tiny Software company produces several host-based packages that are highly recommended. The Tiny Firewall package is a host-based firewall package for Windows operating systems. Like the other host-based firewalls, the user builds a series of filters to protect the host from external connections. Another offering from Tiny Software is the Tiny Trojan Trap. The Trojan Trap provides protection from active content such as Java, , ASP, and macro viruses. The tiny tools are available at

Firewalls Dedicated Firewalls
Dedicated (network based) firewalls are specialized systems that attempt to protect entire networks as opposed to protecting a single host. These devices are placed between two networks. The firewall system is loaded with configuration files that specify what types of packets should not be allowed to pass through the device to the other network. There are several types of dedicated firewall systems, including packet filtering firewalls and proxy firewalls.

Firewalls Firewall Policies Along with the types of firewalls, there are two general firewall policies: allow everything except that which is explicitly denied, and deny everything except that which is explicitly allowed. The first policy requires a lot of operator fine-tuning, and can be problematic to implement. The “allow all but that which is denied” policy generally requires considerable computational horsepower in the router. The “deny all but that which is allowed” policy is usually easier to implement, less prone to operator errors, and typically does not require as much computational power on the part of the router.

Firewalls Drilling Holes in the Firewall
WARNING: Even at their best, firewalls do not provide a complete answer to the network security problem. Firewalls do not provide security to individual hosts. They do not protect hosts on the “secure” network from “inside” attacks. A single hole in the firewall may allow attackers access to all hosts on the “protected” network. Mistakes in the configuration of a firewall may go unnoticed without other security measures in place. Resist the temptation to open a hole through a firewall without studying the possible impact on the security of the enterprise. A firewall’s purpose in life is to block network traffic. The best firewall might be one that does not let any packet through. This is somewhat akin to being disconnected from one of the networks. Unfortunately, this makes doing business on the Internet very difficult. Most companies will not allow such a firewall to be installed. Therefore, once we install a firewall on a network, we immediately begin drilling holes through the wall to allow some information to pass through the barricade.

Firewalls Some firewalls allow very few types of information through. This generally means that these firewalls have had minimal holes drilled through them. Other firewalls allow data to flow in and out of the organization, as as if there were no firewall present. This generally means that the firewall has had numerous holes drilled through it. In this case, you may as well not bother with the expense of the firewall. Virtual Private Networks Virtual private networking (VPN) allows users to build an encrypted connection across an unencrypted link. Many corporations employ VPN technology to allow users to pass data through firewalls. To establish a VPN connection, both ends of the link must agree on encryption keys. The VPN routers may be separate devices, or their functionality may be built into other pieces of network equipment.

Firewalls The VPN devices may be in-line, or may reside on bastion networks. When a connection is requested, the remote host contacts its VPN router, and asks for a connection to the local host. The VPN routers build an encrypted tunnel across the unencrypted network. The VPN routers are essentially a proxy service. When the two hosts communicate, the encrypted packets are intercepted by the VPN routers, and decrypted. The content of these packets is sent to the end hosts involved in the communication. Note that the encrypted traffic is allowed through the firewall unimpeded; therefore, the security of the entire network relies on the security of the hosts using the VPN. If one of those hosts is compromised, all hosts on both networks are vulnerable to compromise!

Firewalls IPSEC Ipsec is an IP protocol security package. PSEC is a series of protocols that allow the implementation of encryption over an IP connection. IPSEC, in reality, is the base that most virtual private networks are built on top of. The IPSEC package allows for the following two modes of operation. The headers of the packet are not encrypted, but the data in the packet is encrypted. The entire packet is encrypted, and encapsulated within an unencrypted packet. IPSEC requires that the administrator configure the following databases. Security Policy Database (SPD): Database of security policies that may be applied to an IPSEC device. For example, an SPD might contain information that means: to access network , use 3DES for encryption with HMAC-MD5 for authentication. Security Association Database (SAD): Database that contains the information for each currently established IPSEC link.

Firewalls IPSEC relies on/provides the following services.
Internet Key Exchange (IKE): Method of distributing encryption key information. This piece of the puzzle is still under development. RFC 2409 is the standard for IKE, and is currently under consideration. Authentication Header (AH) protocol: Protocol used when the desire is to encrypt just the transport layer header, and data. Encapsulating Security Payload (ESP) protocol: Protocol used when the entire packet is encrypted, and encapsulated within a nonencrypted packet. NOTE: IPSEC will have an impact on the processing speed of the system’s IP stack!

Firewalls Network Address Translation
Network Address Translation (NAT) was originally developed as a way for sites using private address space to allow hosts to communicate over the public network. The address translation is a proxy service that maps the internal (private) address to an external (public) address. As packets pass through the NAT router, the packets are modified to replace the private address with the public address of the router. The router keeps a table detailing ongoing conversations. When a packet arrives from a remote host, the router checks the table to see which host was communicating with the remote system. The router then alters the IP addresses, and forwards the packet to the internal host. The NAT box provides a proxy translation service.

Firewalls The use of NAT technology is growing rapidly due to the growing base of DSL and cable modem Internet connections. Cable modem and DSL networks are prime playgrounds for hackers, and there are hundreds of thousands of systems connected to the Internet that are ripe for the hacking. This is true because most home computer users do not realize they need to do something to secure their computer from the denizens of the Internet. One way to protect home computers (and corporate computers as well) is through the use of NAT.

Network Stack Options The TCP/IP protocol suite was not developed with today’s attacks in mind. Many portions of the protocol suite provide extremely fertile environments for attackers to explore and take advantage of. Although it is important for the sysadmin to understand these weaknesses, it is nearly impossible to catalog even a small portion of the attacks possible due to gray areas in the specifications and/or inconsistencies in stack implementations. The IP protocol defines several optional services hosts may make use of during a communication session. Many of these options are rarely seen in the wild. Some of these options are used to collect data about a target network, or to finagle ways of getting information to hosts on the target network.

IP Options IP Forwarding
IP forwarding is the process of forwarding IP packets from one network segment to another based on the protocol layer address of the destination. Routers and multi-homed hosts do this routinely. Sometimes sysadmins know that the hosts in their domain are forwarding packets, and sometimes users forget to tell the administrator they configured their hosts to do this. Therein lies the problem. Attackers have learned that they can sometimes circumvent firewalls and other monitoring devices using misconfigured devices that provide IP forwarding. For this reason, the sysadmin might decide to explicitly disable this capability on systems within the enterprise.

IP Options Source Routing
Source routing is another option that is rarely generated (on its own) by the TCP/IP protocol stack. Intended as a way for administrators to reroute traffic around failures, this option has earned favor as a stealthy attack mechanism. The source routing option allows the sender to specify a loose or strict route from host A to host B. A loose route is a list of devices the sender wants this communication to go through on the way to the final destination. The network equipment may decide to add stops along the way. A strict source route is the exact route the sender wants this communication to traverse. Because source routing allows the sender to avoid monitoring devices, and may allow them to divert traffic to undesirable locations, it is wise to disable this function, or at a minimum to monitor it closely.

IP Options ICMP and ICMP Redirects
The ICMP protocol is intended to act as a network control protocol. Recent attack tools have pointed out that the original intent of several types of ICMP packets is not the only use for such packets. A router usually issues an ICMP redirect to inform a host of an alternate path to a destination. Attackers have learned to use this method to cause hosts to redirect all communications through another host. In effect, the attacker tells the system “send everything to me, and I’ll deliver it for you.” The result is that the attacker has access to all communications sent from host A to host B through this intermediary.

IP Options Fun with Broadcasts
Broadcast packets are an essential part of the IP version 4 protocol. Not surprising, the hacker community has found ways to use broadcast packets as attack tools. One “famous” attack was implemented by sending a forged ping packet to a directed broadcast address. This caused all hosts on the network to reply to the “sender.” Unfortunately, the sender’s address was forged, so the reply packets (tens of thousands of them) all went to an unsuspecting target. For example, ping would have caused all hosts on the network to reply. This attack was called the “smurf” attack. Other forms of this attack have used the local broadcast address ( ) and directed subnet broadcast addresses (for example, ). To minimize the ability of her site’s hosts from responding to this type of attack, the administrator needs to disable the host’s ability to respond to broadcast pings.

IP Options Session Hijacking
Session hijacking is a technique whereby the attacker monitors TCP packet sequence numbers, and predicts the next sequence number. Using this technique it is possible to take over (hijack) a session between two hosts. This method was extremely successful against some operating systems, as the algorithm that was used to generate “random” sequence numbers was not random at all! Most vendors currently ship their systems with relatively weak sequence number generators. Fortunately, vendors give the administrator a method of forcing the system to use much stronger sequence numbers.

IP Options Other Stack Attacks
Multi-homed hosts have been used to forward spoofed packets to the network. If your stack offers the option of hardening multi-homed systems, it is recommended you take advantage of these options. SYN floods are a method used to tie up the resources of the system. A remote host sends thousands of SYN packets to initiate TCP connections, but the sender never completes the three-way TCP handshake. This leaves the local host in a state of confusion. The host needs to hold these connections open until the other end responds, or the connection times out. This may exhaust the resources of the local host. One attack type not handled by modifying driver parameters is IP spoofing. These attacks make use of a trust relationship between two systems and the ability to predict the sequence numbers used in a TCP connection. To reduce the predictability of sequence numbers, some operating systems implement a better system of creating initial sequence numbers, as recommended in RFC 1498.

IP Options Hardening the Stack
The following sections list default settings and methods of “hardening” (generally disabling) for the previously outlined problems. These constitute only a partial list of TCP stack variables that may be tuned in order to harden an operating system’s IP stack. Refer to your host’s documentation for more information on the stack implementation for a specific operating environment. NOTE: Most operating system vendors provide tools and technical white papers that describe their TCP/IP stack implementation, and how to harden their respective stacks. For example, the JASS toolkit for Solaris includes a script for checking/configuring a huge number of stack variables. Contact your OS vendor for the most up-to-date and comprehensive list of stack variables for your systems.

IP Options The following are IP forwarding hardening strategies.
Solaris: Default setting (disabled), harden with ndd –set /dev/ip ip_forwarding=0 HPUX: Default setting (enabled on multi-homed hosts), harden with Linux: Default setting (host disabled, gateway enabled), harden with gateway_enable=0 in /etc/rc.conf Windows: Use the network control panel to disable IP forwarding, or set the following registry key to 0. HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\IPEnableRouter=0

IP Options Source Route Handling The following are source route-handling hardening strategies. Solaris: Default (setting enabled), harden with ndd –set /dev/ip ip_forward_source_route=0 HPUX: Default setting (enabled), harden with Linux: Default setting (ignored), harden with echo 0 >/proc/sys/net/ipv4/conf/interface/accept_source_route=0 BSD/MacOSX: Default setting (ignored), harden with forward_source_route=0 in /etc/rc.conf accept_source_route=0 in /etc/rc.conf

IP Options ICMP Redirect Handling
The following are ICMP redirect-handling hardening strategies. Solaris: Default setting (enabled), harden with (N/A) HPUX: Default setting (enabled), harden with (N/A) Linux: Default setting (Host enabled, gateway disabled), harden with echo 0 >/proc/sys/net/ipv4/conf/interface/accept_redirects=0 BSDI/MacOSX: Default setting (enabled), harden with icmp_drop_redirect=0 in /etc/rc.conf; icmp_log_redirect=1 in /etc/rc.conf Windows 2000: Set the registry values for EnableICMPRedirect and EnableICMPRedirects to 0, as follows. HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\EnableICMPRedirect=0 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\EnableICMPRedirects=0

IP Options Broadcast Ping Handling
The following are broadcast ping-handling hardening strategies. Solaris: Default setting (enabled), harden with ndd –set /dev/ip ip_respond_to_echo_broadcast=0; ndd –set /dev/ip ip_forward_directed_broadcast=0 HPUX: Default setting (enabled), harden with Linux: Default setting (enabled), harden with echo 0 > /proc/sys/net/ipv4/ip_echo_ignore_broadcasts BSDI/MacOSX: Default setting (disabled), harden with icmp_bmcastecho=0 in /etc/rc.conf

IP Options TCP Sequence Number
The following is a TCP sequence number hardening strategy for Solaris. Solaris: Default setting (weak protection), harden with ndd –set /dev/tcp tcp_strong_iss=2 Multi-homed Packet Spoofing The following is a multi-homed packet-spoofing hardening strategy for Solaris. Solaris: Default setting (enabled), harden with ndd –set /dev/ip ip_strict_dst_multihoming 0 SYN Floods Solaris: Default setting (enabled(, harden with ndd –set /dev/tcp tcp_conn_req_max_q NOTE: On versions of Solaris prior to 2.6, use ndd—set /dev/tcp TCP_CONN_REQ_MAX 1024.

IP Options Windows 2000: Set the following keys in the registry entry as specified. Registry: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services Value name: SynAttackProtect=2 Value name: EnableDeadGWDetect=0 Value name: EnablePMTUDiscovery=0 Value name: KeepAliveTime=300000 Value name: NoNameReleaseOnDemand=1 Value name: tcpmaxconnectresponseretransmissions=2 Value name: tcpmaxdataretransmissions=3 NOTE : You must be using Windows 2000 Service Pack 2 (SP2) or later to use the NoNameReleaseOnDemand value.

Network Monitoring Monitoring the network is a never-ending task.
The sysadmin must be ever vigilant in order to catch the wily attacker. But there are several ways of monitoring the network, from simple log file monitoring to using management tools such as SNMP and RMON to the high-end intrusion detection systems (IDSs). Along the way, some sites even employ sacrificial honeypot systems that are easy to compromise. By monitoring what the bad guys do to the sacrificial lamb, the administrator has a pretty good idea what they have done to, or are trying to do to, other systems at the site.

System Monitoring Log Files
One of the easiest ways of monitoring your network is to configure all of your systems to send syslog messages to a central syslog server. This allows you to monitor all systems from one host. It also makes life for the attacker more difficult. Many times the attacker will edit the log files stored on the compromised host. They will remove all signs that they ever logged in on the host. But the attacker may not notice that the messages were also sent to another host. And if they do notice, they now have to compromise a second host in order to completely cover their tracks. syslog The syslog file is the primary log file under most versions of UNIX. This file receives copies of all system messages generated by the syslog utility. The syslog file, placed in different locations (e.g., /var/log/syslog, /var/adm/syslog, and /var/syslog) per different versions of UNIX, is the most important file to monitor.

Log Files NOTE: The syslog daemon is controlled by a configuration file, /etc/syslog.conf, which can be modified to increase the detail of recorded log file messages, and optionally to display messages on the system console, or broadcast to the terminals, of specific users. syslog is also a network service, and logging can be directed to another machine (such as a central logging server). By default, Solaris does not record unsuccessful log-in attempts. To enable this logging, add the following line to /etc/syslog.conf. auth.info /var/log/authlog This statement informs the syslog daemon to record the events tagged as “LOG_AUTH” with a severity of “INFO” or higher in the file /var/log/authlog. The next step is to create this file and the corresponding loginlog file. The following commands accomplish this. touch /var/adm/authlog /var/adm/loginlog chown root /var/adm/authlog /var/adm/loginlog chmod 600 /var/adm/authlog /var/adm/loginlog chgrp sys /var/adm/loginlog

Log Files mail.debug @log.astrocorp.com
WARNING: An attacker who has gained unauthorized access to a machine you manage will most likely know about these log files and will modify them to remove any indication of his/her actions. Log file monitoring needs to be performed in concert with tools such as ASET and tripwire to provide a high level of assurance that unauthorized access is discovered. Another feature of syslog is remote logging. Any of the information logged by syslog can be transmitted to another syslog process on another system. This allows for log information to be centralized. This has several benefits, including ease of monitoring and making it more difficult for an attacker to hide his or her tracks. The following is an example of a line from syslog.conf that sends the log messages to the mail facility at level debug or greater to a remote system. Note that instead of a file name the followed by a host name is used.

Log Files sulog The log file produced by the su command is another item a system administrator should check on a routine basis. The command logs both successful and unsuccessful attempts to obtain root privileges. Successful su attempts have a plus symbol (+) listed after the date and time; unsuccessful attempts show a hyphen or minus sign () after the date and time. Unsuccessful su attempts should be investigated thoroughly. Any attempts made by persons not authorized to perform system administration tasks might be a sign of a security breach.

Log Files Other Log Files
The following are system log files that should be routinely checked. [as]ppp.log: PPP software logs errors and connections here. Watch for failed connections as indicators of problems. syslog: Here, by default, the syslog service writes error messages produced by sendmail. Watch for errors of all types. messages: By default, the syslog service writes error messages from a number of different daemons to this file. Watch for errors of all types. maillog: Optional sendmail log file. Check this file for signs of unauthorized relay, or attempts to gain access to the system via the SMTP service. cron/log: By default, the cron daemon logs a message when it runs a scheduled cron job. Watch here for proper operation of scheduled jobs.

Log File Parsers Log File Parsers
If you decide to make your systems log everything to a central log file server, you might want consider the use of tools for summarizing the data you have collected. At a moderately large site, the log information collected can be quite lengthy and difficult to visually parse. Several tools are available for parsing these combined syslog files and automatically generating alarms when certain types of messages are logged. swatch One popular syslog parsing tool is swatch. swatch can actively monitor a log file and look for patterns. When swatch finds a matching pattern, it can display messages or run commands, such as sending to alert the system administrator. swatch can be found at

Log File Parsers logcheck
logcheck is a log parser distributed by Psionic Corporation. logcheck is available for multiple versions of UNIX, at Intrusion Detection Systems Intrusion detection systems (IDSs) are similar to firewalls. The difference is that IDS systems do not (typically) block traffic. The IDS system monitors every packet that traverses the network. The IDS compares every packet to a set of rules that specify what the administrator believes are bad (dangerous) packets. If a bad packet is found, it is logged. The logging may be in real time, in which case an alarm may be set off. More often than not, the log is processed at a later date, so real-time alarms are not available. Many IDS systems do not perform content filtering. They simply look at packet headers to determine if the packet is dangerous or not.

Log Files IDS systems that perform content filtering are available, but you may want to check your company’s rules about the use of these systems, as some may consider them an invasion of privacy! Several IDS packages are available free from the Internet. There are also many commercial IDS systems available. The following sections describe some of the more popular IDS systems. See for more information on IDS freeware and commercial offerings. tcpdump tcpdump was originally developed by Van Jacobson’s TCP/IP research group at Berkeley. tcpdump is a rules-driven packet sniffer. If the rules are simple (catch everything), tcpdump can capture everything that goes by on the network, and log it to a file.

Log Files The log file can them be played back through a different set of filters to pull out the “interesting” packets. The SHADOW IDS is one IDS system that employs tcpdump to collect raw packets for analysis. tcpdump is available at NOTE: The SHADOW IDS system is not a real-time IDS. The information is collected and stored for a short interval (typically an hour) and analyzed off-line. Although this near real-time operation may be useful for collecting archives of conversations, it would not be acceptable for many commercial sites.

Log Files SNORT SNORT is a rules-driven IDS package. SNORT loads a set of rules and compares every packet to the rules. If the packet matches a rule, the packet is logged. SNORT has the ability to log the captured packets in tcpdump format, but by default it generates a text file containing the alerts. There are several add-on utilities that can parse SNORT logs, and generate web pages containing the output. SNORT also has the ability to send resets to the attacker (active response), to close connections. SNORT is available at

Log Files bro Commercial IDS Systems
bro is another rules-driven IDS system. bro contains a powerful description language used to create capture filters. Although the bro language is very powerful, and makes for a nice IDS package, many sysadmins find it cumbersome to work with, as it is yet another language to remember. bro was developed at Berkeley, and is currently available at Commercial IDS Systems Several companies produce IDS systems. Among these are Cisco, Internet Security Systems, Network Flight Recorder, and Check Point Software Technologies. It seems that every day another offering pops up on the market. The following offerings are well-respected commercial IDS systems.

Log Files Network Flight Recorder (NFR) is a commercial IDS system produced by Network Flight Recorder. Information is available at RealSecure is a commercial IDS system developed by Internet Security Systems (ISS). Enterasys Dragon is a series of tools, applications, and hardware that forms the basis of one of the top commercial IDS systems. Information on the Enterasys Dragon IDS is available at Cisco IDS (Formerly NetRanger) is Cisco’s second generation IDS system. Information on Cisco IDS is available at

Honeypots Honeypots Honeypots are specially instrumented “bait” for attackers. The honeypot appears to the attacker to be a normal system on the network. The honeypot is not secure; in fact, it is often configured to be anything but secure. The idea behind the honeypot is to allow the attacker to break in, and then log everything the attacker does while on the system. By monitoring every keystroke the attacker types, the sysadmin can learn a little bit about the skills of the attacker, the tools the attacker employs, and possibly the attacker’s motives. The deception toolkit (dtk) is one honeypot package. The dtk package is available at Others include BackOfficer Friendly, Mantrap, CyberCop Sting, and Spectre. Consult .co.uk/honey.htm/ for more information on honeypot systems.

Simple Network Monitor Protocol
SNMP The Simple Network Monitor Protocol (SNMP) is an optional part of the TCP/IP package on most operating systems. The SNMP protocol defines packet types that allow a management host to poll client hosts (agents) in order to collect data about the client. The data collected is often performance information related to network interfaces on the host. This includes packet counts, byte counts, and error counts per interface. The SNMP package on most systems has been found to be very insecure. It is recommended you disable SNMP unless you absolutely need to run it.

SNMP SNMP also allows a method for using SNMP to configure remote devices. This requires that a “write-community” (password) string be enabled on the remote host. The SNMP management station authenticates itself to the remote host using the write-community string, and proceeds to write new configuration information to the remote client. This is a very dangerous capability! The variables that can be set include IP address, gateways, name servers, and other important IP information.

This capability should be disabled unless it is critical to the operation of your network! SNMP operates on data structures called management information bases (MIBs). Every network device manufacturer provides MIB definitions for its products. The SNMP management information station uses the MIB to determine what information is available in read/write form for the agent system(s). WARNING: Several security problems have been found with the SNMP protocol. Make sure you read all CERT and manufacturer security notes about SNMP before enabling it on your systems! The Remote Monitor protocol (RMON) is built on top of an SNMP MIB. RMON allows even more information to be collected from the host, including memory use, CPU utilization, disk space utilization and throughput, application layer statistics, number of users, processor load, and input/output statistics.

Forensics Forensics is the science of collecting evidence and assessing its meaning. Computer forensics generally deals with collecting evidence after a host has been compromised. The legal concepts of “chain of evidence” and “preservation of evidence” are also important facets of forensics. Depending on several factors, it may be necessary to have someone on the system administration staff trained in the legalities of the collection of evidence, or to keep an organization trained in forensics on retainer in the event your hosts get hacked.

When You Think You Have Been Hacked
The first thing to do when you think you have been hacked is to take a deep breath and relax. You might as well relax for a minute before you dive into the hunt. Once you have caught your breath you need to think about how you plan to approach the problem. You think a system has possibly been compromised. Anything you do that might change the state of the machine might destroy valuable evidence. Even the act of logging in on the machine to look around may compromise the legal value of the evidence, as log files record the fact that you logged. This same log file might contain information detailing the IP address of the machine that compromised the host. However, by logging in you may cause this information to be tainted, as you altered the evidence.

Even the act of performing a file system backup can alter evidence. The backup program “touches” each file. This changes the access time on a file, thereby tainting it as evidence. Special programs are available for performing backups that do not alter any access information for the files. You might consider checking out the Coroner’s Toolkit (TCT). The toolkit is a collection of utilities that can help determine what happened, when it happened, and how it happened. The toolkit is available at NOTE: The TCT tool is not “court proven” at this point in time. If you want to ensure that your evidence is court eligible, you might want to look at the Encase product from Guidance Software. Information on the Encase software is available at

You should also try to avoid letting the intruder know that you are watching. This is one place an IDS system can be extremely valuable. You create a set of filters to monitor all communications to and from the suspect host. By monitoring from another host, you are not disturbing evidence already on the compromised host’s disk drive.

When You Know You Have Been Hacked
Again, the first thing to do when you know you have been hacked is to take a deep breath and relax. You might as well relax for a minute before you dive into the task of forensics and remediation. Every site should have a well-documented disaster recovery plan that includes a plan for dealing with attacks and compromised hosts. This plan should include the following elements.

When You Know You Have Been Hacked
How to react to the attack Collection of information about the attack Determining what level exposure this incident has caused Rules to determine when to disconnect this system from the network, or the entire site from the network A uniform recovery plan How the recovery plan will be communicated to users Steps involved in implementing the recovery plan Information regarding how to report the incident to the appropriate authorities An incident response team should be formed to deal with all compromises. This ensures that every compromise is handled using the same procedures. In the event this becomes a legal case, the uniformity may be helpful. This team might want to use the CERT incident reporting form, available at , to standardize the information collection and reporting process.

Summary Securing networked systems is a challenge, especially for systems connected to the Internet. The current Internet provides an environment rich in potential threats, including automated scans and attacks. Almost every OS provides numerous network services, each with the potential of offering unauthorized access. This chapter discussed several methods of securing a networked system. The use of firewalls and/or filtering routers can provide a site with a first line of defense against unauthorized access. Turning off services wherever possible affords the best security. When services are required, careful attention to access methods and controls, and continual monitoring for unauthorized access, can help make a networked system more secure.

Resources Chapman, Brent, and Elizabeth D. Zwicky, Building Internet Firewalls. Sebastopol, CA: O’Reilly & Associates, 1995, (ISBN ). -– (Covers the setup and maintenance of firewalls.) Computer Emergency Response Team (CERT);, – (The national contact for computer security. This web site contains a wealth of information on security matters, and pointers to the security software mentioned in this chapter.) Computer Incident Advisory Capability (CIAC);, – (Government and education contact for computer security. Provides an excellent mailing list, with updates on the latest security problems and their solutions.) ftp://coast.cs.purdue.edu/pub/-– (A well- known FTP archive for security tools, including TCP wrappers, tripwire, nessus, nmap, and satan. Garfinkle, Simson, and Gene Spafford, Practical UNIX and Internet Security, 2d edition., Sebastopol, CA: O’Reilly & Associates, 1996, (ISBN ).. -– (A detailed and complete guide to security for UNIX systems connected to the Internet.)

Resources Garfinkle, Simson, and Gene Spafford, Web Security and Commerce. Sebastopol, CA: O’Reilly & Associates, 1997, (ISBN ). -– (Targets web server security and security of transactions executed over the Web.) McClure, Stuart, Joel Scambray, and George Kurtz, Hacking Exposed: Network Security Secrets & Solutions, Third Edition,3d ed., Stuart McClure, Joel Scambray, George Kurtz, September 26, 2001,New York: McGraw-Hill Professional Publishing;, 2001, ISBN: Northcutt, Steven, Network Intrusion Detection: – An Analyst’s Handbook,. 2nd edition, Steven Northcutt, 2d ed., New Riders Books, Indianapolis, IN: New Riders, ISBN Pomeranz, Hal (ed.), Solaris Security: Step by Step. Colorado Springs, SANS Institute, 1999; (719) or (A very thorough checklist of procedures for tightening the security of a Solaris system. Step-by-step guides for Linux, Windows, routers, and intrusion detection are also available format csec-top.html. -– (Professor Gene Spafford’s well-maintained Purdue list of security-related web sites.)

Network File Sharing Chapter 18

Chapter Goals Understand concepts of network file sharing
Understand NFS server setup Understand NFS client setup Understand NFS security Understand NFS mount options Understand differences and similarities between AFS and NFS Understand basics of Microsoft File Sharing

Network File Sharing File servers make files available to other hosts on the network. File service clients obtain file systems from file servers. File service peers are (both) servers and clients. Network file sharing employs Remote Procedure Calls (RPC’s).

Network File Sharing Network File Systems allow the users files to “migrate” from workstation to workstation with them. Network File Systems simplify life for the user, but generally make system administration more complicated (due to the setup costs). In Lab 6 we will setup the Sun Network File System (NFS) services on the lab machines. NFS has two components: The server side software, and the client side software. Each component is actually a suite of programs which implement the sockets required to provide network based filesystems. NFS is stateless.

Network File Sharing Server side: Rpcbind (portmap)
Mountd - respond to mount requests (sometimes called rpc.mountd). Relies on several files /etc/dfs/dfstab, /etc/exports, /etc/netgroup nfsd - serves files - actually a call to kernel level code. lockd – file locking daemon. statd – manages locks for lockd. rquotad – manages quotas for exported file systems.

Network File Sharing Client Side biod - client side caching daemon
mount must understand the hostname:directory convention. Filesystem entries in /etc/[v]fstab tell the client what filesystems to mount.

Network File Sharing

Network File Sharing The mount command has several extensions for use with NFS. Mount has to understand timeouts, soft mounts, background mounts, and the automounter. rw/ro - Read/write and read only. NFS file systems that are mounted read/write can block activity on the client when the server providing the file system becomes unavailable. See intr and bg below. hard/soft - The hard option mounts an NFS file system in such a way as to ensure that data is written to the remote file system. If the file server becomes unavailable, a file system mounted with the hard option will stop all remote file operations until the file server becomes available again. All file systems mounted with the rw option should also use the hard option to ensure the integrity of data written to the file system. The soft option does not provide assurance of data writes to the remote file system, but does not stop remote file operations in the case of a file server becoming unavailable. This option is useful for file systems that are mounted read-only.

Network File Sharing suid/nosuid - The nosuid option negates the effect of programs on the remote file system for which respective setuid bits are set. Setuid programs run from NFS file systems mounted with the nosuid option are executed with the normal permissions of the user executing the program, not those conferred by the setuid bit. This option is used to increase the security of the client by preventing setuid programs on remote file systems from being used on the client system. bg/fg - This option pair controls how to handle a failed mount of an NFS file system. Mounts with the bg option are retried in the background, freeing the shell which issued the mount command. Use this option when mounting file systems in /etc/vfstab or /etc/fstab to prevent a workstation from stopping during the boot sequence because a file server is down. intr/nointr - The nointr option prevents program interrupts when programs cause an NFS operation to occur. This can result in programs being uninterruptible when an NFS file server becomes unavailable. The default is to allow interrupts so that programs can be aborted in the event of server failures.

Network File Sharing retry=n - Number of times to retry a failed mount. The default of 10,000 is usually sufficient. timeo=n - Time-out value for retrying NFS operations. Increase this value to permit very slow systems, such as near-line file stores, more time to complete basic operations. retrans=n - Number of retransmissions of a given NFS operation. The setting depends on the network and type of server being used. Some networks where packet loss is high benefit from an increase in the number of retransmissions. rsize=n - Read buffer size. Some servers and clients (e.g., those with slower or less reliable network connections) perform better when the buffer used for NFS operations is a different size than the default. wsize=n - Write buffer size. Similar to rsize in usage.

Network File Sharing proto=? - Controls the network protocol used to transport NFS data. NFS uses IP datagrams by default. By setting proto=tcp, NFS will use tcp, thereby improving performance when moving data over wide area networks and the Internet. secure - On Solaris 7 and early versionsof NFS this option enables NIS+ public key cryptography to be used for NFS authentication and encrypted communications. This option has been deprecated in favor of the “sec=?” option below. sec=? - New in Solaris 8. This option replaces the “secure” option of previous versions. It controls the security mode used for NFS. Options are “sys” for UID & GID based control, “dh” (Diffie-Hellman) for NIS+ based public key cryptography, “kerb4” for MIT Kerberos authentication and “none” which provides no authentication and maps all accesses to “nobody” as described below.

Network File Sharing quota/noquota - Setting this option enables disk quota checking via the rquota service. The rquotad daemon must be running on the server for this to function. Noquota is the default. remount - This option is often used when mounting a file system manually. It converts a mount point from read-only to read-write status. vers=n - NFS protocol version number (2 or 3). By default, the mount command will attempt to use the highest version number protocol available from the server. This option allows the protocol version to be fixed for use with servers that support only the older version 2 protocol.

Network File Sharing Monitoring NFS
NFS is NOT secure. Keep /etc/dfs, /etc/exports locked up (root readable), Use Fully Qualified Domain Names for hosts (FQDN). Make sure you implement any security patches for NFS. Make sure you get rid of “+” in any automount map files! Monitoring NFS The nfsstat command can be used to look at the NFS performance statistics. The -s flag looks at server statistics, and the -c flag looks at client side statistics.

Network File Sharing Windows uses a different approach to file sharing. Server Message Block (SMB) is a proprietary protocol that was developed to support Windows networking. Port 135 Port 136 Port 137 – the NetBios Name Service Port 138 Port 139 – The NetBios Session Service Now that Microsoft has embraced TCP/IP networking, Windows is converting to a new protocol: Common Internet File System (CIFS).

Network File Sharing Permissions
Under NFS, and AFS, the user (or administrator) can assign access permissions to directories, and to the files within those directories. Under Windows, the permissions cover the directory. Files within a directory inherit the permissions of the directory. Shared folder permissions only apply to the folder when it is accessed via the network. The local permissions pertain when accessing files locally on the server. The default permission under Windows is “Everyone: Full Control” ! This means that everyone has access to all files in the shared folder.

Network File Sharing Group Permissions Domain Workgroup
Administrator and Server Operator groups can share folders on any host in the domain. Power Users can share folders on a single host. Workgroup Administrators and Power Users can share folders. Users with the Create Permanent Shared Objects permission can create shares.

Network File Sharing Some folders are shared automatically:
The share name has a “$” appended to the end. These shares are “hidden” shares. Automatically shared folders include: The root of each volume (C$ D$ E$ …) The system root folder (Admin$) The location of the printer drivers (Print$)

Network File Sharing Sharing setup Right click the folder
Select Sharing Fill in the forms Network File Sharing is much easier to set up than NFS/AFS. Network File Sharing is much less secure than NFS/AFS.

Network File Sharing SAMBA is an SMB/CIFS file sharing daemon that runs on UNIX hosts. Clients make SMB requests on the network Samba accepts SMB file requests from clients and uses UNIX calls to obtain requested file from disks. Samba returns SMB file information to the client. SAMBA is free. TotalNet is another solution which performs the same function. TotalNet is a commercial product. “Dave” performs the same function for MacOS. (Free) Xinet is a commercial product that performs the same function.

Network File Sharing A common goal for an organization is to provide one file farm which is accessible from all platforms. At Notre Dame we use AFS – it is native to the UNIX environment, but it works for Windows/MacOS. The MacOS and Windows AFS access may be via an AFS to NFS translator box. The client machines run NFS. The clients make NFS requests to a translator. The translator makes AFS requests to the fileserver. NT is supported as a native AFS client. NT does not require AFS translators. NT port uses a memory based filesystem cache NT port is not very robust. OpenAFS is much better than TransArc’s NT client.

Network File Sharing Athena File System (AFS)
AFS came from the CMU Athena File System. AFS is now distributed as a commercial product by TransARC Corporation (part of IBM). OpenAFS is an open source version of AFS built from TransARC source code. ARLA is another open source AFS built from independent code. AFS appears most often at Universities. AFS was supposed to be a precursor to DFS (Distributed File System). AFS and NFS do the same things, so why chose one over the other?

Network File Sharing AFS NFS Add-in product Distributed with OS
client side caching is standard authenticated challenge on net scales well Uses Access Control Lists (ACL’s) More secure than NFS Less reliable than NFS (?) NFS Distributed with OS client side cache is optional clear-text passwords on net Does not scale well Uses standard UNIX permissions Not secure More reliable than AFS (?)

Network File Sharing NFS AFS Low administrative overhead
Standard UNIX backup /restore Available for most OS Distributed administration Uses standard utilities AFS High administrative overhead “Enhanced” backup /restore Limited OS availability Central administration replaces standard utilities

Network File Sharing AFS
AFS replaces many system library calls with custom versions: passwords - are stored in a common (AFS) file. ftp, telnet, rlogin, rsh have to be modified to use the new password utility. (NO LONGER TRUE as of Solaris 2.6 when using PAM) root’s password is held locally in the normal location, so root is not an authenticated AFS user. The filesystem code is altered such that the local cache disk is checked for files before going to the network.

AFS improves system security due to the way it authenticates the users: The UID of the user is ignored by the filesystem. The filesystem relies on an authentication token instead. NFS uses the user id to authenticate file access. The UID can be changed by a crafty user. On standard UFS filesystems, root can read/write every file. NFS can also allow root read/write. Under AFS, root does not have the ability to go read other users (AFS based) files.

Network File Sharing AFS cache files (/usr/vice/cache)
When you install AFS, the installation procedure creates some new directories: /usr/afsws - contains the binaries for the AFS suite: fs, tokens, pts /usr/vice - contains the AFS administrative files: cache files (/usr/vice/cache) administrative information about this AFS client (/usr/vice/etc). The package software is also installed. Package is a utility for updating system files upon reboot.

Once all of the binaries are in place, the afs software creates a cache directory and initializes a series of files in this directory. When the cache scan is complete, the system reboots so that AFS will start up on the system. At reboot, the package utility looks for a configuration file which tells which files to sync to the master repository. This architecture dependent file tells package which files need to be updated, what modes to make things, which entries are regular files, which entries should force a reboot if they get updated, etc.

Once the package command has updated all of the files it looks to see if any of the updated files had the “reboot” flag set. If so, the system reboots again. This time, the system files should all be up to date. Departments can even use their own package run (controlled by /.package_dept) which updates specific files (sendmail, password files, message of the day, hosts files, Mentor Graphics links). If any of these files have the “reboot” flag set, the system reboots again.

Summary Network File Sharing relies on Remote Procedure Calls.
Network File Sharing is convenient for users. Network File sharing requires setup by the sysadmin. Network file sharing opens the door to many security problems.

Automating File Sharing
Chapter 19

Chapter Goals Understand how to automount file systems under Windows.
Understand how to create a consistent name space. Understand NFS automounter setup. Understand automounter map files.

Windows has nothing really comparable to automount that will automatically mount remote disks on demand. However, Windows shares can be configured to automatically mount when a user logs in. The configuration begins by right clicking on the “Network Neighborhood” or “Network Places” icon and selecting “Map Network Drive” from the pop-up menu. Selecting “Map Network Drive” will bring up a dialog box, where a drive letter is selected and assigned to a share.

This dialog includes three items to pay careful attention to. The “Browse…” button. This allows a user to browse using an interface similar to the “Network Neighborhood” to locate the server and share. This is often easier than entering the share name directly into the “Folder” field. The “Reconnect” checkbox. This is how the automatic mount of the sharing is set. Checking this box results in the drive mapping being saved and automatically performed next time the user logs in. The “different user name” link. This link allows the user to enter an username and password different from the username and password used when they logged into the Windows system as shown in Figure 19-?. This is important for sites that use different authentication methods for Windows and UNIX and still wish to offer Samba shares to Windows users. Note that on login, a share that has a different user name and password will cause the automatic remounting process to prompt the user for the differing password at the point the mount is reconnected.

While this automatic mounting of shares is handy it does not address the basic problem of file sharing, server unavailability. If the server the share is being mounted from fails, the network drive connection will be lost and must be manually remounted. If the server is unavailable when the user logs in, the network drive will not be mounted even if the server later becomes available. If a server fails, but another server offers the same services, manual intervention will be required to mount the backup server. The UNIX automount service offers ways around these problems.

As mentioned in Chapter 18, “Network File Sharing,” growing networks present the system manager with many challenges. As new machines are added, correctly maintaining the configuration files to export and mount the newly added file systems becomes an increasingly daunting chore. In addition, when a file server becomes unavailable, processes on client workstations may stop even if they do not depend on that file server. The automount service was developed to minimize these problems on UNIX systems.

The default mappings used by the automounter are often difficult for users to handle: /tmp_mnt/servername/filesystem_name/user_dir /net/servername/filesystem_name/user_dir /home/servername/filesystem_name/user_dir The system administrator needs to force the automounter to provide a consistent name space for the user’s directories.

What you want the system to do is map a file system from the server to an alternate mount point on the client

The automounter allows filesystems to be mounted on demand. The administrator sets up some control files, and makes some mount point directories. If/when a user references an a filesystem that is set up for the automounter, the NFS software looks it up in the files, and mounts the filesystem. The control files are called “map files”. There are several types of map files. The most common map files are:

Master Maps - list all direct and indirect map files to be processed. # Master map for automount daemon /- auto_direct -ro /remote auto_indirect /home auto_home

direct maps – lists of filesystems that do not share a common mount point. /usr/man /opt /cs/tools # mount /usr/man from grissom /usr/man -ro grissom:/usr/man # mount framemaker binaries from grissom or chaffee /usr/frame -ro grissom:/usr/frame \ chaffee:/usr/frame2.0

indirect maps In an indirect map, the NFS file systems referred to by the map are mounted at a different mount point than the one listed in the table and a symbolic link is made from that location to the directory listed in the master map. This allows for some more exotic automount tricks. # Item in RHS is mounted in location of LHS # mount /src from snow /usr/local/src src snowwhite:/usr/local/src bin snowwhite:/usr/local/bin gnu snowwhite:/usr/local/gnu

auto_home One of the most common indirect maps is auto_home. The auto_home map has keys in the /home directory. It is used to collect users’ home directories into a single location, and greatly eases the task of maintaining home directory location information. dwight glenn:/export/home/& frank chaffee:/user2/& tom grissom:/export/users/& steve glenn:/export/home/& Note how the line starting with the key frank does not contain a full path. The key in an indirect map specifies the name of the symbolic link to be made in the directory specified in the entry for the map in the auto_master file. In this case, all the keys in the auto_home map will create symbolic links in the /home directory.

Automounter Variables Variable - Meaning - Example ARCH - CPU architecture type - sun4 CPU - CPU type - SPARC HOST - Host name - glenn OSNAME - Operating system name - SunOS OSREL - Operating system release number - 5.6 OSVERS - Operating system version - FCS1.0

Once all of the maps are set up, and the mount points have been created, you start the Solaris automount daemon with: /etc/init.d/nfs.client start /etc/init.d/autofs start Automount can also be configured to mount the filesystem from the server that responds first! (Fault Tolerance)

AMD automounter is a more robust system, but takes more work to set up initially (because it is an add-in product). The amd automounter, found on Linux and many BSD style UNIX variants uses a different and incompatible format for its map files. The general concepts are the same, keyed entries that specify remote filesystems to be mounted, however the syntax is richer and offers greater control over how the map behaves in differing circumstances. The analog to the auto_master file for the amd automounter is the amd.conf file found in /etc. Beyond specifying the other maps to be consulted, amd.conf also includes a general stanza that allows the many option settings of amd to be configured.

# # amd default config file # GLOBAL OPTIONS SECTION [ global ] normalize_hostnames = no print_pid = yes pid_file = /var/run/amd.pid restart_mounts = yes auto_dir = /.automount #log_file = /var/log/amd log_file = syslog log_options = all #debug_options = all plock = no selectors_on_default = yes print_version = no

# set map_type to "nis" for NIS maps, or comment it out to search for all
# types map_type = file search_path = /etc browsable_dirs = yes show_statfs_entries = no fully_qualified_hosts = no cache_duration = 3600 local_domain = bio.purdue.edu # Bio map [ /bio ] map_name = /etc/bio.amd # PUCC map [ /pucc ] map_name = /etc/pucc.amd # CS map [ /cs ] map_name = /etc/cs.amd

As stated in the comment at the top of the amd.conf file, the many options listed are described in the manual page. Note that the option keys and their assocated values are case sensitive. Here are a few of the key options that may need to be changed to adapt the default amd behavior for a particular site. normalize_hostnames: Setting this option to yes will cause amd to re-write any hostnames into their fully qualified form before using them as parameters in map files. This is not always desirable as it makes for long entries in map files for local hosts. log_file: This specifies the location of the log file amd writes messages to. Or, as shown here, the log_file option can be set to “syslog” to have amd log via the syslog service.

map_type: This option takes several values allowing for a wide variety of sourcs for map information. Here the “file” option is used. Other choices include hesiod, ldap, ndbm, nis, nisplus, passwd and union. The passwd option allows for the direct creation of an auto_home style user home directory map from the the password file. browsable_dirs: By setting this to yes, the keys in a given map are made available for viewing by commands such as “ls”. This prevents amd from mounting all the referenced file systems for simple directory lookups; a big performance savings. Note that commands that stat each directory entry such as “ls –l” will still cause amd to mount the referenced file systems. cache_duration: This specifies the time an unused file system will remain mounted.

An amd map file uses a syntax that involves a key and series of values format. The key is the entry that will appear in the amd “file system”. The series of values describes the file system(s) or other items referenced by the key and their options. The series of values can contain conditional statements as well as file system references.

# global default /defaults type:=nfs;opts:=rw,intr,hard,nosuid,grpid,quota,vers=2,proto=udp # replicated local program servers MISC rhost:=mutant;rfs:=/usr/mutant3/local \ rhost:=turtle;rfs:=/usr/turtle2/local # UNIX filesystems alaska host!=alaska;rhost:=alaska;rfs:=/home \ host==alaska;type:=link;fs:=/home alu host!=alu;rhost:=alu;rfs:=/usr/alu \ host==alu;type:=link;fs:=/usr/alu

Summary Windows allows automatic file system mounting.
Windows automounters are fairly simple. Unix automounters allow for redundancy and failover. One good use for the automounter is to provide a consistent name space for the users file systems. Map files are used to configure the Unix automounter.

Name Services Chapter 20

Chapter Goals Understand Local vs. global name services.
Understand basic use of NIS. Understand how DNS works. Understand DNS configuration files. Understand how to make multiple name services work together.

Network Configuration
Review In order to install a network connection on a UNIX box, you have to do the following: Set up the nameservice files: /etc/nsswitch.conf set the hosts entry to use the appropriate name service (this step to be discussed later) If you are using NIS, you have to set up files in /var/yp. /etc/resolv.conf nameserver domain cselab.nd.edu search cselab.nd.edu cse.nd.edu helios.nd.edu cc.nd.edu nd.edu

Name Service There are several name services available.
For UNIX, the most common are: Network Information Services (NIS)(NIS+) /etc/hosts file (static mappings) Network Information Service (Federated Name Services - FNS) Domain Name Service For WINDOWS, the most common are: lmhosts file Wins DNS

Name Services The Network Information Service (NIS) (and it’s successor NIS+) are local information servers. NIS/NIS+ provides hostname to IP address lookups, password lookups, and other local information lookups. NIS/NIS+ are not global services. It does not make sense to make some of the NIS services global (passwords, aliases, ...). Must run DNS for Internet name lookups.

Name Services NIS/NIS+ Strong Points:
Centralized Administration (all local information in one database). Several versions of Unix include NIS/NIS+ Integral part of Solaris. Easy to understand file formats Configurable NIS Shortcomings: The database does not scale well. NIS requires/facilitates centralized administration. NIS/NIS+ are not available on all platforms. NIS/NIS+ open the site up to security problems.

Name Services NIS allows the site to split the namespace into organizational unit service “domains” NIS allows for multiple servers Master server – authoratative for a domain Slave server – a backup server for a domain Each sub-domain may have master and slave servers which are authoritative for their own sub-domains.

Can have one master NIS, or multiple NIS masters.
Discuss the good/bad points of each.

NIS Summary NIS is a LOCAL name service.
You must still run DNS to be on the Internet! Alternate: You can have your ISP run DNS for you. NIS is not secure (No Information Security)

Name Services At the top of the hierarchy is the root domain.
DNS is a distributed database which holds information about hosts IP addresses, mail routing information, and hostnames. DNS is typically implemented via the Berkeley Internet Name Domain system (bind). Other name service packages are available: Cisco Network Registrar is one example. DNS uses a hierarchical tree of name servers to minimize impact on any one nameserver. At the top of the hierarchy is the root domain. The root domain has no name server.

Name Services DNS specifications set aside certain top-level domain names. These domains reside under the root domain. Each of these top level domains has one (or more) master name servers. Unfortunately, these are referred to as the root name servers. These top-level domains are different in the US than in other countries.

Name Services .com - commercial companies
In the US, the top level domains are: .com - commercial companies .edu - educational institutions .gov - government agencies .mil - military agencies .net - network providers .org - non-profit organizations .int - international organizations .arpa - a dead elephant (historical) Each of these domains has (at least) one authoritative name server.

Name Services In other countries, the ISO country codes are used as top level domain names: au - Australia ca - Canada dk - Denmark fi - Finland fr - France jp - Japan se - Sweden hk - Hong Kong ch - Switzerland

Name Services Within each top-level domain there are several second level domains. Each second level domain can have an authoritative name server. nd.edu is a second level domain. bind.cc.nd.edu is the name server for the nd.edu domain.

Name Services Under each second level domain you might find many subdomains. cse.nd.edu, math.nd.edu, lsc.nd.edu and cselab.nd.edu are all subdomains of nd.edu. These domains may or may not have their own nameservers. If not, they rely upon the second level server for address resolution. If so, they generally rely upon the higher level name servers for information on hosts outside of the subdomain. music.cselab.nd.edu ( ) is our lab nameserver. The cselab domain is a 3rd level domain. Music refers requests to bind.nd.edu for hosts outside of the lab domain.

Name Services There are three components to the name service system:
A daemon (named) that answers queries Library routines that programs call in order to contact the server when they need to resolve hostnames/addresses. Command line interfaces to the DNS database (nslookup, dig, host) Named is the process that answers queries about hostnames and IP addresses. If named knows the answer, it replies. If not, it queries a nameserver at a higher level to get the information required named is also responsible for transferring the database from high level servers to the lower level servers (zone transfers).

Name Services Named operates in one of three modes:
master - one per domain - keeps the master copy of the DNS database for this domain. slave - copies it’s data from the primary server via a zone transfer. Multiple secondary servers allowed within a domain. caching - loads a few important addresses into it’s database, and gathers information on other hosts through normal operation.

Name Services Nameservers come in two flavors: recursive nameservers - stick with a query until they get a resolution for the client machine. The cache management becomes very resource intensive. non-recursive - are lazy. If they don’t know the answer, they return a “go ask him” response to the client. Their cache of information is not very resource intensive. Low level servers are usually recursive, while higher level servers are usually non-recursive.

Name Services START A user on a system called darwin.cc.nd.edu wants to finger a user on a system called foyt.central.sun.com Darwin looks in the /etc/hosts file to see if it knows who foyt.central.sun.com is and how to get there. If we find an entry in the hosts file, skip to host-resolved. If darwin does not find foyt.central.sun.com in it’s hosts file, it checks /etc/resolv.conf, finds the name of it’s nameserver. Darwin creates a DNS query packet, and sends it to the nameserver. The nameserver receives the DNS query packet and examines it: “Hi, I’m darwin, I live at , my MAC address is 08:00:20:00:4e:3f. Who is foyt.central.sun.com and how do I get there?”

Name Services The nameserver (bind.cc.nd.edu) looks in its database to see if it knows who foyt.central.sun.com is and how to get there. If the nameserver has an entry for the foyt.central.sun.com machine skip to DNS-resolved. If the nameserver does not have an address for the foyt machine, it sends out an DNS request to it’s master nameserver (.edu) saying “Hi, I’m bind.cc.nd.edu, I live at , my MAC address is 08:00:20:ff:ee:dd. Who is foyt.central.sun.com and how do I get there?” This starts an iterative process of nameservice lookups...

Name Services The master .edu nameserver is lazy (non-recursive). It tells bind to go ask the nameserver for .com. The reply packet tells bind the address of a .com name server. The master .com nameserver is lazy (non-recursive). It tells bind to go ask the nameserver at Sun.com. The reply packet dives bind the address of the Sun.com name server. Bind queries the Sun.com nameserver. If Sun.com is recursive, it will go ask Central.sun.com. If Sun.com is non-recursive, it will tell bind to ask central.sun.com. If no nameserver knows who foyt.central.sun.com is, then the user gets the always helpful “host unknown” message on their console. Skip to DONE.

Name Services If a nameserver finds the foyt.central.sun.com machine in it’s database, then it will reply back through the chain that “foyt.central.sun.com is at ”. Some of the name server(s) which are contacted add bind.cc.nd.edu, and foyt.central.sun.com to their named cache.

Name Services DNS-resolved
Bind.cc.nd.edu adds foyt to it’s named cache, and forwards the information about foyt.central.sun.com (from the master nameserver) on to darwin. Darwin receives the address information from bind, and thanks bind. Darwin adds the bind.cc.nd.edu information to it’s named cache. GO TO ARP

Name Services host-resolved
Darwin looks to see if it has the hardware address of foyt. If not, GO TO ARP ARP Darwin sends a hardware broadcast packet that says: Hi, I’m Darwin, my IP address is , my MAC address is 08:00:20:00:4e:3f. Who is Foyt, and what is his MAC address? If Foyt is on the same network, it replies with it’s MAC address. Otherwise the router replies with it’s MAC address.

Name Services Darwin sends an IP packet to foyt.central.sun.com at IP address saying “Hi, I’m darwin.cc.nd.edu, I live at and my MAC address is 08:00:20:00:4e:3f. I’d like to contact your finger server (port 79) with the information contained in the data segment of this packet” Foyt.central.sun.com receives the packet, decodes the protocol information and determines that it is for the /usr/etc/in.fingerd program. Foyt forwards the packet to it’s finger daemon on port 79. Foyt adds the darwin machine to it’s named cache.

Name Services The finger server on foyt looks up the information requested by the user on Darwin, and sends a packet out on the net saying “Hi there darwin.cc.nd.edu, I am foyt.central.sun.com. I live at , my MAC address is 11:22:33:44:55:66, here is the information you requested. Darwin receives the information from foyt, thanks the foyt machine, and sends the data to the user’s terminal. Darwin adds the Foyt machine to it’s named cache. DONE The user finds out their friend wasn’t logged in, goes home and drinks beer (or whatever users do when not logged in to a system).

Name Services Now it is time to look at the contents of the DNS database(s), and see what information is there, what it does, and how it is used. Client-side database files The /etc/resolv.conf file is the simplest DNS database file. This file contains the IP address(es) of the nameserver(s), a search list, and the domain information for this host. All hosts in the domain need a copy of the /etc/resolv.conf file so their name/address resolver knows where to go for information.

Name Service # cat /etc/resolv.conf domain cse.nd.edu ; search cse and nd search cse.nd.edu. nd.edu. nameserver nameserver nameserver

Name Services While the resolver only requires one file, the name server (named) requires several configuration files. named.conf - Sets general named parameters and points to locations (disk files or other servers) which we obtain our information from. root.hint - Points to the root domain servers. localhost.zone - Used to resolve the loopback addresses. d.zonename - The zone file that maps names to IP addresses. d.reverse-ip - the zone file for reverse domain lookups (IP address to hostname). We’ll start by looking at some of the keywords allowed in the named.conf file.

Name Services named.conf - allows several keywords: directory - Directory for all subsequent file references. primary - Declares this server as primary for this zone. secondary - Declares this server as secondary in zone. cache - Points to the cache file. forwarders - Lists servers to which we send requests. slave - Forces the server to forward all requests. ; - Comment (note, that # works, but is not correct!) (data) - Allow data to span lines @ - The current domain name * - Wildcard (name field only) - dangerous!

Name Services # cat /etc/named.conf options {
version "Surely you must be joking!"; listen-on { ; }; directory "."; statistics-file "named.stats"; dump-file "named_dump.db"; // _PATH_DUMPFILE pid-file "named.pid"; // _PATH_PIDFILE notify yes; auth-nxdomain yes; interface-interval 60; // scan for new or deleted interfaces allow-transfer { ; ; ; }; forwarders { ; }; };

Name Services type hint; logging {
category default { default_syslog; default_debug; } ; channel goobers { file "/var/log/named.log" versions 5 size 32m; } ; category queries { goobers; }; category lame-servers { null; }; }; zone "." { type hint; file "root.hint";

Name Services zone "cselab.nd.edu" { type master; };
file "d.cselab.nd.edu"; allow-update { none; }; allow-transfer { ; ; ; }; allow-query { /16; }; }; zone " in-addr.arpa" IN { file "d in-addr.arpa";

Name Services zone "nd.edu" { type slave; };
file "nd.edu.zone"; masters { ; ; }; forwarders { ; ; }; allow-query { /16; }; }; zone " in-addr.arpa" IN { file "d in-addr.arpa"; forwarders { ; };

Name Services zone "localhost" IN { type master; };
file "localhost.zone"; allow-update { none; }; }; zone " in-addr.arpa" IN { file " zone";

Name Services The named.conf file defines the zones and files to use.
The files referenced in the named.conf file contain resource records that govern the information provided by the name service.

Name Services The format of a DNS resource record is: [name] [ttl] [class] type data name - is the name of the domain object this record refers to. This can be a hostname, or an entire domain. Name is relative to the current domain unless it ends in a “.” (dot). If the name is blank, this record applies to the domain object from the last name command. ttl - Time-to-live defines the length of time (in seconds) that the resource record should be kept in cache. Usually blank so the default (in an SOA record) is used. class - defines this to be an Internet DNS record. Other record types are possible but not used by DNS.

Name Services type - identifies what type of record this is:
SOA - Start Of Authority - Marks the beginning of a zone’s data and defines global (zone) parameters. NS - Name Server - Identifies a domain’s name server. A - Address - Converts a hostname to an IP address. PTR - Pointer - Converts an IP address to a hostname. MX - Mail eXchange - Identifies where to deliver mail for a given domain name. CNAME - Canonical Name - Defines an alias host name. HINFO - Host Information - Describes host hardware/OS. WKS - Well Known Services - advertises network services. RP - Responsible Person - who is in charge of this server. data - the data specific to this record (IP address for a host).

Name Services The database files are
root.hint – used to locate the root name servers. d.zonename – used to define the forward lookup records for the zone. d-reverse-ip – used to define the reverse lookup records for the zone.

; Root.hint Data file for initial cache data for root domain servers.
D IN NS G.ROOT-SERVERS.NET. D IN NS J.ROOT-SERVERS.NET. D IN NS K.ROOT-SERVERS.NET. D IN NS L.ROOT-SERVERS.NET. D IN NS M.ROOT-SERVERS.NET. D IN NS A.ROOT-SERVERS.NET. D IN NS H.ROOT-SERVERS.NET. D IN NS B.ROOT-SERVERS.NET. D IN NS C.ROOT-SERVERS.NET. D IN NS D.ROOT-SERVERS.NET. D IN NS E.ROOT-SERVERS.NET. D IN NS I.ROOT-SERVERS.NET. D IN NS F.ROOT-SERVERS.NET. G.ROOT-SERVERS.NET w6d16h IN A J.ROOT-SERVERS.NET w6d16h IN A K.ROOT-SERVERS.NET w6d16h IN A L.ROOT-SERVERS.NET w6d16h IN A M.ROOT-SERVERS.NET w6d16h IN A A.ROOT-SERVERS.NET w6d16h IN A H.ROOT-SERVERS.NET w6d16h IN A B.ROOT-SERVERS.NET w6d16h IN A C.ROOT-SERVERS.NET w6d16h IN A D.ROOT-SERVERS.NET w6d16h IN A E.ROOT-SERVERS.NET w6d16h IN A I.ROOT-SERVERS.NET w6d16h IN A F.ROOT-SERVERS.NET w6d16h IN A

Name Services Localhost zone files # cat localhost.zone
; Forward lookup for zone $ORIGIN localhost. @ D IN SOA @ root ( ; serial (d. adams) 3H ; refresh 15M ; retry 1W ; expiry 1D ) ; minimum 1D IN NS @ 1D IN A

Name Services Localhost zone files # cat 127.0.0.zone
; Reverse information file for zone $ORIGIN in-addr.arpa. @ D IN SOA localhost. root.localhost. ( ; serial (d. adams) 3H ; refresh 15M ; retry 1W ; expiry 1D ) ; minimum 1D IN NS localhost. D IN PTR localhost.

# more d.cselab.nd.edu $ORIGIN nd.edu. ; Lab Start of Authority Record cselab IN SOA music.cselab.nd.edu. root.music.cselab.nd.edu. ( ) IN NS music.cselab.nd.edu. music.cselab IN A ; Now define the lab hosts $ORIGIN cselab.nd.edu. localhost IN A loghost IN A stu-gw IN A IN HINFO "Cisco 4500" "IOS" stu-switch IN A dilbert IN A IN HINFO "Generic PC" "Linux/BSD"

# cat d in-addr.arpa $ORIGIN in-addr.arpa. IN SOA bind.nd.edu. root.music.cselab.nd.edu. ( ) IN NS bind.nd.edu. $ORIGIN in-addr.arpa. IN PTR cselab-gw.cselab.nd.edu. IN PTR noise.cselab.nd.edu. IN PTR acapella.cselab.nd.edu. IN PTR latin.cselab.nd.edu. IN PTR swing.cselab.nd.edu. IN PTR spiritual.cselab.nd.edu. IN PTR march.cselab.nd.edu. IN PTR country.cselab.nd.edu. IN PTR salsa.cselab.nd.edu. IN PTR blues.cselab.nd.edu. IN PTR music.cselab.nd.edu. IN PTR pop.cselab.nd.edu.

Name Services # /path/to/named
Once all of the databases are set up you need to start the named daemon. The startup is usually handled by the /etc/rc* files. To manually start the named process, login as root, and type: # /path/to/named After named is started, it is a good idea to query the DNS database to see how things look. There are two common commands used to query the database: nslookup, and dig.

Name Services Query the database
nslookup is a standard part of BIND. It allows you to query the BIND database files to determine information about a host. nslookup allows interactive, or command line queries. In the simple form, the syntax is nslookup hostname grumpy% nslookup wizard Server: bind.nd.edu Address: Name: wizard.cse.nd.edu Address:

Name Services

Name Services Querying the DNS database
We have dig online (in the lab), in /usr/site/bin/dig. The user interface for dig is nicer than the nslookup command. dig is generally easier to use than nslookup. Nslookup will go away soon, replaced by dig

Network Configuration
Common problem: You can ping/telnet/... a host by address, but not by hostname. This tells you that some things are right, and something is wrong: Right: The network card is operable, and the wiring is all correct. Wrong: The name service software is not properly configured. By using the IP address of the remote host, you bypass the name service. When you use the hostname of the remote host, the name service software needs to resolve the IP address. This step is failing...

Name Services It is possible, and even common to use multiple name services concurrently. This configuration is controlled via the nsswitch.conf file.

# cat /etc/nsswitch.conf
passwd: files group: files hosts: files dns ipnodes: files networks: files protocols: files rpc: files ethers: files netmasks: files bootparams: files publickey: files netgroup: files automount: files aliases: files services: files sendmailvars: files printers: user files auth_attr: files prof_attr: files project: files

Summary Name Services are an essential component of the network.
Local name services provide the capability of distributing several types of information. Many of these pieces of information should not be distributed globally. Global name services (DNS) are required for sites on the Internet. Management and security of DNS is a time consuming task.

Web Services Chapter 21

Chapter Goals Understand the terminology of the WWW.
Understand web clients (browsers). Understand web servers. Understand client and server security issues. Understand web performance issues.

Web Services What is the World Wide Web (WWW)?
The World Wide Web is a client-server based application originally developed to distribute documentation. Researchers at various locations, notably the National Center for Supercomputer Applications at the University of Illinois, extended the original design to include the distribution of a wide variety of media including graphics, audio, video, small applications or applets.

Web Services WWW clients, known as browsers, make requests from WWW servers and display the results in the form of a page. Pages and other resources are referenced using a universal resource locator (URL). The format of a URL is a resource type tag, followed by the name of the system holding the resource, followed by the path to the resource that may include option flags and other data. Web pages are written in HyperText Markup Language (HTML). A single web page may include text, graphics and other elements from one or more servers. HTML and the format of other page elements are standardized allowing a given web page to be rendered and viewed on a wide variety of web browsers. Web pages can also include forms and buttons. These allow data to be entered into the page via the web browser and communicated back to the web server.

Web Services Web Clients
Administrating WWW clients is primarily a matter of keeping up to date with browser and page content development. At present, leading browsers are undergoing rapid development. New versions of some browsers are available as frequently as every few weeks. New page content in the form of new media data types are continually being developed. Not all media types are directly viewable by a given browser and not all pages follow the HTML specifications closely enough to be properly rendered by all browsers. Additional software may be needed to view certain content types such as video , animated pictures and menus. Such additions to the browser come in two flavors: (1) extensions to the browser program itself, often called plug-ins, or (2) separate applications started under the browser’s control, known as helper applications.

Web Services Plug-ins Plug-ins can be categorized into two major groups based on the application-programming interface (API) they use. One group is designed for Microsoft’s Internet Explorer API, and the other group is based on the Netscape API. Most browsers, such as Mozilla, Opera, Konquerer, use the Netscape API and are able to make use of plug-ins designed for that API. Plug-ins are further categorized by processor architecture and operating system like other application software. As one would expect, the widest selection of plug-ins for various media types is for Internet Explorer on Microsoft Windows on Intel processors. Fewer plug-in choices are available for Mac OS X and Linux and very few plug-ins are available for other UNIX variants.

Web Services Helpers Helper applications are standalone programs that the browser runs to display content in formats not supported by the browser itself or a plug-in. A typical helper is Real’s RealPlayer audio and video player. When a user clicks on a link to a RealPlayer video clip, the browser starts the player and passes along the URL or downloads the video clip and passes the filename of the clip to the player depending on how the clip is specified on the page. The system administrator needs to be aware of the media types his users will need to view. Macromedia’s Flash animation player plug-in and Real’s RealPlayer audio and video player are two typical additions to the base web browser that are widely used to display content found on many web sites. Some sites offer less common media types such as VRML or other 3D images, Window’s media player audio or video, Quicktime video, and others.

Web Services Client Security Issues
Web browsers present several security problems revolving around the issues raised by “active content”. Active content is a program or script that is downloaded as part of a web page and used to provide active features such as animated menus, special page rendering effects, error checking in forms and other features. Most web browsers have the JavaScript scripting language built in. Additionally, most browsers include a Java interpreter either built-in or as a plug-in. Some plug-ins such as the Macromedia Flash player interpret active content and can be considered similar to a scripting language in terms of their programmability. Internet Explorer on Windows systems adds the capability of both Windows scripting and executable applets known as ActiveX.

The range of mischief an executable applet or script could potentially cause is large. Web browsers, Java, JavaScript interpreters and other content viewers are designed with this in mind and combat the problem in varying ways. However, bugs in these tools have appeared over time and continue to appear making the display of active content a risky activity. Fortunately, most browsers allow the user to optionally turn off the execution of Java applets, JavaScript programs and other active content. Turning these off will disable certain interactive features of some web pages. The desirability of turning these features off to gain additional security must be weighed against the requirements of the applications the user has and the web pages they need to view.

Bugs in the browser itself constitute another common problem. Browsers are complex, often including their own Java virtual machine as well as internal versions of ftp and other network tools. System managers at sites concerned about security should continually monitor the browser vendor Web pages for updates that address security problems. WARNING: There are numerous security vulnerabilities associated with downloaded applets and scripts on Microsoft Windows platforms that can affect the security of other systems on a network. These include the unintended installation of malicious software that may examine or disrupt network traffic or adversely effect the operation of servers and other networked systems. Security conscious sites need to consider not only the security of their servers, but also the risks involved in their choice of client platforms and software.

Another client security issue is referring page information. Many web browsers pass along the URL of the page they came from to the web server of the next page they load. This is done to help web sites track how people get to their site. However any information encoded in the URL is passed along as well. Such additional data may include information believed to be secure if the browser moves from a secure page to an unsecured page. Many Web sites avoid this problem by “wiping the browser’s feet” via directing the browser to a blank or unrevealing page after requesting secure information. By default, many browsers will alert users to this problem by posting an alert message when the user moves from a secure page to an unsecured page.

Modern browsers are capable of storing small pieces of information from Web sites such as a password or usage history. These bits of information are known as “cookies.” The security preferences dialog box allows those concerned about cookies to disable them or have the browser announce the delivery of a cookie from the Web site. Turning off cookies will disable password memory and history features of some Web sites. The decision to turn off cookies depends on the user’s concerns about her privacy and the Web pages she views most often.

Web Services Web Servers
Installing and configuring a Web server is a much more involved process than configuring a web browser. A Web server is a very complex daemon with numerous features that are controlled by several configuration files. Web servers not only access files containing web pages, graphics and other media types for distribution to clients, they can also assemble pages from more than one file, run CGI applications, and negotiate secure communications. Security and performance issues are near the top of the list when choosing, installing and configuring any web server.

Web Services Choosing a Web Server
Choosing a web server involves an evaluation of several related factors. Security – Web servers that serve web pages on the Internet face an extremely hostile environment. They are the point of attack for persons interested in entering a system, stealing data or simply defacing web pages. Web servers must properly handle a wide range of input data without fail. Programs run via the web server such via the Common Gateway Interface (CGI) must likewise deal with possibly malicious input data and explicit attempts to exploit them.

Performance – Serving web pages is often a highly I/O intensive task. Many web page are constructed “on the fly” from the output of programs or as the result of a database query. The performance of a web site is dependant on the performance of all the components that feed into the web pages being served. Included in this is the performance of the system the web server resides on, the network it is connected to and the data storage facility being used.

Availability – Some web servers are available for only one operating system platform. Some CGI programs, database interconnections and other data sources are available for only selected platforms. A careful inventory of the desired CGI programs and data sources is helpful in reducing the range of choices to those where the needed software is available. Viewed another way, if a specific platform has already been selected, a review of the web servers, CGI programs, etc. that are available for the selected platform can help guide the development of the web site.

WARNING: Based on a long string of security problems, culminating in the infamous Code Red and Nimda worms, many organizations have moved away from Microsoft’s Internet Information Server (IIS) web server. Moving away from IIS is also the recommendation of the Gartner Group.

Web Services Apache The most widely used web server on the Internet, Apache, is available for all UNIX variants and Windows NT and later. Many UNIX variants such as Red Hat Linux, Mac OS X and Solaris ship Apache as part of the operating system distribution. For those that do not, Apache is freely available in source code form from Aside from its wide acceptance, Apache offers a comprehensive suite of configuration options and features found on many other web servers.

Web Services Server Add-ons
If a web server were all that was needed to set up a web site, life would be pretty easy for the system administrator and web master. However, the typical web server is extendable via several methods. Common Gateway Interface (CGI) – The most common route to extending the functionality of the web server is via CGI. Web pages can refer to CGI programs and data from forms can be passed to them. Web pages can be created on the fly by CGI programs that send data via the web server directly to the client web browser. CGI programs might be Perl scripts, Python scripts, or even compiled binaries.

Web Services Server Add-ons
Application Servers – Tools such as Zope and php provide templates for building web pages. These templates form an entry point into a scripting language and access to databases easing the development of dynamically created web pages. Modules – Analogous to web browser plug-ins, modules extend the web server by directly adding functions. Like web browser plug-ins, modules are specific to a particular web server and match that web server’s API. Status reporting, performance enhancements such as a built-in Perl interpreter, encryption utilities, and even URL spelling correction are some of the modules that are available for the Apache web server.

Web Services Web Server Installation
Apache is available in both binary form from some vendors and in source code form for all systems. While a binary distribution saves time, it does not offer the level of control that building from sources offers. To prepare for an installation from source code, make an inventory of the Apache modules that the web site will require. Also, check that the needed build tools are available.

Web Services Web Server Installation
Apache is built using the “configure and make” procedure common for many open source packages. Like other packages that use the configure utility, typing “configure --help” will produce a list of all of the available option flags. Additional modules not found in the base Apache distribution may require additional work. For example, adding mod_ssl, to provide secure web connections requires that the OpenSSL package be installed first and that an environment variable, SSL_BASE, containing the path to OpenSSL be set when Apache is configured.

Web Services Web Server Configuration
Current versions of the Apache web server are configured via a series of directives kept in a plain text file, httpd.conf. The Apache server distribution includes a set of samples files that the system administrator can modify. Over 100 configuration options can be applied to control the behavior of the Apache Web server. Directives in the configuration files are case insensitive, but arguments to directives are often case sensitive. Long directives can be extended by placing a backslash at the end of the line as a continuation character. Lines beginning with a pound sign (#) are considered comments. A few of the most basic options to be examined upon setting up a new Web server are examined in the next section.

Web Services Basic Apache Directives
At a minimum, the system administrator will want to modify the User, Group, ServerAdmin, ServerRoot, ServerName and DocumentRoot lines to reflect the local site. The User and Group lines specify the user id and group id that the Web server will operate under once started. The ServerAdmin is an address to which the server can send problem reports. The ServerRoot specifies the installation directory for the server. The ServerName is the name of the server returns to clients. The DocumentRoot directive sets the base for the default web page for the web server.

The Alias lines may also require updating to reflect the location of icons and other local files. The Alias lines allow Web page designers to use shortened names for resources such as icons instead of specifying full paths. UserDir WWW Alias /icons/ /usr/local/http/icons/ ScriptAlias /cgi-bin/ /usr/local/http/cgi-bin/ Besides making Web page construction easier by providing short names for icons and CGI programs, these directives allow access to users’ Web pages.

The UserDir line specifies the subdirectory each user can create in his home directory to hold Web pages. This directory, WWW in the example, is mapped to the user’s username as follows. A user whose username is bob has his WWW directory mapped to ~bob. By default, the Apache Web server will display the index.html file in that directory, or a directory listing if the index.html file is not found. This indexing behavior can be controlled by a set of directives, IndexIgnore, IndexOptions, and IndexOrderDefault. IndexOptions in particular has numerous options.

A new installation of Apache may also require changing the <Directory> directives to indicate where the server should look for documents to serve and for CGI programs. For example, if the server is installed in /usr/local/apache with the documents and CGI programs in directories under that directory, the following <Directory > line may be necessary. <Directory /usr/local/apache/htdocs>

Web Services NOTE: The “user” and “group” directives in the httpd.conf file have significant security implications. The “nobody” user is used to severely limit the access privileges the web server has in order to limit what an attacker might be able to access via the web server. These directives also specify the default user under which any CGI program is run. Limiting the privileges that a CGI program has access to is an important step in making the CGI program secure.

Web Services Server Modules
One of the more useful features found in the Apache web server is the use of modules to extend the base server functionality. These modules provide such services as web server status monitoring, encrypted connections, URL rewriting and adding native versions of CGI tools such as Perl. For modules that are built as part of the standard Apache build, activating them is a matter of calling the directive associated with the module. For example, here are the lines required to activate the mod_status module that allows the administrator to query the web server for status information. <Location /server-status> SetHandler server-status Order deny,allow Deny from all Allow from .astro.com </Location>

Web Services Server Modules
The Location directive describes the “page” that is used to view that status information, while SetHandler specifies the server-status entry to the mod_status module. The triple of Order, Deny and Allow directives controls access to this “page” limiting it to only hosts within the specified domain. If the server’s name were the URL used to access this page would be,

Web Services Mod_ssl A more complex module to configure is mod_ssl.
This module provides the encryption used for secure web pages. Before using ssl, a certificate to be used in the authentication of the server will need to be purchased from a certification authority such as Thawte or generated and signed locally. The locally generated certificates, also called self signed certificates, will be flagged by web browsers and require the user to acknowledge them before viewing the web site. The web browser can authenticate certificates purchased from a certificate authority without any user interaction.

Web Services Mod_ssl Next, several directives will need to added to the Apache configuration file to enable ssl and specify the content to be accessed using an encrypted connection. Here is an example that enables ssl using high quality encryption and specifies content to use the encrypted connection. SSLProtocol all SSLCipherSuite HIGH:MEDIUM SSLVerifyClient none SSLCACertificateFile conf/ssl.crt/ca.crt <Location /secure/area> SSLVerifyClient require SSLVerifyDepth 1 </Location>

Web Services Mod_ssl The ssl module has 22 directives and provides fine control over the security of the connection. The effort required to obtain a certificate and configure secure web connections is well worth it. Secure web connections form the basis of many other applications. Two examples are web-based and web based remote system management. The end-to-end encryption supplied by SSL is especially important when remote users are utilizing potentially insecure networks such as wireless networks, or network connections offered at conferences or hotels.

Web Services Mime types
Web servers can serve an almost limitless range of file formats. The mime.types file includes the mapping from a mime type to a file extension. The most common types are provided in the sample file provided with the Apache distribution.

Web Services Web servers present a difficult security challenge.
Server Security Considerations Web servers present a difficult security challenge. They must be widely accessible to be useful, but tightly controlled to prevent security breaches. They must be tolerant of any requests submitted to them, including requests specifically constructed to gain unauthorized access to files or to exploit bugs in modules, application servers, CGI programs or the web server itself.

Web Services Ports 80 and 443 By default a web server listens on port 80 for plaintext requests and port 443 for SSL connections. These are well-known ports and will be examined by attackers. The port a web server listens on can be changed via the server configuration file, however this will cause web browsers to be unable to connect to the server unless the port number is included in the URL specification. For example, if the web server on were set to listen on port 8000, the URL for the server’s default page would be : WARNING: Changing the port a web server listens for requests on does not improve the security of the server. An attacker can locate the web server by scanning all of the ports open on the system.

Web Services File Access Control
The control files which determine the Web server’s function as well as the log files it produces should not be accessible to the user ID the Web server runs under. Individuals attempting to gain unauthorized access are thwarted to the extent that they cannot obtain information about the Web server’s configuration and function. One way to tightly control access is to set the default Apache access rule to deny, and open up only those directories that contain content to be distributed. For example, the httpd.conf directives shown below set the default access to deny and open up access to user web directories and a system default web page area.

Web Services File Access Control # Set default access to deny
<Directory /> Order Deny,Allow Deny from all </Directory> # Allow access to user’s web directories <Directory /usr/users/*/WWW> Allow from all # Allow access to the system web directory <Directory /usr/local/httpd/WWW>

Web Services File Access Control
In addition to the access controls found in the web server configuration files, many web servers provide access control for individual user directories by means of control files found in those directories. Apache uses a file called “.htaccess” which contains directives specifying access. For example, one could restrict access to a particular directory to a specific domain by placing this in the .htaccess file in the directory to be protected. deny from all allow from .bio.purdue.edu In a .htaccess file, the options are assumed to apply to the directory the .htaccess resides in and explicit <Directory> directives like those used in the httpd.conf file are not needed. The access directives can include IP address ranges and references to password databases if desired.

Web Services Server Side Includes
Web server options under which Web pages include other files and execute programs should be carefully scrutinized for potential access to files not intended for distribution. In particular, server side includes (SSI) should be used cautiously. By default, enabling SSI allows users to execute arbitrary programs as part of an include directive. The possible damage this can cause can be limited by using the suexec facility to run the referenced program in a controlled manner with privileges limited to that of the owner of the HTML file. A still more restrictive and secure approach is to allow files to be included, but disallow execution. This is accomplished by using the IncludesNOEXEC directive instead of the Includes directive when specifying the options allowed for a specific directory in httpd.conf.

Web Services Server Side Includes
Below is an example showing how to apply this directive to a specific directory. <Directory /web/docs/ssi> Options IncludesNOEXEC </Directory>

Web Services CGI CGI programs are among the biggest potential dangers to Web server security. These programs are run based on a URL passed to the Web server by a client. In normal operations this URL comes from a form or page. However, the URL provided to a CGI program can be given to the Web server by other means and can be carefully constructed to exercise bugs in the CGI program itself. For example, one of the most common attacks against a web server is via the phf CGI program. The phf program is not included with recent versions of Apache, but was present in earlier versions. Due to poor design, phf could be easily subverted. To disable this CGI program, remove it from the cgi-bin directory specified in the web server configuration file.

Web Services CGI As a general rule, any unused CGI program should be removed from the cgi-bin directory. CGI programs must be carefully constructed to avert potential problems resulting from the input passed to them. One successful method is to use the “tainted” variable facility found in the Perl scripting language. If other languages are used, care must be taken to ensure that all possible input characters are properly handled, including shell metacharacters, quotes, asterisks, and braces. Administrators must also be alert to the well-known problem of very large input strings designed to overwrite small input buffers. Security conscious sites should carefully audit CGI programs before putting them into operation.

Web Services CGI WARNING: The mod_perl module for the Apache web server does not provide any security advantages over a standalone CGI program written in Perl. While it does offer a substantial performance improvement, CGI programs making use of mod_perl need to be as carefully audited as standalone CGI programs. Similarly, the sysadmin should disallow user executable CGI programs. Like the executable server side includes mentioned earlier, user executable CGI opens a Pandora’s box of possible vulnerabilities. Limit CGI programs to a controlled directory and carefully audit any CGI programs for security vulnerabilities. If it is necessary to run a CGI under the UID of a user other than the web server, a wrapper such as suexec or CGIWrap can be used. The wrapper limits the damage an attacker can cause by exploiting a poorly written CGI program. Wrappers are often needed when a CGI program makes use of data that is accessible only to a particular UID.

Web Services CGI Some alternative approaches to standalone CGI programs are application servers such as PHP, and ZOPE. These tools provide a standardized CGI interface designed specifically to avoid problems found in input from web pages. These tools also provide for rapid development of dynamic pages used in a growing number of web applications. PHP is also available as an Apache module giving better performance than that of a standalone CGI program. WARNING: While providing a more standardized way of using CGI, tools like ph and zope are not without problems. Application servers can contain bugs that make vulnerable to attack like any other CGI program or module. For example, all versions of PHP prior to version were found to have a buffer overflow that can be exploited to gain elevated privileges. A privilege elevation problem was also found in ZOPE versions prior to version beta 1

Web Services Unintended Web Servers
The pervasiveness of web browsers has made them a common interface tool for a variety of devices and services beyond the web page. This unfortunately means that there may be unsecured web servers hiding in obscure parts of a network waiting to be exploited. Some of these unintended web servers include the following. Solaris’s AnswerBook2 – AnswerBook2 is web based and it installs and uses a web server (dwhttpd) running on port 8888. Because AnswerBook2 is a web server, it does not need to be installed on every system, a central server can be used. However, it represents another possible avenue of access to a system and should not be enabled unless needed.

The administrator can stop and start the AnswerBook2 web server with the following commands. /usr/lib/ab2/lib/ab2admin –o stop /usr/lib/ab2/lib/ab2admin –o start To disable the AnswerBook2 web server from starting at boot time, the ab2mgr init script needs to be removed from the /etc/rc2.d directory. rm /etc/rc2.d/S96ab2mgr Linuxconf – The popular linux system administration GUI, linuxconf, is available via the web on port 98. It is a well-known port and will be scanned for by attackers. On Red Hat Linux, web access to linuxconf can be disabled using ntsysv, or “chkconfig linuxconf off”.

Web Services Unintended Web Servers Printers – Popular printers from Hewlett-Packard, Epson and others come with a built-in web server that can be used to configure the printer when it is installed. While these web servers often have a password protection scheme in place for their settings, the default passwords are widely known. At a minimum, network accessible printers should have their configuration password changed and any their firmware patched with the current set of patches available from the vendor. Security conscious sites may want to go further and disable remote configuration of network accessible printers as per the printer vendors’ documentation.

Routers, switches and other network devices – Network infrastructure devices often also contain embedded web servers. As with printers, these devices need at a minimum to have their default passwords changed. Security conscious sites should consider disabling remote configuration of these devices as well.

Personal File Sharing – Web servers running on user’s PC’s can pop up on a network like weeds. On Windows 2000 and later editions, the personal file sharing option includes a web server. Unfortunately, this web server is the infamous IIS in disguise and in the default installation, without any of the numerous patches needed to secure it from attack. Controlling this problem is difficult. A combination of actively scanning one’s own network and a firm policy regarding servers run on personal computers is needed to combat the problem. Where possible, these web servers should be shutdown and users directed to use a common web server where security can more readily be maintained.

Web Services Web Servers and Firewalls
A common error in deploying web servers is to place the web server behind the firewall and allow requests to the web server to pass through the firewall. While this seems like a good way to protect the web server it in fact more often leads to the web server becoming a conduit for attackers to pass through the firewall and gain access to the secured network behind it. A better approach is to place the web server outside the firewall. In this configuration, the web server is dedicated to web serving only, all other services except for a secure communications facility such as ssh are removed from the system. Placing the web server outside the firewall acts to prevent a compromise on the web server from proceeding on to the systems protected by the firewall.

Web Services A still better approach for larger networks is to establish a so-called “DeMilitarized Zone” or DMZ area between the firewall protected internal network and the Internet using a second firewall. The advantage of this approach is that the firewall between the Internet and the DMZ offers some protection to the web server while still allowing web requests to pass into and out of the DMZ. The firewall between the DMZ and the internal network then acts to prevent an attack on the web server from proceeding on to systems on the internal network. Either of these approaches protects the web server. However, many web sites build their web pages on the fly from a database. One method of handling this is to periodically push a copy of the database out from a protected system out onto the web server. This isolates the transaction between the web server and the database.

Web Services Log Files Web servers maintain several log files that can aid in monitoring the security of the Web server. access_log - Listing of each individual request fielded by the Web server. agent_log - Listing of every program run by the Web server. This log is optional in the default Apache installation and can be enabled by editting the httpd.conf file. error_log - Listing of the errors the server encountered. Errors from CGI programs as well as the server itself are logged to this file. refer_log - Listing of the previous URL accessed by a given browser. This log is optional in the default Apache installation and can be enabled by editing the httpd.conf file.

Web Services Log Files Of principal interest from a security standpoint are error_log, agent_log, and access_log. These logs should be reviewed periodically for purposes of identifying CGI program problems and attempts to access files not intended for distribution. Another aspect of web server log files is the wealth of information they hold regarding the usage of the web site. Log analysis tools such as http-analyze can provide the web site administrator with a variety of useful statistics on the usage of the web site WARNING: A web server’s log files can provide a wealth of information for an attacker. Be certain that the location of the log files is not accessible by the web server. See the discussion in the section on file access control for a description of how to limit the parts of the file tree the web server is allowed to serve.

Web Services Web Performance Issues
The performance of a web server is a mixture of several factors including the style of data served (dynamic versus static), system resources (CPU, I/O) and the available network bandwidth. Web requests can be viewed as requests for various objects. A typical web page might include some text and one or more graphical images. A web browser will make separate requests, often in parallel, for each element of the page. The web server fills each request as a separate item. Web server load is measured in the size of individual requests and the number of requests it can fill per unit of time. Requests are refered as “hits”.

The Apache web server deals with requests by using a pool of slave processes. The number of processes in the pool is managed dynamically by the parent web process within the bounds set in the httpd.conf file. The parameters that control the pool are shown below. MinSpareServers 5 MaxSpareServers 10 StartServers 5 The MinSpareServers parameter specifies the minimum number of server processes in the pool. The MaxSpareServers specifies the maximum number of server processes in the pool.

StartServers specifies how many servers to start when Apache is started. The values listed for each of these parameters is the default and in general should not be changed. Sites that see very large numbers of hits may consider increasing the number of servers but will need to pay careful attention to system resources, especially memory. Server processing of data before a request is filled by page processing tools such as PHP or by CGI programs adds additional load on the server. Servers with dynamic page content may require additional memory or faster processors to provide reasonable speed in responding to requests. Likewise, the speed of the network connection between the web server and web clients will limit the maximum number of hits per unit time that can be processed.

Web Services Spiders and robots.txt
A performance concern for some sites is the load placed on the web site by web crawling “spiders” or “robots” used by various web monitoring and indexing services. These spiders request page elements in much the same way a web browser would but do so systematically and often at a faster rate. There is an agreed upon standard for web servers to specify what parts of a site, if any, a robot should traverse called the robot exclusion protocol. The protocol makes use of a file called robots.txt and an HTML META tag to control access.

Web Services Web Caches
Another method for improving web performance is the use of an external cache system. Most web browsers have a cache of recently viewed pages, graphics and other other page elements for a period of time defined by the content provider or optionally by the web browser configuration. This allows the browser to rapidly view the page again by loading elements from the local cache instead re-requesting them from a web server. A similar technique can be applied to both the serving of web pages and the local network. Squid, a commonly used web cache program is listed in the reference section of this chapter.

For a local network with a slow connection to the Internet, a proxy web cache can be used to improve performance and conserve bandwidth on the slow speed link. A proxy web cache acts as a local reference for all web requests. The proxy cache holds copies of web page elements for a time period defined by the content provider or by the proxy cache configuration. Web browsers on the local network are configured to use the proxy cache and the proxy cache in turn makes requests for web pages not in its cache or simply replies with the page elements already in the cache.

A Proxy web cache can be either explicitly or implicitly configured for a web client. Most web browsers have an option dialog box that allows a specific proxy to be configured. A web browser so configured will direct all web requests to the proxy. An implicit configuration uses a firewall or router to intercept any web requests leaving a site and redirect them to a proxy. This technique does not require any additional configuration on the client end.

Some web sites use a web cache as the “front end” to their web server. This improves the performance for page serving by allowing the web cache to reply to frequently requested pages from its cache, off loading that work from the web server itself. One situation where this is helpful is a web site with a mixture of static and dynamic web pages. The web cache can take on the load of serving the static pages while requests for dynamic pages are passed on the web server itself.

Web Services Beyond Caching
An extension of the idea of using a web cache as a “front end” to a web server is to use a set of distributed web servers or web caches to provide more web service. There are several approaches to this. Round Robin DNS - This is a special DNS configuration that treats a series of web servers as a single DNS entry. When a request is made for this special entry, the DNS server replies with one of the IP addresses in the series. It replies with the next address in the series for the next request and so on. This spreads the web service load over the machines in the series.

Web Services Beyond Caching
3DNS Appliances - These systems provide an enhanced version of DNS that is tied to database. They can not only spread load between a group of servers as the round robin DNS method does, but also assign requests to servers that are physically close of to the system making the request via data on the topology of the Internet stored in their database. Load Balancing Routers - These systems perform a similar round robin load sharing function but work at the packet level, routing incoming packets destined for a web server to a series of web servers each in turn. Commercial Service Providers - Companies such as Akamai provide globally distributed web caching services aimed at large high volume web sites.

Summary Web servers are becoming a common service that nearly every site will offer in some fashion. Web browsers are relatively non-configurable. Some configuration options allow the user to configure the look and feel of the browser. Other configuration options allow the user to implement rudimentary security, at a loss of convenience. Some web servers are very configurable. Some of the configuration options allow the admin to configure the basic operation of the server. Other configuration options allow the admin to configure basic security of the web server. Web server performance is an elusive goal. Web caches and proxies might be used to improve web server performance.

Electronic Mail Chapter 22

Chapter Goals Understand the basic steps in the mail delivery system.
Understand the role of the Mail User Agent (MUA) Understand the role of the Mail Transport Agent (MTA) Understand the basic strategies for handling . Understand the basic protocols used to deliver and transport mail. Understand the basics of security Understand the basics of sendmail configuration and rulesets. Parsing Anti-spam Anti-relay Authentication

Email Email Overview Email is a “vital” service in users eyes.
Lost mail is not acceptable But it happens daily! is assumed to be confidential It is not confidential! delivery delays are not tolerated is an unreliable service! This leaves system administrators with huge problems. How to ensure reliable service How to secure the MTA/SMTP service How to monitor and manage services How to secure MUA services

Email Typical user complaints/questions:
Overview Typical user complaints/questions: How do I send mail to my friend? I don’t know their address, but I need to send them mail. I sent person X mail, why don’t they respond? Why do I get all of this spam? Why can’t you stop all of this spam? Is OIT reading my mail? Where did my mail go? It was there a minute ago!

Email Mail Overview (at the sending end)
A user creates a mail message using a mail user agent (MUA) (pine, mh, elm, netscape, eudora, mailx). When done “creating”, they exit the MUA. The MUA “contacts” a local mail delivery agent (MDA). The MDA spools the message in the mail spool area and signals a program to process it. The program that processes the message is called a Mail Transport Agent (MTA). The MTA implements the Simple Mail Transfer Protocol (SMTP). The MTA parses the “To:” address, and attempts to contact the remote host’s MTA. If contact succeeds, the local MTA transfers the mail to the remote end. If contact fails, the local MTA retries for some finite period of time.

Email Mail Overview (At the destination end)
The destination MTA “receives” the message as per the SMTP protocol sending end introduces itself sending end tells who mail is from sending end tells who mail is for If destination user is valid, open a spool, and continue collection. More on this in a minute… Sending end transfers data Sending end closes connection

Mail Overview (”deliver it”) The destination MTA checks the “To:” address to see if there is a system wide alias for the user. If alias exists, deliver as per alias. If no alias, check to see if account exists. If no account, reject message. If account exists, check to see if the user has a .forward file. If .forward exists, deliver mail as per .forward If no .forward, deliver to local spool. When recipient invokes their MUA, it checks local spool, and informs user there is a message.

Email Mail Aliases root: curt, mmcnally postmaster: root epadmin: curt
Unix: /etc/mail/aliases – a text file containing a list of recipients, and names of users to deliver mail to. root: curt, mmcnally postmaster: root epadmin: curt cfh: curt erp: curt, mentor: suggest, henry tou: scott:

Mail Strategy To implement the delivery of at a site, the administrator has to make a few decisions about how mail will be handled at the site. There are two primary models in use: the “every host” (mail host) model and the “smart-hub/thin-client” model.

Email Mail Strategy “Every Host” Mail host
In this model, every machine on the network is capable of sending and receiving . Although this requires the least setup, it also causes problems. The administrator should add the mail spool to the backup schedule to ensure that a user’s messages are not lost. The individual machines are all running the SMTP daemon, and could be used as open relays. The fact that does not pass to a single host means that router filters and spam/virus filtering are more difficult to implement. Troubleshooting mail problems is difficult, as every machine is (potentially) configured differently.

Email Mail Strategy “Every Host” Mail host
Every time a new version of the software is released, the administrator has to update every host. The good side of this model is that the configuration is pretty minimal. Clients read mail from their own local disk, and therefore the mail file system does not have to be made available to other hosts. The administrator may have to develop a standard delivery configuration file, and distribute it to all machines.

Email Mail Strategy Smart Hub/Thin Client
This model of management requires a large central server. The central server is the only machine that will accept mail messages for the entire enterprise. This server is configured with plenty of disk space and connectivity to allow it to keep up with the load of all into and out of the enterprise. If the enterprise decides to implement this model, the name service may also require some reconfiguration, to add MX records for all hosts in the enterprise. The MX record would tell other hosts to send their mail messages to the smart hub, instead of to individual hosts within the enterprise.

Mail Strategy This model requires much more configuration at the beginning, but it also brings a certain amount of sanity to the process. For example, the enterprise router filters may be tuned such that they only allow SMTP connections to the mail hub (mail server). All other SMTP connection requests can be denied. Anti spam/virus filtering can be installed on the mail server to ensure that all messages are checked for harmful content. The administrator only has to back up one mail host, instead of backing up the mail spool from every host at the corporation. If an upgraded version of the mail software is released, the operator has to update only one mail server, instead of hundreds.

Mail Strategy Mail client machines can also be greatly simplified using the mail hub model. For example, you might determine that it is not necessary to run the SMTP daemon on client machines. A simple cron job to check the queue periodically and process pending requests by sending them to the mail server for delivery may be all the client support your site requires. For slightly more complicated scenarios, you may still need to build an SMTP daemon configuration file to control this process, and/or find a way to make the mail spool (on the server) available to the MUAs on mail clients.

Mail Strategy But the news is not all good, as this model also has its downside. The mail server is a great repository of mail messages, but it also has to make these messages available to users. Although you could force the user to log in to the mail server to read mail, this is rarely acceptable. Another problem with the mail hub model is user education. Users like to personalize their mail. Many users prefer to think that by having mail delivered to their desktop, it is more secure. Some users want correspondents to think the mail goes directly to their desktop, instead of to a corporate mail server. Quite often, the administrator has to convince the user to advertise the address on the corporate server, rather than the address on the user’s desktop.

Mail Strategy Mail Servers often require substantial hardware to implement this mail management model. A 20,000-employee operation could easily swamp a four-processor mail hub with 300 gigabytes of disk space reserved for the mail spool area. If that single mail server ever experiences a problem that takes it off-line for an extended period of time, the users will be on the warpath!

Protocols The heart of is the collection of protocols used to transport from server to server and make it available to users. This collection of standard protocols allows the wide range of software to interoperate across the Internet. These protocols can be split into three categories: those used by MTAs as mail is moved between servers, those used by MDAs to deliver the mail, and those used by MUAs to allow the user to read, create, and reply to mail.

Protocols MUAs typically allow the user several methods of accessing mail, depending on how and where messages are stored. The three most common access methods are plain files, the Post Office Protocol (POP), and the Internet Mail Access Protocol (IMAP). These protocols, as well as the SMTP protocol used by MTAs and associated service daemons, have their own reserved ports

Email Mail User Agents (MUA’s)
Some MUA’s “read” mail directly from the spool (/var/mail, /var/spool/mail). (mailx) Mail spool must be mounted on machine where user reads mail. Some MUA’s move messages to an Inbox and operate on it there (pine, netscape). Mail spool must be accessible, but not necessarily mounted on machine where user reads mail.

Email Mail User Agents (MUA’s)
Some MUA’s use delivery protocols to get mail to user Post Office Protocol (POP) Network based – cleartext passwords – copies mail to client, can remove from server, or leave copy on server (pointer into spool tells what has been read) Internet Mail Access Protocol (IMAP) Network based – cleartext passwords – uses RPC’s to act on messages. Displays message on client, does not copy to local disk.

Email MUA’s Have their own transport languages. User Pass Get Put
Typical commands: User Pass Get Put Delete Purge Write (Save)

Email Mail transport agents (MTAs)
Mail transport agents (MTAs) are the workhorses of the system. Several MTAs exist for a wide range of platforms. Some common choices are Sendmail, Microsoft’s Exchange Server (exchange), postfix, qmail, and exim, PMDF. This variety of choices means that the administrator needs to make a decision as to which MTA will work the best for the site.

Email Mail transport agents (MTAs)
Many factors influence the MTA selection process, including the following. Security is one of the primary factors in choosing an MTA. Like a web server, a mail server will need to accept input from a wide variety of sources, including malicious sources. A mail server needs to be capable of handling a large volume of data. A mail server should be capable of using encrypted connections. A mail server should be capable of controlling access. Sendmail is the most commonly used MTA. It is shipped as the default MTA on nearly every UNIX variant and is available for Windows.

Sendmail Sendmail, Inc. distributes an open-source version of the sendmail MTA. The sendmail MTA is configurable on two fronts: The Build utilities (shipped with sendmail) allow the administrator to configure the operation of the sendmail binary ( strategy, security). The sendmail.cf file is used to customize the local delivery rules.

Email Sendmail Philosophy Don’t actually deliver email – route it.
Too many local conventions. Too hard to customize sendmail to fit these conventions. Generalized crossbar switch Individual MUA’s don’t need to know where mail goes. All knowledge about mail routing is in SMTP daemon. All routing is consistent. Do some protocol conversion Basic header munging Do whatever is necessary to route message Better to deliver twice, than not at all Implemented via binary (typically /usr/lib/sendmail) Main configuration file: /etc/[mail]/sendmail.cf)

Email SMTP protocol (spoken by MTA’s)
HELO/EHELO – introduce yourself, and your capabilities MAIL FROM – who is this message from? RCPT TO – who is this message to? DATA – what is the body of the message? VRFY – see if this user exists. EXPN – expand this address and tell me who it is HELP – display the sendmail.hf file RSET – reset the connection NOOP – do nothing VERB – verbose mode DSN – delivery status notice AUTH – authenticate this user QUIT – close the connection

Email Under the hood of MTA’s
The SMTP daemon places the “message” in an envelope for delivery. There is a header on the “letter” There is a header on the envelope. The headers contain addresses, and other information about the message. They should be the same, but are not always! Envelope headers are (usually) assigned by system software (SMTP) Message headers can be (and are) easily forged by user.

Email Under the hood of MTA’s
Users typically do not see the envelope. These headers are stripped off by the SMTP daemon. Every message is assigned a unique ID by EACH SMTP daemon that touches it. This allows tracing the message from end to end (if log files are available).

The following are the files typically used to configure and support the Sendmail binary. sendmail.mc: List of macro definitions used to create the sendmail.cf file. sendmail.cf: Master Sendmail configuration file. It contains the rules that parse mail messages, and determine how, and if, a message gets delivered. sendmail.cw: Contains a list of hosts the mail server will accept messages for. sendmail.hf: Contains help information for the SMTP daemon. sendmail.pid: Contains the process ID of the running Sendmail daemon. aliases: Contains aliases (addresses) for users on this mail server. access.db: Contains a database of sites/hosts/users that are, or are not, allowed to access this mail server.

Email Define()dnl Feature()dnl Parts of a sendmail.mc file Definitions
Configured via FEATURE and DEFINE statements in .mc file Define variables Define()dnl Define macros to perform functions Feature()dnl Define classes (sets of names) Rules parse address, and re-write it for transport. Use macros, classes, and variable definitions during re-write. Apply rules to reject spam and other messages. Mailers Define the mailers that are available for mail delivery on this system.

Email Variables That Control Sendmail Configuration
Most of the Build options for Sendmail are implemented as a series of macro definitions, and/or variables the administrator can set. There are tens (if not hundreds) of variables that might be used to customize Sendmail. The following is a partial list of variables that may be set via the sendmail.cf configuration file, or via the siteconfig file. confMAILER_NAME: Sender name used for internally generated messages. confDOMAIN_NAME: Should only be defined if your system cannot determine your local domain name. confCF_VERSION: If defined, this is appended to the configuration version name. confCW_FILE: Name of file containing host names this system accepts mail for. confCT_FILE: Name of file containing the list of trusted users. confCR_FILE: Name of file containing the list of hosts allowed to relay. confTRUSTED_USERS: Names of users to add to the list of trusted users. This list always includes root, uucp, and daemon. confTRUSTED_USER: Trusted user for file ownership and starting the daemon. confSMTP_MAILER: Mailer name used when SMTP connectivity is required.

Email Variables That Control Sendmail Configuration
confSEVEN_BIT_INPUT: Force input to seven bits. confEIGHT_BIT_HANDLING: Enable 8-bit data handling. confMAX_MESSAGE_SIZE: Maximum size of messages accepted (in bytes). confMIME_FORMAT_ERRORS: Send error messages as MIME-encapsulated messages per RFC 1344. confFORWARD_PATH: Colon-separated list of places to search for .forward files. confLOG_LEVEL: Log level. confPRIVACY_FLAGS: Privacy flags. confTIME_ZONE: Zone info. Can be USE_SYSTEM to use the system’s idea, USE_TZ to use the user’s TZ environment variable, or something else to force that value. confUNSAFE_GROUP_WRITES: If set, group-writable, :include: and .forward files are considered “unsafe.” That is, programs and files cannot be directly referenced from such files. World-writable files are always considered unsafe. confDONT_BLAME_SENDMAIL: Override Sendmail’s file safety checks. This will definitely compromise system security and should not be used unless absolutely necessary. confAUTH_MECHANISMS: List of authentication mechanisms for AUTH (separated by spaces). The advertised list of authentication mechanisms will be the intersection of this list and the list of available mechanisms as determined by the CYRUS SASL library.

Email Sendmail.mc file variables
use_cw_file: Reads the /etc/mail/sendmail.cw file to get a list of hosts the server will accept messages for. use_ct_file: Reads the /etc/mail/trusted-users file to get the names of users that will be “trusted.” stickyhost: This feature is sometimes used with LOCAL_RELAY, although it can be used for a different effect with MAIL_HUB. When used with without MAIL_HUB, sent to is marked as “sticky” and is not forwarded to LOCAL_RELAY. With MAIL_HUB, mail addressed to is forwarded to the mail hub, with the envelope address remaining Without stickyhost, the envelope would be changed to in order to protect against mailing loops. always_add_domain: Includes the local host domain even on locally delivered mail. ldap_routing: Implements LDAP-based recipient routing according to the Internet Draft draft-lachman-laser-ldap-mail-routing-01. Nullclient: A special case. Creates a configuration file containing nothing but support for forwarding all mail to a central hub via a local SMTP-based network. promiscuous_relay: By default, the Sendmail configuration files do not permit mail relaying (that is, accepting mail from outside your local host and sending it to a host other than your local hosts).

Email Sendmail.mc file variables
relay_entire_domain: By default, only hosts listed as RELAY in the access db will be allowed to relay. relay_hosts_only: By default, names listed as RELAY in the access db are domain names, not host names. relay_mail_from: Allows relaying if the mail sender is listed as RELAY in the access map. relay_local_from: Allows relaying if the domain portion of the mail sender is a local host. accept_unqualified_senders: Normally, MAIL FROM: commands in the SMTP session will be refused if the connection is a network connection and the sender address does not include a domain name. accept_unresolvable_domains: Normally, MAIL FROM: commands in the SMTP session will be refused if the host part of the argument to MAIL FROM: cannot be located in the host name service (e.g., an A or MX record in DNS). access_db: Turns on the access database feature. blacklist_recipients: Turns on the ability to block incoming mail for certain recipient user names, host names, or addresses. delay_checks: The rule sets check_mail and check_relay will not be called when, respectively, a client connects or issues a MAIL command. dnsbl: Turns on rejection of hosts found in an DNS-based rejection list.

Email Summary of the sendmail configuration file
/etc/sendmail.cf is built from the sendmail.mc file /etc/mail/sendmail.cf - controls nearly everything: sets global variables and options defines macros and classes (sets of names) describes syntax of message headers defines Delivery Agents (mailers) that may be used defines rule sets based on a “production system” programming language Line at a time syntax Read only at startup

Email Creating a sendmail.cf
Used to be a guru function. Hand editing of an existing sendmail.cf file Complicated Easy to mess up Have to understand sendmail language Better to create a sendmail.mc file, let the system build .cf file for you Easier to port changes Less knowledge of language required – just need to understand macros

Rewrite rules read “tokens” and make decisions based on contents of the token stream. The left hand side of rewriting rules contains a pattern. Normal words are simply matched directly. Metasyntax is introduced using a dollar sign. The metasymbols are: $* Match zero or more tokens $+ Match one or more tokens $- Match exactly one token $=x Match any phrase in class x $~x Match any word not in class x

Example: could become 7 tokens: curt @ cse nd edu $ $2 $3 $4 $5 $6 $7 $* $+ $+ $1=curt $2=cse.nd.edu $- @ $+ $1=curt $2=cse.nd.edu $- . $D $1=curt $2=cse $+ . $+ . $=$T $2=nd $3=edu

Email Sendmail Operators
When the left hand side of a rewriting rule matches, the input is deleted and replaced by the right hand side. Tokens are copied directly from the RHS unless they begin with a dollar sign. Metasymbols are: $n Substitute indefinite token n from LHS $[name$] Canonicalize name $(map key $:default $) Generalized keyed mapping function $>n "Call" ruleset n $#mailer Resolve to mailer Specify host $:user Specify user The $n syntax substitutes the corresponding value from a $+, $-, $*, $=, or $~ match on the LHS

Email HSubject: $>CheckSubject D{MPat}Important Message From
D{MMsg}This message may contain the Melissa virus. D{HPat}Homeworkers Needed D{HMsg}Go away spammer SCheckSubject R${MPat} $* $#error $: 553 ${MMsg} RRe: ${MPat} $* $#error $: 553 ${MMsg} R${HPat} $* $#error $: 553 ${HMsg} RRe: ${HPat} $* $#error $: 553 ${HMsg}

Email LOCAL_RULESETS SLocal_check_mail
R$* $:$1 $| $>Local_check_numb $1 R$* $| $#$* $#$2 R$* $| $* $>Local_check_bull $1 # SLocal_check_numb R$* $: $>Parse0 $>3 $1 R$+ $+. > $* $: $(allnumbers $1 $) $#error $: 553 Header Error SLocal_check_bull R$+ $+. > $* $: $(SpamFriend $1 $) $#error $: 550 We no longer accept spam from you # now call Basic_check_mail to continue processing R$* $| $* $>"Basic_check_mail" $1

Email Recent additions Authentication
Reading/understanding rewrite rules requires a lot of practice! Sendmail has a debug mode that allows the administrator to see how the rule set works. User can use mail -v to see what happens to mail they send. Recent additions New rules allow user authentication. Authentication Block relaying as a general rule Enable authentication User authenticates to server. If user is valid, allow relaying. Can also use SSL encryption as part of this process.

Email Recent additions
As of sendmail 8.8 there are also new macro’s and rewrite rules that allow administrators to build in rules to block spam. Spammers use several tricks to get their mail sent with bogus addresses: Connect to someone else’s SMTP service and send a flood of stuff (Relaying). Guerrilla mailers that munge the envelope and headers to hide the real point of origin. Mailers that use bogus domains or user names in the mail from line.

Statistics A small ISP reported that in 80 days they received 257,000 pieces of at their SMTP server. Of that, 2,500 messages were real mail (<1% of total). Another 2,500 messages were automated reports (<1% of total). The rest was SPAM! (>98% of total). Yahoo (purportedly) delivers 1 BILLION pieces of spam per day. This is after their filters remove 4 out of 5 spam messages that they receive at their SMTP servers! If you multiply the number of Internet users in the USA by the average number of spam messages that they receive per day, and use minimum wage as a cost factor, spam costs the US $622 billion a year!

Email Relaying A “hack” typically used to deliver spam
I create message I send message to Your server accepts message and delivers it for me. You take the heat for the spam. If I forge the headers correctly, you cannot trace it to me. Message MIGHT be a mobile user Mail from a staff member on the road Mail from a staff member’s “home” account Need to control relaying Detecting Relaying - is incoming message destined for a user on this host? If so, accept. If not, this is a relay attempt.

Email The anti-spam rules can check:
Valid sender hostname - look up sending host in DNS. If it does not exist, do not accept mail. Access databases - Local and global lists may be checked: RBL - network services which tracks spammers, relay sites, and dialup ISP’s. Works like DNS – look up host at the RBL service, if an answer comes back from RBL server, do not accept this message.

Email The anti-spam rules can check:
access.db - a local database of sites/users you will not accept mail from. Create a text file with a key, and an action: Key is one of: a user name, a domain name, or a Action is one of: OK, REJECT, or RELAY

Email Access Database nd.edu RELAY cselab.nd.edu RELAY
cse.nd.edu RELAY austin.ibm.com RELAY OK REJECT REJECT REJECT bttb.net REJECT free-virtualweb.org REJECT thefreevirtual.org REJECT REJECT

Email anti-spam rules:
Rulesets can return fatal, or transient error messages Fatal error - sender gets a bounce message. transient error - ties up resources, no bounce message. Check Subject line and other headers Useful for virus rejects and anti-spam.

When building the sendmail binary, there are several options that need to be considered: By default, sendmail will use the OS’s simple database facilities. Often, this is not a good choice. You may need to install a more robust database package for use with sendmail. You may need to compile name service or directory service (LDAP, NIS, …) information into your sendmail. Generally want to put localisms in the devtools/Site directory in a file called siteconfig.m4 Use the Build utilities to include the localisms into the sendmail binary.

Mail Logfiles An important part of the system is the ability to prove where the mail came from, and how it was handled in transit. Mail logging is configured in the sendmail.cf file, and via the syslog facility. Mail log files are very useful in case you need to trace the operation of the mail system. You can chain together the unique message ID’s and prove origination/routing of a message. Should be kept locked up (otherwise users can see who others are mailing). Recent versions of sendmail have improved the sender authentication.

Security Sendmail has been blamed for a lot of security problems. New sendmail (8.9 and later) has a lot better security (and includes a way to override security by setting the “DontBlameSendmail” variable). One well-known security “hole” is the “telnet host 25” trick. Can send bogus mail and make it show up as though someone else sent it. in.identd process can catch this in progress, and provide sendmail with information about the real sender. Mail User agents might not show this information to the user by default.

Email Mail Security Overview
The administrator should take every opportunity to try to convince users to employ secure protocols for mail delivery. POP/IMAP connection sends their log-in and password across the network in plain-text form. To secure such connections, the administrator should install an SSL-encrypted POP and IMAP service, and teach users how to access this service. Once users have been given time to convert to secure services, plain-text services should be disabled.

Email Mail Security Overview Securing Mail User Agents
Mail user agents typically do not provide much to ensure the security of the mail system. By default, MUAs do everything in plain-text mode allowing prying eyes to snoop the network and to read messages. This implies that the user should use some form of encryption tool if she wants to ensure the privacy of messages. Many MUAs contain options that allow the user to make use of encrypted mail delivery services.

Email Mail Security Overview Securing Mail Servers
Hosts that run an MTA daemon may be susceptible to another security problem. An improperly configured mail server will allow anyone to connect to it, and send mail using the mail server as the “From:” address. Such servers are referred to as open (mail) relays. People that generate and send spam mail messages often make use of open relays. The spammer finds a host that allows open relaying, creates the message to be sent, and uses the third-party mail server to send the message. When people that received the spam start complaining, they send mail to the owner of the improperly configured mail server. The owner of the mail server did not create the spam message, nor can he track where it came from, but he will certainly get a lot of fan mail from people that received the spam message!

Email Mail Security Overview
Open relaying has been disabled in recent versions of the Sendmail MTA software, but the administrator has the ability to reenable this mode of operation. Reenabling open relaying is strongly discouraged! Instead, look into building a version of Sendmail that authenticates users, and allows authorized users to relay mail via the mail server. This combats the spam problem in two ways. First, the authentication step logs the name of the user that authenticated. This allows the administrator to track who generated any spam mail that does get relayed through the site. The authentication step also combats spam by requiring the user to authenticate in order to use the MTA to relay messages. This prevents users that do not have a valid log-in/password on the mail server from accessing the mail system.

Email Playing Post Office
In most organizations, users have a personal computer on their desk where they read their mail. Some users will have even smaller systems (such as a Palm, Blackberry, or cellular phone) that are too small or too infrequently connected to the network to act as a mail server. Rather than making all of these systems full-fledged mail servers, a separate local delivery system is used. Each user’s PC makes requests to retrieve mail on demand in a manner similar to a person checking a post office box. There are two methods for providing post office services.

POP The Post Office Protocol (POP) is a simple mail retrieval protocol. The most recent version of the protocol, version 3, is detailed in RFC1939. A POP mail client authenticates itself as a particular user to the POP server, and can list, retrieve, and delete messages from that user’s mailbox. POP provides two internal authentication schemes, plain-text and APOP. APOP uses a time stamp, and a shared secret to produce an MD5 digest that is used to authenticate the user. Although APOP helps to secure the user’s password, the user name and all of the user’s still pass along the network in the clear. A more secure method is the use the POP protocol over a secure socket layer (SSL) connection. POP is usually not run as a persistent daemon, but is started on demand via the inetd or xinetd daemon. As with other inetd services, wrapping the POP server using tcpd or using the built-in access control features of xinetd is strongly recommended both for connection logging and access control.

POP The Post Office Protocol (POP) is a simple mail retrieval protocol. The most recent version of the protocol, version 3, detailed in RFC1939. A POP mail client authenticates itself as a user to the POP server, and can list, retrieve, and delete messages from that user’s mailbox. POP allows two internal authentication schemes, plain-text and APOP. APOP uses a time stamp, and a shared secret to produce an MD5 digest that is used to authenticate the user. Although APOP helps to secure the user’s password, the user name and all of the user’s still pass along the network in the clear.

POP A more secure method is the use the POP protocol over a secure socket layer (SSL) connection. POP is usually not run as a persistent daemon, but is started on demand via the inetd or xinetd daemon. As with other inetd services, wrapping the POP server using tcpd or using the built-in access control features of xinetd is strongly recommended both for connection logging and access control.

IMAP The downside to POP is that the user’s is removed from the server and copied onto the user’s system. The Internet Message Access Protocol (IMAP) offers a solution by providing a file-server-like facility tailored to handling . IMAP clients authenticate as a particular user to an IMAP server. IMAP clients can then obtain lists of messages and read messages, as well as manage folders.

IMAP All of the user’s can remain on the server, and be sorted and stored in folders managed via the IMAP client. On a server with adequate disk space and backups, IMAP can provide a more flexible and reliable system than POP. IMAP is particularly well suited for users who access their from more than one client. IMAP is a completely plain-text protocol. To provide security, IMAP can be run over an SSL connection. Like POP, IMAP is typically started via inetd or xinetd, and should be protected using a TCP wrapper .

Email IMAP There are several drawbacks to using IMAP.
First, IMAP makes much heavier use of the server than does POP, both in terms of disk space and I/O. Second, there are fewer IMAP clients available. Finally, accessing mail folders via IMAP can be slower than accessing local mail folders on a given client.

Email Mail User Agents (Mail Clients)
There are numerous MUA applications available for various operating system environments. Each offers different options, configuration methods/files, and user interfaces. Choosing an MUA A wise administrator will find two or three (at most) MUAs and make them available to local users. These will be the “supported” MUAs for the site. If users want to use an MUA that is not on the approved list, they will do so at their own risk. The administrator should consider (at least) the following factors while choosing an MUA for the site.

Email Mail User Agents (Mail Clients) Security
On personal computers, content-based attacks (in the form of viruses and other malicious software) is a security issue. A mail client can help or hinder efforts to defend against these problems. Like other Internet software mail clients, MUAs need to be robust in the face of malformed input data. Mail clients that have tightly integrated scripting functions have been used to launch attacks from infected personal computers. Mail clients should be configurable to prevent the execution of embedded scripts, viewing of HTML attachments, and execution of attachments found in incoming messages. WARNING: Microsoft’s Outlook and Outlook Express have a long history of poor security and have been the vectors of infection for a large number of viruses and other malware. The tight integration of scripting in Outlook is frequently exploited to reach beyond the individual PC and spread the infection to other systems.

Email Mail User Agents (Mail Clients) Availability
Users with a wide range of skills will use mail clients on a wide range of platforms. Mail clients that are available on multiple platforms and that offer the same user interface can save on user training and support effort, and allow consistent configuration across the organization. Support for Communication Standards A good mail client supports current standards for communication and content. Clients that support the secure forms of POP, IMAP, and SMTP are excellent choices for mobile users and environments with wireless networks. Clients that can properly handle MIME attachments, to facilitate document exchange, are a requirement in many environments.

Web-based Mail An alternative mail client that offers another solution for mobile users and users who employ multiple hosts is web-based mail. A web-based mail client is a suite of CGI programs, or an application server program, that act as a mail client using a web browser as the user interface. Web-based mail can be used from any client platform that has a web browser. If the web server offers encrypted connections, web-based mail can make use of the encrypted connection to protect the user ID, password, and message content.

Web-based Mail Setting up a web-based mail client requires obtaining and installing the needed CGI programs and supporting programs and adding them to the web server configuration. For example, SquirrelMail requires Apache, PHP, and an IMAP server, as well as the SquirrelMail software. To provide a secure connection, a web mail client will also require configuring the web server to use SSL.

Email Miscellaneous Mail Tools
System administrators of mail servers should be aware of a few ancillary tools that may be of help in their environment. procmail: The procmail filter is the default delivery agent on some UNIX variants, such as Red Hat Linux. It reads a rule set that can filter mail messages in a variety of ways. procmail is often used to pass through other filtering programs. spamassassin: One of the best tools for identifying those annoying and unwanted commercial s or SPAM. spamassissin uses several methods to attempt to identify a message as SPAM. It can be run several ways, including via procmail. fetchmail: fetchmail is a batch-oriented, command line POP and IMAP client. It is useful for situations in which noninteractive access to a mail server is needed.

Summary Keeping flowing is a required task for most system administrators. Choosing a good mail transport agent and properly configuring it is a good place to start, but the administrator also needs to think through the site’s model, user agents, and hardware required to provide this critical service. Users will benefit from a well-chosen combination of client and post office service daemon.

Automating System Administration Tasks
Chapter 23

Chapter Goals Understand what tasks lend themselves to automation.
Understand the tools available to automate system administration tasks. Understand differences between shells, and shell programming languages.

What to automate? As we have seen, there are several repetitive tasks in system administration: Downloading and installing patches Installing accounts Managing configuration files Managing printers Scanning log files Monitoring security Cleaning out temporary files. These tasks lend themselves to automation using a variety of tools.

What to automate? Patches Installing accounts
RedHat up2date Notre Dame’s “nd.installpatch” Installing accounts Acmaint grep user_name /afs/nd.edu/common/etc/passwd >>/etc/passwd ; pwconv Managing Configuration Files rdist expect rsync package

What to automate? Managing printers
Write a script to add printers for you Scanning log files and monitoring security Swatch Logwatch Write a script to watch for things of interest to you. Cleaning out temporary files cron find

Information Distribution
Distributing system information (files) is a problem. Small site --> small problem. Large site --> LARGE problem. Consider: Site with 4 system architectures: Sun (250 hosts) HP (250 hosts) IBM (250 hosts) PC’s with Linux (250 hosts) How would you distribute a new version of sendmail to each host?

The first problem to tackle is “what should we distribute”? Try to determine which files may be distributed to multiple system architectures (usually text files). Try to determine what binaries are located on the system disks (not on network file systems). Try to determine which files are scripts that would work on multiple architectures. Try to determine which files are common to all hosts of a particular architecture.

Some typical examples: System Binaries sendmail login – common to a single OS/architecture ftpd tcpd Common configuration files /etc/motd sendmail.cf password file shadow file – may not be directly usable

The next problem to tackle is which hosts you want to distribute files to: All hosts of an architecture? (Sparc, HP) All hosts which are clients of a particular server? All hosts which are null clients of a particular mail server? All hosts in engineering? The more files/architectures you have to distribute information to, the more complex the setup will be for the distribution method (and the more likely you will mess something up).

There are two methods of distributing system information: The push method - a server pushes the information to the clients. Advantages: It is usually easy to run “unscheduled” push operations. You have some control over when the process runs. Disadvantages: More difficult to update a single client. Tainted files will be distributed just like good files. Setup: Need to build/maintain copies of files to distribute. Need to build/maintain the distribution control file.

There are two methods of distributing system information: The pull method - a client pulls the information from a server. Advantages: It is easy to run “unscheduled” updates. Systems can be reset to a known state upon reboot. Disadvantages: More difficult to update clients all at once. Administrator has no idea which hosts have updated. Setup: Need to build/maintain copies of files to distribute. Need to build/maintain the distribution control file.

The push method The rdist program is one example of a “push method” file distribution system. Need to build a distfile tells what systems to distribute the files to tells which files to distribute to the systems allows special operations to be performed allows notification of success/failures allows exceptions to the rules may be run from a cron entry Has a handy “no action” version that allows rules testing.

Rdist Need to create a repository of files to distribute. Good idea to use RCS/SCCS/CVS to keep track of versions, and changes. Good idea to keep the repository “read only” so that bad versions of files do not get distributed. Special caveat: Rdist distributes the files with the ownership of the user who ran the rdist command. This can be a major problem if not handled by the settings in the distfile!

Sample rdist file # # distribute something to lab hosts
BASE=“/afs/nd.edu/user33/curt” SOL_CLIENTS=( snowwhite boole branin eckert noyce turing ) # Files to distribute lab6: $BASE/courses/cse444/lab6.init -> ${SOL_CLIENTS} install /etc/init.d/lab6; special "chmod 755 /etc/init.d/lab6";

Rdist Example # # distribute Solaris sendmail to grumpy, mail.cse), mail clients # distribute HPUX sendmail to geo # distribute AIX4 sendmail to yoyo and euclid BASE=/afs/nd.edu/wsadmin/cse_254 SRC=/afs/nd.edu/user14/csesoft/src SOL_CLIENTS=( aliens.dcrl atanasoff athena backus bashful berry boole branin) STANDALONE=( grumpy ) AIX_CLIENTS=(euclid yoyo) HPUX_CLIENTS=( geo ) SUNS=(${SOL_CLIENTS} ${STANDALONE} ${SERVER}) SERVER=( wizard ) ALL=(${SERVER} ${STANDALONE} ${SOL_CLIENTS} ${AIX_CLIENTS} )

Rdist example # # Files to distribute sendmail.cf.solcli:
$BASE/common/etc/mail/sendmail.cf -> ${SOL_CLIENTS} special "cp /etc/mail/sendmail.cf /etc/mail/sendmail.cf.old"; install /etc/mail/sendmail.cf.new; special "cp /etc/mail/sendmail.cf.new /etc/mail/sendmail.cf"; special "ln -s /etc/mail/sendmail.cf /etc/sendmail.cf"; special "rm /etc/mail/sendmail.cf.new"; sendmail.cf.server: $BASE/server/etc/mail/sendmail.cf -> ${SERVER}

Rdist example sendmail.cf.stand:
$BASE/grumpy/etc/mail/sendmail.cf -> ${STANDALONE} special "cp /etc/mail/sendmail.cf /etc/mail/sendmail.cf.old"; install /etc/mail/sendmail.cf.new; special "cp /etc/mail/sendmail.cf.new /etc/mail/sendmail.cf"; special "ln -s /etc/mail/sendmail.cf /etc/sendmail.cf"; special "rm /etc/mail/sendmail.cf.new"; sendmail.sun: $BASE/common/usr/lib/sendmail -> ${SUNS} special "cp /usr/lib/sendmail /usr/lib/sendmail.old"; install /usr/lib/sendmail.new; special "chgrp sys /usr/lib/sendmail"; special "chmod 6755 /usr/lib/sendmail"; special "/usr/local/bin/killj sendmail"; special "cp /usr/lib/sendmail.new /usr/lib/sendmail"; special "/usr/lib/sendmail -bd -q1h"; special "rm /usr/lib/sendmail.new";

Rdist example sendmail.cf.aix:
$SRC/sendmail/cf/cf/nd-csedept-AIX4-hidden.cf -> ${AIX_CLIENTS} special "cp /etc/mail/sendmail.cf /etc/mail/sendmail.cf.old"; install /etc/mail/sendmail.cf; special "ln -s /etc/mail/sendmail.cf /etc/sendmail.cf"; sendmail.aix: $SRC/sendmail/src/obj.AIX /sendmail -> ${AIX_CLIENTS} special "cp /usr/lib/sendmail /usr/lib/sendmail.old"; install /usr/lib/sendmail; special "/usr/local/bin/killj sendmail"; special "/usr/lib/sendmail -bd -q1h"; sendmail.cf.hpux: $SRC/sendmail/cf/cf/nd-csedept-HPUX10-hidden.cf -> ${HPUX_CLIENTS}

Rdist example sendmail.hpux:
$SRC/sendmail/src/obj.HP-UX.10.2/sendmail -> ${HPUX_CLIENTS} special "cp /usr/lib/sendmail /usr/lib/sendmail.old"; install /usr/lib/sendmail; special "/usr/local/bin/killj sendmail"; special "/usr/lib/sendmail -bd -q1h";

The pull method There are two common “pull” packages: expect expect uses ftp to copy files to the client expect provides some directives to manage the ftp session. can be run from a bootup script can be run from a cron entry

Sample expect script #!/usr/local/src/gnu/bin/expect spawn /bin/ftp
expect "ftp> " {send "open dopey.cselab.nd.edu\r"} expect "): " {send "gorp\r"} expect "Password:" {send expect "ftp> " {send "bin\r"} expect "ftp> " {send "get np.tar /dev/null\r"} expect "ftp> " {send "quit\r"} exit

Another pull technology is the “package” command used with AFS. package requires the administrator to set up a control file which contains a list of files which will be distributed. package allows a noaction mode to test rules. package could be run from cron (dangerous?). package is usually run at system reboot.

Sample package file # # CSE supplemental package file
# Need these directories defined so that we can get to other entries D / root root 755 D /afs root root 2755 D /etc root staff 755 D /etc/mail sys mail 755 D /etc/init.d root sys 775 D /etc/inet root sys 755 D /etc/rc3.d root sys 775 D /etc/rc2.d root sys 775 DR /var/tmp bin sys 1777 DR /tmp bin sys 1777 D /usr root sys 775 D /usr/bin root bin 775 D /usr/sbin root bin 775 D /usr/include root sys 775 D /usr/vice root other 755 D /usr/vice/etc root other 755 D /var root sys 755 D /var/spool root bin 755 D /var/spool/cron root sys 755 D /var/spool/cron/crontabs root sys 755

Sample package file # # Some necessary links
# Eases installation of new machines LA /usr/include/X11 /afs/nd.edu/sun4x_55/usr/local/src/X11R6/usr/include/X11 LA /usr/lib/X11 /afs/nd.edu/sun4x_55/usr/local/src/X11R6/usr/lib/X11 # Particular to this cluster # Package file, MOTD, and AFS cache size F /etc/motd /afs/nd.edu/wsadmin/cse_254/211 root sys 644 # For all CSE clients (i.e. non-wizard) F /.rhosts /afs/nd.edu/wsadmin/cse_254/common root sys 444 F /.cshrc /afs/nd.edu/wsadmin/cse_254/common root sys 444 F /.profile /afs/nd.edu/wsadmin/cse_254/common root sys 444 F /var/spool/cron/crontabs/root /afs/nd.edu/wsadmin/cse_254/common root other 400

Sample package file # Replace some /etc
F /etc/passwd /afs/nd.edu/wsadmin/cse_254/211server root other 644 F /etc/resolv.conf /afs/nd.edu/wsadmin/cse_254/211server root other 644 F /etc/pam.conf /afs/nd.edu/wsadmin/cse_254/common.26 root other 644 FQ /etc/inet/hosts /afs/nd.edu/wsadmin/cse_254/211server root other 444 LA /etc/hosts /etc/inet/hosts root other 644 F /etc/inet/services /afs/nd.edu/wsadmin/cse_254/common root other 644 LA /etc/services /etc/inet/services root other 644 F /etc/syslog.conf /afs/nd.edu/wsadmin/cse_254/common root other 644 F /etc/init.d/cse_client /afs/nd.edu/wsadmin/cse_254/common root other 755 LA /etc/rc3.d/S99cse_client /etc/init.d/cse_client root other 755 F /usr/etc/ifstatus /afs/nd.edu/wsadmin/cse_254/common.26 root other 755 F /etc/inet/inetd.conf /afs/nd.edu/wsadmin/cse_254/common root sys 444 LA /etc/inetd.conf /etc/inet/inetd.conf root other 444 F /usr/sbin/in.ftpd /afs/nd.edu/wsadmin/cse_254/common.26 bin bin 555 F /etc/ftpaccess /afs/nd.edu/wsadmin/cse_254/common.26 bin bin 555 F /usr/bin/top /afs/nd.edu/wsadmin/cse_254/common bin bin 4755 ## FAQ /usr/lib/sendmail /afs/nd.edu/wsadmin/cse_254/common/usr/lib/sendmail root other 4555 F /usr/lib/sendmail.hf /afs/nd.edu/wsadmin/cse_254/common root other 555 F /etc/mail/sendmail.cf /afs/nd.edu/wsadmin/cse_254/ root other 444 LA /etc/sendmail.cf /etc/mail/sendmail.cf root other 444

Other distribution methods NIS - centralized database, not really a way to “distribute” files. The files are available to other hosts, but they are located on a (few) server(s). MIT’s Hesoid - never caught on, difficult to build configuration files. Uses DNS to provide information from a central server. Netinfo - NeXT computer’s version of NIS. Rsync Cfengine

Shells Many automation tasks are handled using shell (or other) scripts. Shell scripts are generally portable across multiple versions of operating systems. Other scripting languages, such as Python, or Perl are much more powerful, but not always installed on systems by default.

Shell Programming Shells
UNIX provides several shell programs for the users. These programs are the user’s interface with the system software. The shell programs read commands from the user terminal and interpret or execute them as required. Some of the more popular shells available are: sh - the original Bourne shell csh - the Berkeley C shell bash - the Bourne Again SHell (an updated sh) ksh - the Korn shell tcsh - an updated version of the C shell.

Shell selection is a highly subjective user decision. While the shells are primarily a command interpreter, they also provide an interpreted programming language which users can employ to make their lives easier. Different shells implement different programming languages. Unfortunately, system administrators have to be proficient with several shell languages in order to manage the system. Over the next few lectures we will look at the “sh” and “csh” shells. In particular we will look at using these shells to write shell scripts which will assist us with our system administration tasks.

Most of you use a variant of the Cshell (csh or tcsh). The Cshell provides some job control, and command line editing options not available under the Bourne shell (sh). Tcsh provides more advanced command line editing and parsing than csh...but tcsh is not a standard shell on all versions of Unix. Under Solaris the root account uses the bourne shell located in /sbin/sh. The bourne shell is not my favorite shell, but the examples I give will be sh based. If you are serious about system administration, I suggest you become familiar with both sh and csh environments.

Shell Programming Common Shell Features
All shells have some common features: Shells allow interactive or background processing. Shells allow input/output redirection. Shells allow “pipes” between commands. Shells allow wildcard matching. Shells assign special meaning to some characters. Shells use variables to store values. The common invocation of a shell command is: command [options] arguments

Shell Programming Example Script Invocations
nispopulate -u -F -p /nisstuff/update -d cselab.nd.edu. /etc/init.d/lab10 start which talk cd /tmp basename /afs/nd.edu/user33/curt

Shell Programming Built-in Shell Operations
Shells all have some built-in commands which we can use when writing shell scripts: echo - write a message on standard output (CSH). Been hit by root kit? Use echo! read - read something from standard input test - test various conditions expr - evaluate an expression true - return a true value false - return a false value wait - wait for something (good) to happen sleep - stop for some period of time

Shell Programming Shell Variables (Built-in)
All shells have some built-in variables (reserved names) which can be useful when we write shell scripts: PATH - The system search path LOGNAME - The users login name TERM - The kind of terminal the user is at HOME - The users home directory MAIL - The location of the users mailbox PS1 - The primary prompt string for the user LD_LIBRARY_PATH - The path to system libraries.

Shell Programming Shell Variables (user assigned)
To assign a values to a variables: variable=value (set variable=value for CSH) for example fruit=apple, or i=1, set name=$USER To access the value of the variable, prepend a “$” : echo fruit fruit echo $fruit apple echo “User: $USER” User: curt

Shell Programming Shell Variables echo $PS1
You can also set variables by executing commands: menu=`cat food` now=`date` It is also possible to assign string values to variables: PS1=“`uname -n` - Yes Master: “ echo $PS1 grumpy - Yes Master: Must place multi-word strings in double quotes

Shell Programming Metacharacters
All shells treat certain characters as special. $ ^ ; & { } [ ] ‘ ` * ( ) | < > newline space tab To use these characters in scripts they must be quoted or escaped. escape a character by placing a backslash in front of it. single quotes protect text from any substitutions. back quotes cause the shell to perform command substitution double quotes protect against wildcard substitution

Shell Programming Escaping Characters: $ ( )
syntax error: `)' unexpected $  (): not found Single Quotes $ it's $cmd > ' its $cmd^J: not found $ it\'s $cmd it's: not found

Shell Programming Back Quotes $ HN=uname -n -n: not found
$ echo $HN grumpy $ who am i curt pts/ Nov 11 13:47 $ 'who am i' who am i: not found $ `who am i` curt: not found

Shell Programming Double Quotes $ grep Things to do todolist
grep: can't open to grep: can't open do todolist:Things to do: $ grep "Things to do" todolist Things to do:

Shell Programming Shell test features
All shells provide test mechanisms: This feature allows us to do conditional processing within shell scripts. In sh we can test for: numeric values: if [ $# -eq 0 ] ; then if ( $# = 0 ) then (CSH version) general form: N <primitive> M -eq, -ne, -gt, -lt, -ge, -le = != > < >= <= -o (or) -a (and)

Shell Programming if [ -e /usr/lab/tmp/”$AFSID”.start ] ; then
Test Conditions The shells also provides a way to test the external environment: -r file (read permission) -w file (write permission) -x file (execute permission) -e file (file exists) -o file (user owns file) -z file (file is empty) -f file (plain file) -d file (file is a directory) if [ -e /usr/lab/tmp/”$AFSID”.start ] ; then if [ ! -d /usr/lab/tmp/”$AFSID” ] ; then

Shell Programming Shell test features if [ $LOGNAME = “root” ] ; then
string equality if [ $LOGNAME = “root” ] ; then general form: S <primitive> R ; or <primitive> S primitives: =, != -z - is string zero length -n - is string non zero length Testing strings can produce “odd” results: number=1 nombre=‘ 1’ test $number = $nombre evaluates true (spaces eaten) test “$number” = “$nombre” evaluates false

Shell Programming Shell Math
The shell also allows mathematical operations on variables: The expr command evaluates it’s arguments. General form: expr variable operation variable operations: +, -, *, /, % (remainder) sum=`expr $1 + $2`

Shell Programming if [ condition ] ; then if ( condition) then
Conditional Processing The shells all provide a way to do conditional processing: if [ condition ] ; then if ( condition) then statements else (or else if) fi endif

Shell Programming Conditional Processing statements do done end
for variable in list # BOURNE SHELL do statements done foreach i ( list ) # CSH end

Shell Programming Conditional Processing statements do statements
while condition #BOURNE while condition # CSH do statements statements done end until condition do done

Shell Programming Conditional Processing SH statements ;;
case variable in pattern 1) statements ;; pattern 2) *) #default case esac

Shell Programming Conditional Processing CSH statements breaksw
switch ( variable ) case pattern 1: statements breaksw pattern 2: default : endsw

Shell Programming Argument Handling
The shell defines a method of handling arguments: $$ is the process id of the shell program The name of the shell program itself is $0 Argument variables are numbered in the order passed: $1 $2 $3 $4 ... $* and access all variables $* lumps all variables into a single string keeps variables as separate entities $# is set to the argument count

Shell Programming Argument Handling
When you pass an argument to a shell script how do you access it? For example : /etc/init.d/lab8 start In the example above we can test $1 to see if it is “start” or “stop” and continue accordingly.

Shell Programming I/O Redirection Input Output
< file -- causes shell to read from file <&n -- causes shell to read from file descriptor n <& causes shell to close standard input <tag -- causes shell to read up to tag <~tag -- same as <tag, but discard white space Output > file -- causes shell to write to file >>file -- causes shell to append to file >&n -- causes shell to write to file descriptor n >& causes shell to close standard output | pipe the output of command and feed it to next command

Shell Programming I/O Redirection echo $1 $2 $3 > $4 # overwrite $4
echo $1 $2 $3 >> $ # append to $4 10 03 * * * cd /tmp ; find . ! -name . -type d -mtime +1 -exec rmdir {} \; >/dev/null 2>&1 ps -ef | grep curt read answer </dev/tty cat < EOF FATAL ERROR: $SPOOL/etc/setup.cache is missing! The file $SPOOL/etc/setup.cache is not present. This probably means the machine has not been setup using the faxsetup(1M) command. Read the documentation on setting up HylaFAX before you startup a server system. EOF

Shell Programming echo “Enter your afsid: “
Other Shell Features The : command is a null command. Shells allow I/O operations: echo “Enter your afsid: “ read AFSID </dev/tty cat file.dat | while read x y z >do echo $x $y $z ; done

Shell Programming Other Shell Features
All shells provide a means of assigning temporary filenames for their use: sort -u $* |tr -d 0-9 >/tmp/$0$$ All shells provide a means of catching interrupts for cleanup processing: trap ‘command arguments’ signal All shells provide a means of debugging shell programs (-x). All shells allow for those dreaded comments: # rest of line is a comment

Shell Programming Other Shell Features who -r
The set command allows you to set $1 through $n to the words given as its arguments: who -r . run-level 3 Nov 21 09: S set `who -r` echo $6 09:13

Shell Programming $ a=c ; b=m ; c=d ; cmd=date $ eval $`echo $a$b$c`
Other Shell features The shells also provide a utility to execute arguments. The eval command executes commands generated by multiple levels of indirection: $ a=c ; b=m ; c=d ; cmd=date $ eval $`echo $a$b$c` Fri Nov 21 09:18:45 EST 1997 $ $cmd Fri Nov 21 09:18:49 EST 1997

Shell Programming #!/bin/sh #ident "@(#)nfs.client 1.8 93/07/07 SMI"
if [ ! -d /usr/bin ] then # /usr not mounted exit fi killproc() { # kill the named process(es) pid=`/usr/bin/ps -e | /usr/bin/grep $1 | /usr/bin/sed -e 's/^ *//' -e 's/ .*//'` [ "$pid" != "" ] && kill $pid }

Shell Programming # Start/stop processes required for client NFS
case "$1" in 'start') if [ -x /usr/lib/nfs/statd -a -x /usr/lib/nfs/lockd ] then /usr/lib/nfs/statd > /dev/console 2>&1 /usr/lib/nfs/lockd > /dev/console 2>&1 fi # obtain kerberos ticket before attempting kerberos NFS mounts /usr/bin/sed -e 's/#.*//' /etc/vfstab | \ /usr/bin/grep kerberos >/dev/null 2>&1 if [ $? = 0 -a -x /usr/bin/ksrvtgt -a -x /usr/bin/uname ] then HNAME=`/usr/bin/uname -n` WARN=`/usr/bin/ksrvtgt root $HNAME 2>&1` if [ $? != 0 ] then echo "Warning: cannot get kerb ticket for root.$HNAME" echo " ksrvtgt error: $WARN"

Shell Programming /sbin/mountall -F nfs /sbin/mountall -F cachefs
/sbin/swapadd ;; 'stop') killproc lockd killproc statd /sbin/umountall -F cachefs /sbin/umountall -F nfs *) echo "Usage: /etc/init.d/nfs.client { start | stop }" esac

Shell Programming Shell Programming
All shells provide us with programming constructs (variables, flow control, conditional tests, ...). with these facilities we can write programs to make our lives easier. When writing shell programs we also have easy access to all of the system utilities. By combining shell code and utility calls it is easy to write very powerful tools!

Find Command Cleanup Tools Find
The find command can be a very useful tool for administrators to police disk usage. You can find and remove cruft from system directories (core files, a.out, .o files, junk in /tmp). You can locate files owned by a particular user. You can locate files with particular permissions. You can locate files containing a specific string. You can locate files which have been modified since a particular date. You can locate files of a particular size.

Find Command WARNING!!! Removing files from a users directory may be illegal! Files in a user’s account are considered property of the user unless otherwise stated in site policies. User must be informed that files in their account are not personal/private. Files in /tmp are exempt from this, as /tmp is a Public file system. Other public file systems (/scratch, /usr/tmp, /var/tmp, /pub) are also typically considered exempt.

Find Command Find find pathlist expression
The generic invocation of find is: find pathlist expression The pathlist is a directory [or list of directories and/or files] you wish to search. The expression is a directive which tells find what to look for, and what to do when it finds what it is looking for.

Find Command Find pathlist expression
Some of the more useful expressions for the find command include: name - search for files called name atime n - search for files which were accessed n days ago. ls - print the current path and related statistics mtime n - search for files which were modified n days ago. exec command - execute command when the file is found. print - causes the filename to be printed when found. type c - search for files of type “c” (file, directory, link, device files, fifo, socket) fstype type - search for filesystems of type

Find Command Find examples
Suppose you want to make a tape of your files before you leave Notre Dame. You want to keep your source code, your mail addresses, and other files, but you do not want to carry along your a.out’s, any of the .o files, or any netscape cache files. find $HOME $-name a.out -o -name ‘*.o’ -o -name ‘cache*’$ -exec rm{} ; If you were a system administrator who wanted to remove the same files from all directories on the system you could modify the command a little: find / $-name a.out -o -name ‘*.o’ -o -name ‘cache*’$ -exec rm{} \; SEE WARNING!!

Find Command Find examples
Suppose you had a series of users complain that their .login files had been modified yesterday by someone other than themselves. If you wanted to find all instances of modified .login files you could use: find /home -name .login -mtime +1 -print Similarly, suppose you knew that someone had compromised your system and replaced the shell program with their own version. You found the string “floobydust” in their version of the shell program, so you want to look and find out if they left other copies of their program on the system: find / -type f -exec grep -l “floobydust” {} \;

Find Command Find How do the security tools we discussed (SATAN, COPS) find suid programs? find / (-perm o -perm o -perm 1755) -print Suppose an employee (UID 666) leaves the company and another employee (UID 999) takes over the code managed by the old employee. You have been asked to make sure the new employee has full permissions on the files the old employee owned: find / -user 666 -exec chown 999 {} \; SEE WARNING!!!

Find Command Find Find can also be a useful tool for forgetful users (or professors) who want to find where they left something. find $HOME -name homework6 -print find $HOME -exec grep -l “lab combination” {} \; As a system administrator you need to think about a couple of questions: How often should these housekeeping functions be performed? Is there a method that will automate these functions without requiring my intervention.

Find Command Cleanup Tools
Many places create special scripts to locate and remove “cruft” from the system. Skulker SpaceGripe DiskClean Most are based on find.

AWK AWK AWK is a powerful pattern matching and scanning tool used by system administrators. AWK is typically used to scan an input string, grab certain portions of the string, then output the information in another format. AWK was developed by Alfred Aho, Peter Weinberger, and Brian Kernighan (hence the name AWK). There are several variants of awk: standard awk (awk), Gnu awk (gawk), and new awk (nawk) are the most common.

AWK AWK Awk allows us to: Nawk adds several capabilities:
view a text file as if it were made up of records and fields in a textual database Use variables to manipulate the database Use loops and conditional processing Generate formatted reports Nawk adds several capabilities: Define functions Execute UNIX commands Process the results of UNIX commands Better command line argument processing Work with multiple input streams

AWK Generic invocations:
awk ‘instructions’ files awk -f ‘script’ files If you have a file (filename list) with the following entries: John Doe, 999 Sorin Hall Jeff Walker, 234 Cushing Hall Amy Vanderbilt, 876 Hesburgh Library awk ‘{print $1}’ list will output : John Jeff Amy

AWK If you wanted to make mail labels from the file “list” you could do: awk -F, ‘{print $1 print $2 print “Notre Dame, IN 46656”}’ The output would be: John Doe 999 Sorin Hall Notre Dame, IN 46656 Jeff Walker 234 Cushing Hall Amy Vanderbilt 876 Hesburgh Library

AWK input: name address phone John Doe, 123 Sorin Hall, 634-4444
You can set shell variables with the output of the awk command. input: name address phone John Doe, 123 Sorin Hall, name=`awk ‘{print $1}’ input` echo $name John

AWK Awk Awk does a lot of the “programming” for you.
An AWK program has three parts: An optional “begin” routine which is executed once before the main loop. The main loop. An optional “end” routine that is executed after all of the main loop code is done. AWK provides the main loop. When you call AWK is goes into a loop reading input and providing it to your code. You do not have to write code to read the input....you just provide pattern matching statements.

AWK AWK awk ‘{print $1}’ file AWK acts on patterns..
Your code is a series of patterns and actions. When AWK detects the pattern, it executes the action. For example: awk ‘{print $1}’ file tells awk to print the first field of the input line. $1 is the pattern print $1 is the action

AWK /^$/ {print “Input is a blank line” }
AWK Regular Expressions /^$/ {print “Input is a blank line” } /[0-9]+$/ {print “Input is an integer” } /[A-z]+/ {print “Input is a string” } AWK works with internal variables much like the Bourne shell does: x = 1 assigns the value 1 to x z = “Hello” assigns the string “Hello” to z w = $1 assigns the value of the first field of the input to the variable w.

AWK AWK If we want to perform mathematical operations on the variables in an AWK script, the following operators are available: +, -, *, /, %, ^ AWK also has a group of assignment operators: +=, ++, --, -=, *=, /=, %= A simple script to count blank lines in a file: awk ‘/^$/ { ++x} END { print x }’ file

AWK AWK has some handy built-in variables:
FS is the input field separator. (Default space or tab) OFS is the output field separator RS is the input record separator (Default newline) FILENAME is the name of the input file NR is the number of input records read AWK has relational operators and Boolean operators: <, >, <=, >=, ==, !=, ~, !~ ||, &&

AWK So what is all of this useful for (besides lab9)?
Suppose your site has a shell called the new shell (nsh). You are discontinuing support for this shell because it is very similar to the zork shell. You need to scan the password file, convert all accounts with nsh to use zork, and you need to keep track of how many users you convert over to the zork shell. The password file consists of 7 colon separated fields. The users shell is held in the 7th field of the input.

AWK awk '{ # Set delimiters BEGIN { FS=":" ; OFS=":" }
# if shell ($7) is /bin/nsh convert it to /bin/zork { if ( $7 == "/bin/nsh" ) { nnsh++ ; print $1,$2,$3,$4,$5,$6,"/bin/zork" } # Otherwise don’t change the line else { print $1,$2,$3,$4,$5,$6,$7 } # Print number of users assimilated } END { print nnsh “ users converted from /bin/nsh to /bin/zork” } }'

AWK Another stupid example:
You work for a Veterinarian. The Dr. wants to send a postcard to the owners of all dogs informing them of a new parvo-virus immunization law. The information format in the Dr’s database is: Species,Owner Name, Address, City, State, Zip, Phone, Animal’s Name, Animals Age, Immunized,Last Visit, Notes

AWK nawk -F, '{ # If canine and not immunized, print postcard, else ignore the line if ( $1 == "Canine" && $10 == "No" ) {print $2 ; print $3 ; print $4 ", " $5 " " $6 print "" print "Dear " $2 "," print "A recently enacted state law requires that all dog" ; print "owners get their animals immunized for parvo-virus " ; print "as soon as possible. Our records indicate that " $8 print "needs to be immunized. Please call our office to " ; print "make an appointment as soon as possible." } }'

Other Useful Tools Some other tools you might want to experiment with:
cut - cut bytes from the input. first=Curt last=Freeland f1=ècho $first | cut -b1` f1=C ln=ècho $last | cut -b1-7` ln=Freelan try=curt:x:1234:40:GECOS:/home/curt:/bin/csh found=ècho $try | cut -d: -f1` found=curt

Other Useful Tools It’s pretty easy to convert strings from upper to lower case in C. How would you do the same thing in shell scripts? The tr command translates (or transforms) characters on the input stream into different characters on the output stream. echo $f1$ln CFreelan lname=`echo $f1$ln | tr “[:upper:]” “[:lower:]”` echo $lname cfreelan

Other Useful Tools There are many variants of the grep command. The “fgrep” command has an interesting flag: Consider: a password file contains the following entries: curt:x:1234:40:GECOS:/home/curt:/bin/csh curt1:x:1235:40:GECOS:/home/curt1:/bin/csh curt2:x:1236:40:GECOS:/home/curt2:/bin/csh grep curt /etc/passwd will return all three lines! fgrep -x curt /etc/passwd returns nothing! The -x flag tells grep that it has to match the entire input string exactly. awk -F: ‘{print $1}’ /etc/passwd | fgrep -x curt

Other Useful Tools sed ‘1,3d’ file sed ‘[Jj]ohn/p’ datafile
The Streams editor (sed) is a very handy tool. sed uses regular expression matching to convert the input stream to a new output stream one line at a time. SED works on a temporary buffer called the pattern space - it does not change the original input file. SED uses the same commands as the ex and vi editor (when run in line mode). sed ‘1,3d’ file Deletes lines 1-3 from file and displays result on screen. sed ‘[Jj]ohn/p’ datafile Prints any lines from the input file that contain John or john

Other Useful Tools #!/bin/sh #ident "@(#)nfs.client 1.8 93/07/07 SMI"
if [ ! -d /usr/bin ] then # /usr not mounted exit fi killproc() { # kill the named process(es) pid=`/usr/bin/ps -e | /usr/bin/grep -w $1 | /usr/bin/sed -e 's/^ *//' -e 's/ .*//'` [ "$pid" != "" ] && kill $pid }

Summary Automating repetitive tasks allows the administrator time to get other things done. The administrator needs to understand what can be automated, and what cannot be automated. The administrator should understand how to write shell scripts using the command line utilities used to perform daily tasks.

Performance Analysis Chapter 24

Chapter Goals Understand the basic terminology of performance monitoring and analysis. Understand proper methods of monitoring a system’s performance. Knowledge of the tools that allow you to monitor system performance. Understand how to analyze the data provided by the monitoring tools. Understand how to apply the data to improve system performance. Understand what to tune, and why to tune it.

General Performance Tuning Rules
Right-size the system to start with. You do not want to start with an overtaxed system with the intention of providing a turbo-charged service. UNIX is very demanding on hardware. UNIX generally provides each process with (the illusion of) unlimited resources. This often leads to problems when system resources are taxed. Windows operating systems and applications often understate system requirements. The OS and/or applications will operate in a sparse environment, but the performance is often abysmal.

Determine the hardware requirements of specific types of servers. Generally, and web servers require high-throughput network links, and medium to large memory capacity. Mail servers typically require significantly more disk space than web servers. Database servers typically require large amounts of memory, high capacity, high-speed disk systems, and significant processing elements. Timeshare systems require significant processing elements, and large amounts of memory.

Monitor critical systems from day one in order to get a baseline of what “normal” job mixes and performance levels are for each system. Before making changes to a system configuration, make sure user jobs are not causing problems. Check for rabbit jobs, users running too many jobs, or jobs of an inappropriate size on the system. A performance problem may be temporary, so you need to think through any changes before you implement them. You might also want to discuss proposed changes with other system administrators as a sanity check.

Once you are ready to make changes, take a scientific approach to implementing them. You want to ensure that the impact of each change is independently measurable. You also want to make sure you have a goal in mind, at which point you stop tuning and move on to other projects. Before you begin making changes to the system, consider the following. Always know exactly what you are trying to achieve. Measure the current system performance before making any changes. Make one change at a time.

Change Rules Once you do make a change, make sure to monitor the altered system for a long enough period to know how the system performs under various conditions (light load, heavy load, I/O load, swapping). Do not be afraid to back out of a change if it appears to be causing problems. When you back a change out, go back to the system configuration immediately previous to the “bad” configuration. Do not try to back out one change and insert another change at the same time. Take copious notes. These are often handy when you upgrade the OS, and have to start the entire process over.

Resource Rules Install as much memory as you can afford.
Disk systems can also have a substantial impact on system performance. Network adapters are well-known bottlenecks. Eliminate unused drivers, daemons, and processes on the system. Know and understand the resources required by the applications you are running.

Terminology Bandwidth: Throughput:
The amount of a resource available. If a highway contains four lanes (two in each direction), each car holds four people, and the maximum speed limit allows 6 cars per second to pass over a line across the road, the “bandwidth” of the road is 24 people per second. Increasing the number of lanes will increase the bandwidth. Throughput: Percentage of the bandwidth you are actually getting. Continuing with the road example, if the cars only hold one person, the protocol is inefficient (not making use of the available capacity). If traffic is backed up due to an accident and only one or two cars per second can pass the line, the system is congested, and the throughput is impacted. Likewise, if there is a toll booth on the road, the system experiences delays (latency) related to the operation of the toll booth.

Terminology Latency: Response time: Knee: Utilization:
How much of the resource was used. It is possible to use 100% of the resource, and yet have 0% throughput (consider a traffic jam at rush hour). Latency: How long it takes for something to happen. In the case of the road example, how long does it take to pay the toll? Response time: How long the user thinks it takes for something to occur. Knee: Point at which throughput starts to drop off as load increases.

Terminology Benchmark: Baseline:
Set of statistics that (hopefully) shows the true bandwidth and/or throughput of a system. Baseline: Set of statistics that shows the performance of a system over a long period of time. Instantaneous data about the system’s performance is rarely useful for tuning the system. But long-term data is not very useful either, as peaks and valleys in the performance graph tend to disappear over time. You need to know the long-term performance characteristics, as well as the “spikes” caused by short-lived processes. A good way to obtain long-term (and short-term) information is to run the vmstat command every five seconds for a 24-hour period. Collect the data points, reduce/graph these data points, and study the results.

Windows Monitoring Task Manager
The Cygwin package allows the administrator to build and install several UNIX tools to monitor system performance. For sites that do not use the Cygwin toolkit, there are several third-party native Windows tools that might be useful when you need to monitor system performance. Among these tools are: vtune products/vtune/ SysInternals

UNIX Monitoring ps top vmstat iostat nfsstat netstat mpstat accounting

Unix Monitoring Most versions of UNIX ship with an accounting package that can monitor the system performance, and record information about commands used. Many sites run the detailed system accounting package in order to bill departments/users for the use of the computing resources they consume. The accounting packages can also be very useful tools for tracking system performance. Although the accounting information is generally most useful as a post-mortem tool (after the processes has completed), it is sometimes possible to gather semi real-time information from the system accounting utilities. System auditing packages can give a lot of information about the use of the system, but these packages also add considerable load to the system. Process accounting utilities will generally add 5% of overhead to the system load, and auditing utilities can add (up to) 20% of overhead load to the system.

Accounting Why run accounting? CPU time used Memory used
Bill for resources used. CPU time used Memory used Disk space used Printer page accounting Detailed job flow accounting (Banks/Insurance/Stock trading) Keep track of every keystroke Keep track of every transaction Security track every network connection track every local login Track every keystroke

Accounting Two types of accounting Process accounting
Track what commands are used Track what system calls are issued Track what libraries are used Good for security (audit trail) Good when multiple users have access to system Good way to track what utilities and applications are being used, and who is using them.

Accounting Detailed accounting Track every I/O operation
Disk Tape tty Network Video Audio Primarily used for billing

Accounting Charging for computer use
Almost unheard of in academia (today). Some Universities charge research groups for CPU time. Some Universities charge for printer supplies. Some Universities charge for disk space and backups. Most companies that run accounting have a central computing facility. Subsidiaries buy computing time from the central group. Accounting is used to pay for support, supplies, …

Accounting Why avoid accounting? Log files are huge
Must have disk space for them. 15 minutes of detailed accounting on a system with one user generated a 20 MB log file! 15 minutes of process accounting on a system with one user generated a 10 MB log file! Must have (and bill) cpu time for accounting. Accounting can require a lot of CPU/disk resources Who will pay for the CPU/disk resources used by accounting Must decide what information to keep, and what to pitch.

Accounting What can accounting track?
Some of the common things to track: CPU time Memory usage Disk usage I/O usage Connect time Dial-up/Dial-out usage Printer accounting

Accounting Solaris Auditing Perform audit trail accounting
Relies on the Basic Security Module (BSM). Can monitor TONS of stuff. Processes Function/subroutine calls System calls Ioctls Libraries loaded File operations (open close read write create remove) File system operations (stat, chmod chown, …) Can configure to monitor successful/unsuccessful operations Can monitor on a per user basis

Accounting Solaris Audit binaries auditconfig
auditd – the audit daemon praudit – print audit information auditon – turn on auditing

Accounting Solaris Audit files Control Files in /etc/security
audit_class audit_control audit_data audit_event audit_startup audit_user audit_warn device_allocate device_maps

Accounting Solaris Audit Files Data Files in /var/audit
YYYYMMDDHHMMSS.YYYYMMDDHHMMSS.hostname YYYYMMDDHHMMSS.not_terminated.hostname

Accounting Solaris Accounting Daily Accounting Connect Accounting
Process Accounting Disk Accounting Calculating User Fees

Accounting Solaris Accounting /usr/lib/acct/acctdisk
/usr/lib/acct/acctdusg /usr/lib/acct/accton /usr/lib/acct/acctwtmp /usr/lib/acct/closewtmp /usr/lib/acct/utmp2wtmp

Accounting Solaris Accounting binaries
acctcom – search/print accounting files acctcms – generate command accounting from logs acctcon – turn accounting on/off acctmerg – merge multiple account forms into a report Acctprc – programs to generate process accounting logs fwtmp – manipulate connect accounting records runacct – run daily accounting summary

Accounting Solaris Accounting Data Files /var/adm/pacct
/var/adm/acct/fiscal /var/adm/acct/nite /var/adm/acct/sum

Performance Analysis Unix User Interface researchers report that an average user perceives a system to be slow when response times are longer than 0.7 seconds!

Performance Analysis CPU time – Memory speed –
How long does the user’s job take to complete? Is the job time critical? What other jobs are running? Context switches are costly. Must share cpu cycles with other processes What is the system load average? Memory speed – Does the job need to be loaded into memory? How quickly can memory be filled with pertinent information? Is the job swapped out? Swapping brings disk system into picture. Swapping invalidates cache for this job. Swapping is easy to eliminate/minimize! Does the job fit into cache?

Performance Analysis Disk I/O bandwidth – Network I/O bandwidth –
Bus Speed Controller width/speed How fast can information be pulled off of disk? SCSI vs IDE vs RAID Rotational latency Caching in controller/drive Disk system speed will have an effect on memory speed (swapping). Network I/O bandwidth – Are files stored on a network file system? Does network file system do any caching? Shared/switched media? Full/half duplex?

Performance Analysis CPU bound jobs are difficult to measure.
Use ps and top to see what is running. Use uptime to determine load averages 1 minute average is good for “spiky” load problems 5 minute average is good metric to monitor for “normal” activity 15 minute average is good indicator of overload conditions Use sar to determine the system cpu states. System accounting can track amount of time each CPU spends working on idle/system/user jobs. Use mpstat to determine what multi-processor systems are doing. One busy processor and one idle processor is probably “normal” operation. Use vmstat and iostat to determine percentage of time system is running user/kernel processes. Less detail than sar, but good general information.

Performance Analysis How can you improve CPU performance? More cpu(s)
Faster cpu(s) Lock jobs to specific cpu(s) Lock cpu(s) to specific tasks

Performance Analysis Before you can diagnose performance problems, you must have a good idea of what is reasonable for your system. Monitor system and develop a fingerprint of typical job mixes, load average, memory use, disk use, network throughput, number of users, swapping, job size. If something happens to the performance use these metrics to determine what has changed. Did jobs get larger? More disk or network I/O? Less free memory? More swapping? More users? More jobs?

CPU Performance In general, the output of the top, vmstat, w, and other utilities that show processor-state statistics can tell you a lot about the performance of the CPU subsystem. If the CPU is in user mode more than 90% of the time, with little or no idle time, it is executing application code. This is probably what you want it to do, but too many user jobs running concurrently may be detrimental to any one job getting any work done. If the CPU is in system mode more than 30% of the time, it is executing system code (probably I/O, or other system calls). Context switches are a symptom of high I/O activity (if the interrupt rate is also high). If seen in conjunction with high system call activity, it is a sign of poor code (nonlocal data, open, read, close, or loop). If the CPU is idle more than 10% of the time, the system is waiting on I/O (disk/network). This could be a symptom of poor application code (no internal buffering) or overloaded disk/network subsystems.

CPU Performance If the system exhibits a high rate of context switches, the system is displaying symptoms of a number of possible problems. Context switches occur when one job yields the processor to another job. This may occur because the scheduler time slice expired for the running job, because the running job required input/output or because a system interrupt occurred. If the number of context switches is high, and the interrupt rate is high, the system is probably performing I/O. If the number of context switches is high, and the system call rate is high, the problem is likely the result of bad application coding practices. Such practices include a program loop that repeatedly performs the sequence “open a file, read from the file, close the file.”

CPU Performance If the system exhibits a high trap rate, and few system calls, the system is probably experiencing page faults, experiencing memory errors, or attempting to execute unimplemented instructions. Some chips do not contain instructions to perform certain mathematical operations. Such systems require that the system generate a trap that causes the system to use software routines to perform the operation. An example of this situation occurs when you attempt to run a SPARC V8 binary on a SPARC V7 system. The SPARC V7 system contains no integer multiply/divide hardware. SPARC V8 systems contain hardware multiply/divide instructions, so compiling a program on the V8 architecture imbeds these instructions in the program. When this same program is run on a V7 system, the OS has to trap the instructions, call a software routine to perform the calculation, and then return to the running program with the answer.

Performance Analysis Memory is a critical system resource.
Unix is very good at finding/hoarding memory for disk/network buffers. Unix buffering scheme At boot time, size memory. Kernel takes all memory and hoards it As jobs start, kernel begrudgingly gives some memory back to them. In some versions of UNIX: Disk buffers are allocated on file system (disk partition) basis Network buffers are allocated on a per-interface basis.

Performance Analysis Memory is a critical system resource.
Before upgrading the cluster systems OIT looked at the memory question: With 64 Meg jobs took X minutes to run. With 128 Meg of memory, the same jobs took X/3 minutes to run. With 256 Meg of memory, the same job did not run any faster, but you could run multiple instances of same job with no degradation in performance. Memory is cheap. Buy lots!

Performance Analysis Monitoring memory use. Memory is cheap! Buy Lots!
Use pstat -s to look at swap information on BSD systems. Use swap -l to look at swap on System V systems. Use sar -r to look at swap information Use vmstat to look at memory statistics. Use top to monitor job sizes and swap information. If there is any sign of swapping Memory is cheap! Buy Lots! Can adjust reclaim rate, and other memory system parameters, but it is usually more profitable to add memory.

Memory Performance Unlike CPU tuning, memory tuning is a bit more objective. Quantifying CPU performance can be somewhat elusive, but quantifying memory usage is usually pretty straightforward. Job Size An easy diagnostic for memory problems is to add up the size of all jobs running on the system, and compare this to the size of the system’s physical memory. If the size of the jobs is grossly out of proportion to the size of the system memory, you need to do something to change this situation. You could use a scheduler that uses job size as one of the criteria for allowing a job to run, remove some processes from the system (for example migrate some applications to another server), or add memory to lessen the disparity in the requested versus available memory.

Memory Performance Swapping/Paging
Under BSD operating systems, the amount of virtual memory is equal to the swap space allocated on the system disks plus the size of the shared text segments in memory. The BSD VM system required that you allocate swap space equal to or greater than the size of memory. Many BSD environments recommended that you allocate swap space equal to 4x the size of real memory. Under System V UNIX kernels, the total amount of virtual memory is equal to the size of the swap space plus the size of memory, minus a small amount of “overhead” space. The system does not begin to swap until the job memory requirements exceed the size of the system memory.

Memory Performance You can estimate the system’s virtual memory requirements on BSD systems by looking at the output of the top and/or ps commands. If you add up the values in the RSS columns (resident set size), you can get an idea of the real memory usage on the system. Adding up the values in the SZ column gives you an estimation of the VM requirements for the system. If the total of all SZ values increases over time (with the same jobs running), one or more applications probably have memory leaks. The system will eventually run out of swap space, and hang or crash. Some kernels allow you to modify the page scan/reclaim process. This allows you to alter how long a page stays in real memory before it is swapped or paged out. Such modifications are tricky, and should only be performed if you know what you are doing.

Memory Performance If you see that the scan rate (sr column in vmstat output) value is roughly equal to the free rate (fr column in vmstat output), the system is releasing pages as quickly as they are scanned. If you tune the memory scan parameters to increase the period between when the page is scanned and when it is paged out (allow pages to stay in memory for a longer period), the VM system performance may improve. On the other hand, if the sr value is greater than the fr value, decreasing the period between scan and paging time may improve VM system performance.

Memory Performance VM Symptoms
The following indicators may be useful when tuning the VM system. Paging activity may be an indicator of file system activity. Swapping activity is usually an indicator of large memory processes thrashing. Attaches and reclaim activity is often a symptom of a program in a loop performing a “file open, read, and close” operation. If the output of netstat –s shows a high error rate, the system may be kernel memory starved. This often leads to dropped packets, and memory allocation (malloc) failures.

Memory Performance Shared Memory
Large database applications often want to use shared memory for communications among the many modules that make up the database package. By sharing the memory, the application can avoid copying chunks of data from one routine to another, therefore improving system performance and maximizing the utilization of system resources. This generally works fine, until the application requests more shared memory than the system has available. When this situation occurs, system performance will often nosedive. Under Solaris, the /usr/bin/ipcs command may be used to monitor the status of the shared memory, and semaphore system.

Memory Performance mmap
If an application is running from a local file system, you might want to look into using the mmap utility to map open files into the system address space. The use of mmap replaces the open, malloc, and read cycles with much more efficient operation for read-only data. When the application is using network file systems, this might actually cause a degradation of system performance. Using the cachefs file system with NFS will improve this situation, as this allows the system to page to a local disk instead of through the network to an NFS disk.

Performance Analysis How can you improve the memory system? Add memory
It’s cheap Use limits they’re ugly payoff is not (usually) very good.

Performance Analysis Disk I/O is one of the most critical factors in system performance. Most file access goes through the disk I/O system. Multiple “hot” file systems on one disk will be a problem. Slow disks will be a problem Narrow controllers will be a problem Partitioning of disks will have an effect on buffering Disk geometry of disk will have an effect on buffering Swapping/paging goes through the disk I/O system. Split swap space over multiple spindles to increase interleave If swapping: Buy More Memory (It’s cheap) Use iostat to look at the disk I/O system.

Disk Performance Swapping
In general, if a system is swapping this is a symptom that it does not have enough physical memory. Add memory to the system to minimize the swapping/paging activity before continuing. You might also consider migrating some of the load to other systems in order to minimize contention for existing resources. If the system contains the maximum memory, and the system is still swapping, there are some things you can do to improve the performance of the swapping/paging subsystem. First, try to split the swap partitions across several disk drives and (if possible) disk controllers. Most current operating systems can interleave swap writes across several disks to improve performance. Adding controllers to the swap system can increase the bandwidth of the swap subsystem immensely.

Disk Performance Read/Modify/Write
One major problem for disk systems is the read/modify/write sequence of operations. This sequence is typical of updates to a file (read the file into memory, modify the file in memory, and then write the file out to disk). This sequence is a problem for (at least) the following reasons. There is a delay between the read and the write, so the heads have probably been repositioned to perform some other operation. The file size may change, requiring the new file to be written to non-contiguous sectors/cylinders on the disk. This causes more head movement when the file has to be written back to the disk.

Disk Performance It may seem simple to avoid or minimize such operations, but consider the following : A typical “make” operation might read in 50 include files. The compiler might create 400 object files for a large make operation. File system accesses require an inode lookup, a file system stat, a direct block read, an indirect block read, and a double-indirect block read to access a file. When the file is written to disk, the same operations are required.

Disk Performance When a database application needs to perform a data insert operation it needs to write the data to disk. It also needs to write the transaction to a log, and read/modify/write an index. Databases typically exhibit 50% updates, 20% inserts, and 30% lookups. This can lead to 200 (or more) I/O operations per second on medium-size databases! Trying to store such a database on a single disk is sure to fail. You would probably get by with a four-drive RAID for such applications, but a six- or eight-drive stripe would be a better bet for high performance.

Disk Performance File Servers
File servers should be delegated to providing one task: storing and retrieving files from system disks. Although this might seem like it should be a simple task, lack of planning when creating and populating file systems may cause severe performance problems. If a file server seems sluggish, use the iostat, vmstat, and other commands available on the system to monitor the disk subsystem. You need to determine which disks are experiencing large numbers of transfers, and/or large amounts of information read/written to disks.

Disk Performance Unbalanced Disks
Monitor the disk activity on an overloaded system to determine what file systems are being accessed most often. If most of the disk activity is centered on one disk drive, while other disk drives sit idle, you probably have an unbalanced disk system. A typical disk drive can handle (roughly) 50 I/O operations a second. If you are trying to perform 100 I/O operations/second to a single disk drive, system performance will suffer! If you see signs that one disk is being heavily accessed, while other disks sit idle, you might consider moving file systems in order to spread high-activity file systems across multiple disks. Place one high-activity file system on a disk drive with one or more low activity file systems. This minimizes head/arm movement, and improves the utilization of the on-drive and on-controller caches.

Disk Performance Unbalanced Disks
Too many hot file systems on a single disk drive/stripe is another typical problem. The tendency is to use all of the space available on the disk drives. Many times the administrator will partition a large disk into two (or more) file systems, and load files on all of the partitions. However, when all of the file systems begin to experience high volumes of access requests the disk head-positioner and the bandwidth of the disk drive become bottlenecks. It is usually better to waste some disk space and leave partitions empty than to place multiple active file systems on a drive. If you must do so, try to place inactive or read-only file systems on one partition, with an active read/write partition on another partition.

Disk Performance Another way to disperse file system load is to break up large multifunction file systems into smaller, more easily dispersed chunks. For example, the UNIX /usr file system often contains the system/site source code, system binaries, window system binaries, and print and mail spool files. By breaking the /usr file system into several smaller file systems, the sysadmin can disperse the load across the disk subsystem. Some of the more typical ways to break /usr into smaller chunks include making separate partitions for /usr/bin, /usr/lib, /usr/openwin, /usr/local, and /usr/spool.

Disk Performance RAID Some believe that by default RAID provides better performance than Single Large Expensive Disks (SLEDs). Others believe that RAID is only useful if you want a redundant, fault-tolerant disk system. In reality, RAID can provide both of these capabilities. However, a poorly configured RAID can also cause system performance and reliability degradation.

Disk Performance RAID Due to RAID’s flexibility and complexity, RAID subsystems present some tough challenges when it comes to performance monitoring and tuning. Most operating levels of RAID have well-known performance characteristics. Design your file systems such that high-performance file systems are housed on RAID volumes that provide the best performance (typically RAID 0). For improved reliability, RAID level 1, 4, or 5 would be a better choice. However, even within the RAID levels there are some general guidelines to keep in mind while designing RAID volumes.

Disk Performance Disk Stripes
One of the prime considerations for tuning RAID disk systems is “stripe size.” RAID allows you to “gang” several disks to form a “logical” disk drive. These logical drives allow you to attain better throughput, and large-capacity file systems. However, you need to be careful when you design these file systems.

Disk Performance Disk Stripes
The basic unit of storage on a standard disk is the disk sector (typically 512 bytes). On a RAID disk system, the basic unit of storage is referred to as the block size, which in reality is the sector size. However, RAID disks allow you to have multiple disks ganged such that you stripe the data across all disks. The number of disks in a RAID file system is referred to as the interleave factor, whereas the “stripe size” is the block size multiplied by the interleave factor. You typically want the size of an access to be a multiple of the stripe size.

Disk Performance Sequential I/O Optimizations
When using RAID, each disk I/O request will access every drive in the stripe in parallel. The block size of the RAID stripe is equal to the access size divided by the interleave factor. For example, a file server that contains a four-drive RAID array that allows 64-kilobyte file system accesses would be best served by reading/writing 16-kilobyte chunks of data to/from each in the array in parallel. A file server with an eight-disk stripe that allowed 8-kilobyte file system accesses should be tuned to read/write 1 kilobyte to/from each disk in the stripe. Such setups (RAID with a four- to eight-drive interleave) can provide a 3x to 4x improvement in I/O throughput compared to a single disk system.

Disk Performance Random I/O Optimizations
When using RAID for random I/O operations, you want each request to hit a different disk in the array. You want to force the I/O to be scattered across the available disk resources. In this case you want to tune the system such that the block size is equal to the access size. For example, a file server that allows 8-kilobyte file accesses across a six-disk RAID stripe should employ a 48-kilobyte stripe size, whereas a database server that allowed 2-kilobyte accesses across a four-drive RAID array should employ an 8-kilobyte stripe size.

Disk Performance File System Optimizations
The way an OS manages memory may also impact the performance of the I/O subsystem. For example, the BSD kernel allocates a portion of memory as a buffer pool for file system I/O, whereas System V kernels use main memory for file system I/O. Under System V, all file system input/output operations result in page-in/page-out memory transactions! This is much more efficient than the BSD buffer-pool model. You can tune the BSD kernel to use 50% of system memory as buffer pool to improve file system performance.

Disk Performance Disk-based File Systems
File systems stored on local disks are referred to as disk-based file systems (as opposed to network file systems, or memory-based file systems). There are several items related to disk-based file systems the administrator might want to tune to improve the performance of the system.

Disk Performance Zone Sectoring
Most modern disk drives employ zone-sectoring technology. This means that the drive has a larger number of storage sectors on the outer cylinders than it has on the inner cylinders; hence, the outer cylinders provide “more dense” storage than the inner cylinders. As the platter rotates, more sectors are under the read/write heads (per revolution) on the high-density cylinders than on the low-density cylinders. In many cases, two thirds of the disk’s storage space is on the outer (high-density) cylinders. This implies that you can attain higher performance if you just use the outer two-thirds of the disk drive, and “waste” one-third of the drive’s storage capacity.

Disk Performance Zone Sectoring Free Space
File systems should be sized with this constraint in mind. While wasting one-third of the storage capacity seems counterproductive, in reality system performance will be much better if you waste some space. Free Space Most modern file systems do not perform well when they are more than 90% filled. When the file system gets full, the system has to work harder to locate geographically “close” sectors on which to store the file. Fragmentation becomes a performance penalty, and read/modify/write operations become extremely painful, as the disk heads may have to traverse several cylinders to retrieve and then rewrite the file.

Disk Performance On user partitions (where the user’s files are stored) you can use the quota system to ensure that you never fill the file system to more than 90% capacity. This entails calculating how much space each user can have, and checking that you do not allow more total quota space than 90% of the total partition size. This can be a tedious process. More commonly, the sysadmin watches the file system, and if it approaches 90% full moves one or two of the space hogs to another partition.

Disk Performance Linux Ext3 Performance Options
The Ext2 file system has a reputation for being a rock-solid file system. The Ext3 file system builds on this base by adding journaling features. Ext3 allows you to choose from one of three journaling modes at file system mount time: data=writeback, data=ordered, and data=journal. To specify a journal mode, you can add the appropriate string (data=journal) to the options section of your /etc/fstab, or specify the –o data=journal command-line option when calling mount from the command line. To specify the data journaling method used for root file systems (data=ordered is the default), you can use a special kernel boot option called rootflags. To force the root file system into full data journaling mode, add rootflags=data=journal to the boot options.

Disk Performance data=writeback Mode
In data=writeback mode, Ext3 does not do any form of data journaling at all. In this mode, Ext3 provides journaling similar to that found in XFS file systems; that is, only the metadata is actually journaled. This could allow recently modified files to become corrupt in the event of an unexpected crash or reboot. Despite this drawback, data=writeback mode should give the best performance under most conditions.

Disk Performance data=ordered Mode
In data=ordered mode, Ext3 only journals metadata, but it logically groups metadata and data blocks into a single unit called a transaction. When it is time to write the new metadata out to disk, the associated data blocks are written first. The data=ordered mode solves the corruption problem found in data=writeback mode, and does so without requiring full data journaling. In general, data=ordered Ext3 file systems perform slightly slower than data=writeback file systems, but significantly faster than their full data journaling counterparts.

Disk Performance data=ordered Mode
When appending data to files, data=ordered mode provides all of the integrity guarantees offered by Ext3’s full data journaling mode. However, if part of a file is being overwritten and the system crashes, it is possible that the region being written will contain a combination of original blocks interspersed with updated blocks. This can happen because data=ordered provides no guarantees as to which blocks are overwritten first, and therefore you cannot assume that just because overwritten block x was updated that overwritten block x-1 was updated as well. Instead, data=ordered leaves the write ordering up to the hard drive’s write cache. In general, this limitation does not end up negatively impacting system integrity very often, in that file appends are usually much more common than file overwrites. For this reason, data=ordered mode is a good higher-performance replacement for full data journaling.

Disk Performance data=journal Mode
The Ext3 data=journal mode provides full data and metadata journaling. All new data is written to the journal first, and then to the disk. In the event of a crash, the journal can be replayed, bringing both data and metadata into a consistent state. Theoretically, data=journal mode is the slowest journaling mode, in that data gets written to disk twice rather than once. However, it turns out that in certain situations data=journal mode can be blazingly fast. Ext3’s data=journal mode is incredibly well suited to situations in which data needs to be read from and written to disk at the same time. Therefore, Ext3’s data=journal mode, assumed to be the slowest of all Ext3 modes in nearly all conditions, actually turns out to have a major performance advantage in busy environments for which interactive I/O performance needs to be maximized.

Disk Performance echo 40 0 0 0 60 300 60 0 0 > /proc/sys/vm/bdflush
TIP: On busy (Linux) NFS servers, the server may experience a huge storm of disk-write activity every 30 seconds when the kernel forces a sync operation. The following command will cause the system to run kupdate every 0.6 seconds rather than every 5 seconds. In addition, the command will cause the kernel to flush a dirty buffer after 3 seconds, rather than after the default of 30 seconds. echo > /proc/sys/vm/bdflush

Disk Performance BSD Disk System Performance
The Berkeley file system, when used on BSD-derived operating systems, also provides some methods for improving the performance of the file system. For file servers with memory to spare, it is possible to increase BUFCACHEPERCENT. That is, it is possible to increase the percentage of system RAM used as file system buffer space. To increase BUFCACHEPERCENT, add a line to the kernel configuration similar to the following. option BUFCACHEPERCENT=30 You can set the BUFCACHEPERCENT value as low as 5% (the default) or as high as 50%.

Disk Performance BSD Disk System Performance
Another method that can be used to speed up the file system is softupdates. One of the slowest operations in the traditional BSD file system is updating metainfo, which happens when applications create or delete files and directories. softupdates attempts to update metainfo in RAM instead of writing to the hard disk for every metainfo update. An effect of this is that the metainfo on disk should always be complete, although not always up to date.

Disk Performance Network File Systems
Network file systems are “at the mercy” of two bottlenecks: the disk system on the server and the network link between the server and the client. One way to improve performance of NFS file systems is to use the TCP protocol for transport instead of the UDP protocol. Some operating systems (Solaris, among others) have already made TCP their default transport for this reason. Another way to improve the performance of NFS is to increase the size of the data chunks sent and received. In NFS V1 and V2, the chunk size is 8 kilobytes. In NFS v3, the chunk size is up to 32 kilobytes.

Disk Performance cachefs
Another way to improve NFS performance is to use a client-side cache. By default, the NFS file system does not provide client-side caching. Allocating memory or disk space as a cache for network files can improve the performance of the client system at the cost of local disk space or memory for jobs. cachefs provides huge improvements for read-only (or “read-mostly”) file systems. A good size for the cachefs is 100 to 200 megabytes.

Performance Analysis Network I/O can be very critical in a heavily networked environment. NFS/AFS performance relies on the network performance. NFS is extremely dependent (no cache) Large transfer size (8k v3, 32 k v4) UDP implementation AFS is less dependent (has disk cache) Web servers are very network sensitive Lots of small transfers (input) Lots of larger transfers (output) Also disk system dependent. Use netstat to view network statistics. Use nfsstat to look at nfs statistics.

Performance Analysis How can you improve network I/O?
Change network connections to switched technology. Upgrade half duplex to full duplex Change to a faster network technology Upgrade 10 Mbit to 100 Mbit Ethernet. Fewer hosts on the network. Less traffic on critical links == more headroom. Faster network core. Off-site caching Particularly useful for web services Create dense request packets Use keepalives

Network Performance Trunking
Network adapters are engineered to provide specific bandwidth to the system. A 10-megabit Ethernet adapter will typically provide 6 to 10 megabits per second of bandwidth when operating in half-duplex mode. You can improve the performance of the network subsystem by configuring the adapter to operate in full duplex mode. But what do you do if you need 500 megabits of throughput from a database server to the corporate web server? Many vendors allow you to cluster multiple network interfaces to provide improved performance. By clustering interfaces, you can also provide redundancy, as the system will continue to operate, albeit at lower performance levels, if one interface fails. An example of trunking is the Sun Multipath package.

Network Performance Trunking Collisions
NOTE: Some applications seem to have problems working with systems using network trunking. At least one popular utility that allows UNIX servers to operate as Apple file/print servers experiences difficulties (and horrible performance) when used in a trunk environment! Collisions Anytime a packet is involved in a collision, network performance suffers. The damaged packet(s) will need to be retransmitted, adding load to an already overburdened network. Consider transitioning all connections to switched hardware. The switched hardware may still experience collisions, but usually at much lower rates than shared-mode hardware.

Network Performance TCP_NODELAY
Under most circumstances, TCP sends data when it is “handed” to the TCP stack. When outstanding data has not yet been acknowledged, TCP gathers small amounts of output to be sent in a single packet once an acknowledgment has been received. For a small number of clients, such as windowing systems that send a stream of mouse events that receive no replies, this process may cause significant delays. To circumvent this problem, TCP provides a socket-level option, TCP_NODELAY, which may be used to tune the operation of the TCP stack in regard to these delays. Enabling TCP_NODELAY can improve the performance of certain network communications.

Network Performance HIWAT/LOWAT
Most operating systems make certain assumptions about the type of network connection likely to be encountered. These assumptions are used to set the size and number of network buffers that can be used to hold inbound and outbound packets. Systems with several network interfaces, or systems that are connected to very high-speed networks, may realize an improvement in network performance by increasing the number of buffers available to the network stack. This is typically accomplished by tuning variables in the TCP stack. Under Solaris and HP-UX (among others), you can tune the number of buffers by setting the hiwat and lowat variables via the ndd command.

Common sense: Don’t overload the system.
Unix does not deal well when presented with overload conditions. The same is true for NT. ALWAYS keep at least 10% free space on disk partitions. Keep 35% free bandwidth on network links Eliminate swapping! Try to keep 30 to 50 % free cycles on CPU’s Don’t run accounting/quotas if your goal is peak performance. Run system scripts late at night (or other off-hours). Don’t run backups during peak hours.

Common Sense Watch for runaway jobs.
Users hate “killer” programs, but they do have their place! Watch for hardware problems that might aggravate problems Disk errors will cause the disk system to retry - this makes the system slower! Network errors require retransmission of packets – this makes the system slower! Slow (or speed mismatched) memory DIMMS may cause system to stall (wait states) – this makes the system slower! Try to run “native mode” programs Binary compatibility mode is slow Vmware and other “virtual environments” can be very slow Interpreted languages can be slow (sh code vs C code, compiled Java vs. Interpreted Java)

Common Sense Watch for stupid programmer tricks
Walking backward through arrays defeats cache Try to optimize loops such that critical data resides in cache. Sparse matrix operations can be avoided! Single character reads/writes defeat buffering User should read large blocks into a buffer in their code, then work from this buffer. File open/file close operations are slow Rabbit jobs Background processes Zombie processes

Summary System performance analysis and tuning is an iterative process. The sysadmin must use scientific methodology when attempting to tune a system’s performance.

An Introduction to System Administration

Similar presentations

Presentation on theme: "An Introduction to System Administration"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

An Introduction to System Administration

Similar presentations

Presentation on theme: "An Introduction to System Administration"— Presentation transcript:

Similar presentations

About project

Feedback