An Introduction to System Administration

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 CEOs 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 e-mail 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. 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.

Operating System Concepts 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. Operating System Concepts 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. Operating System Concepts 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. Operating System Concepts 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. Operating System Concepts UNIX systems refer to the Operating Systems 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. Operating System Concepts 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. Operating System Concepts 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. Operating System Concepts 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 vendors hardware this simple description is sufficient to make a choice of operating system. Operating System Concepts

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 Operating System Concepts 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. 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 http://perso.wanadoo.fr/levenez/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. 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. 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. 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).

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. 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. 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. 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.

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. 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) Moving Around the File Tree 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 pwd ls / dir

Change Directory Show current location List the files and directories Moving Around the File Tree 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 systems 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. 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. 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. 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.

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 e-mail 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 E-mail Most system administrators handle a large volume of e-mail 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. General-purpose GUI Tools 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. General-purpose GUI Tools 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. General-purpose GUI Tools 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

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. An Overview Of The Boot Sequence 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. An Overview Of The Boot Sequence

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 weve see the basic series of events that occur during the system boot process, lets 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 Sun PROM Monitor Sun PROM 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 Step 2: Boot Block The boot blocks job is to initialize some of the systems 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 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!

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-2.5.99 label = net test kernel restricted image = vmlinuz-stable label = stable kernel restricted other = /dev/hda3 label = Windows 2000 Professional

restricted table = /dev/hda GRUB # /etc/grub.conf generated by anaconda timeout=10 splashimage=(hd0,1)/grub/splash.xpm.gz password --md5 $1$pd$J08sMAcfyWW.C3soZpHkh. title Red Hat Linux (2.4.18-3custom) root (hd0,1) kernel /vmlinuz-2.4.18-3custom ro root=/dev/hda5 initrd /initrd-2.4.18-3.img title Red Hat Linux (2.4.18-3) Emergency kernel (no afs) root (hd0,1) kernel /vmlinuz-2.4.18-3 ro root=/dev/hda5 initrd /initrd-2.4.18-3.img

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. 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 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 grumpy% ls -lsa /etc/rc*.d/*afs* 2 lrwxrwxrwx 1 root other 15 May 31 2001 /etc/rc0.d/K66afs -> /etc/init.d/afs 2 lrwxrwxrwx 1 root other 15 May 31 2001 /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 ...2 2 2 2 2 2 2 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 181288 117 pages left 109 pages left 101 pages left 5 pages left 799 total pages, dump succeeded rebooting...

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. 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. Installing an Operating System 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. Installing an Operating System 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! Installing an Operating System 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. Installing an Operating System 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. Installing an Operating System 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. Installing an Operating System 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 revisionlevel 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. Types of Installations 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. Types of Installations 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 preconfigured repository.

Types of Installations Some of the more common problems encountered while installing Windows include: One or more network interfaces may not operate correctly. Generally, removing the adapters 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. Types of Installations 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. Types of Installations 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! Types of Installations 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! Types of Installations 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. Types of Installations 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.

Types of Installations 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. Types of Installations 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. Types of Installations 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 administrators 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.

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. Installation Methods ; Microsoft Windows 2000 Professional, Server, Advanced Server and Datacenter ; (c) 1994 - 1999 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 users hand throughout the installation process (much like Windows). 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. Suns WebStart and the Linux KickStart service are other

examples of the automated network-based installer. Because there is no official standard for these networkbased 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. 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:/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. 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 administrators 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. Users 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 straightforward. 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. Software Maintenance Concepts 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. Software Maintenance Concepts 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.

Software Maintenance Concepts 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. Software Package Management Tools 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. Software Package Management Tools 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. Software Package Management 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 shells 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 users execution path consider adding the needed setup information to the skeleton files used to create the users 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 users 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. Tracking and Distributing Packages and Patches Another approach is to make use of the software package management tools 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. Tracking and Distributing Packages and Patches 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 systems 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 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). 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. UNIX Device Terminology 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. UNIX Device Terminology 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. Problems with the UNIX view Whereas UNIX likes to view everything as a file, some device operations defy the designers 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. Windows Device Tree 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 devicespecial 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.

Solaris Device Tree 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-toremember 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 systems 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. 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 /devices/[email protected],f8000000/[email protected] 0,800000/[email protected],0:a,raw. A Solaris alphabet soup name for a device consists of four fields: Controller (CN), Target (TN), Device (DN), and Slice (SN). 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 4.1.3 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.

Device Linux (/dev/) Solaris (/dev/) BSD (/dev/) da# Disk (SCSI/ RAID) Disk (IDE) Tape sdLP; dsk/cWtXdYsZ; ida/cWdXpZ sd#{a-h}

/dev/hdLP dsk/cWtXdYsZ; dad#{a-h} st# rmt/# Ethernet eth# hme#; eri# le# Video Display

Keyboard fb fbs/ffb vga# keyboard kbd atkbd# Mouse

mouse mouse psm# Diskette floppy diskette fd# CD-ROM

scd# acd# Console Port (serial) Serial Port cons; ttyS# dsk/cWt6dYsZ; cdrom term/a tty#

term/a tty# Printer Port Ecppp0; Bppp0 bpp0; ecpp0 lpt wd# st#

ttyd# 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, /devices/[email protected],4000/[email protected]/[email protected],0:a /[email protected],f8000000/[email protected],4000/[email protected],0:a To list the hardware on a Solaris box, use the PROM monitors 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 manufacturers 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 devices 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 /[email protected],0/[email protected],1/[email protected]/[email protected],0:g into the following components. /[email protected] - Device is connected to a PCI adapter. 1f,0 - An address on the on-board bus. [email protected] - A pci interface is the on-board pci adapter. 1,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 .

[email protected] - An IDE adapter connected to the PCI. 3 - The IDE adapters address offset from the pci bus adapter. [email protected] - 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.

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. 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. Adding Solaris Devices A more dangerous way of reconfiguring the system on the fly is to execute the drvconfig, disks, tapes, and dev links 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 systems 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 zeros 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 heads 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 its 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

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 dont mix different types of SCSI devices together: Performance might suffer! Physical damage may result! Errors will be difficult to track down SCSI

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. Dont 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! Thats a LIE. They do have headers, we just cant 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 == 330752 sectors

The disk can store how many bytes of data? 330752 * 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 isnt the first one on cylinder 45, so we have to determine which surface it is on: 14,560 - 14,535 ==> Our sector is 25 sectors after the start of cylinder 45 45 / 17 > 2 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 its 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 OSs 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 SCSI Disk Formatting (SCSI) 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 drivesuse it whenever possible! When it isnt 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 SCSI Disk Formatting (SCSI) 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. SCSI SCSI Disk Formatting (SCSI) 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. # Data file for the 'format' program. This file defines the known # disks, disk types, and partition maps. # # This is the list of Sun supported disks for embedded SCSI. # disk_type = "SUN2.1G" \

: ctlr = SCSI : fmt_time = 4 \ : ncyl = 2733 : acyl = 2 : pcyl = 3500 : nhead = 19 : nsect = 80 \ : rpm = 5400 : bpt = 44823 disk_type = "SUN4.2G" \ : ctlr = SCSI : fmt_time = 4 \ : ncyl = 3880 : acyl = 2 : pcyl = 3500 : nhead = 16 : nsect = 135 \ : rpm = 7200 # # This is the list of partition tables for the embedded SCSI controllers. # partition = "SUN2.1G" \ : disk = "SUN2.1G" : ctlr = SCSI \ : 0 = 0, 62320 : 1 = 41, 197600 : 2 = 0, 4154160 : 6 = 171, 3894240 partition = "SUN4.2G" \ : disk = "SUN2.9G" : ctlr = SCSI \ : 0 = 0, 390852 : 1 = 180, 781704 : 2 = 0, 11367972 : 6 = 454, 1019541

SCSI Disk Formatting (SCSI) 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. Disk Subsystem

Load Balancing 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. Disk Subsystem Load Balancing Disks 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 0 + 1 implements a mirrored striped array. This allows for data redundancy and improved throughput. Disk Subsystem Load Balancing Disks 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 Disk Subsystem Load Balancing Disks Hardware solutions arent 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. 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 drives 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 strippeddown 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 clientsystem data transfers. The systems network interfaces are used for normal data communication traffic, such as web browsing, e-mail, 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 softwarebased 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 GUIbased 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 8.3 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 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 listedufs, hsfs, pcfs, nfs, and tmpfsare 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. 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 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

UNIX File systems The array of 15 disk blocks stored in the inode point to the data blocks that store the files 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.

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 partitions 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 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. 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.

Working with the newfs Command 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 netnews 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 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 /proc fd swap /dev/dsk/c0t3d0s0 /dev/dsk/c0t3d0s6 /dev/dsk/c0t3d0s5 /dev/dsk/c0t3d0s1 /dev/dsk/c1t3d0s1

device mount to fsck point /proc /dev/fd /tmp /dev/rdsk/c0t3d0s0 / /dev/rdsk/c0t3d0s6 /usr /dev/rdsk/c0t3d0s5/opt - FS type

proc fd tmpfs ufs ufs ufs swap swap fsck pass 1 2 5 -

mount at boot no no yes no no yes no no mount options - 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 [email protected] 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 http://www.cwi.nl/~mdejonge/software/usermount/. 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): 11690 blocks 9292 files /usr

(/dev/dsk/c0t3d0s6): 786776 blocks 322309 files /tmp (swap): 218816 blocks 3288 files /opt (/dev/dsk/c0t3d0s5): 91236 blocks 73801 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 /dev/dsk/c0t3d0s020664 used avail capacity Mounted on 14819

3785 80% / 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 11690 free blocks 7570 available 11520 total files 9292 free files 8388632 filesys id

ufs fstype 0x00000004 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=800018 869622929 /dev/dsk/c0t3d0s6 /usr ufs rw,suid,dev=80001e 869622929 /proc /proc proc rw,suid,dev=2740000 869622929 fd /dev/fd fd rw,suid,dev=27c0000 869622929 /dev/dsk/c0t1d0s6 /var ufs rw,suid,dev=80000e 869622929 swap /tmp tmpfs dev=0 869622932 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:45 2000 /usr on /dev/dsk/c0t3d0s6 read/write/setuid on Sat Apr 1 1:23:45 2000 /proc on /proc read/write/setuid on Sat Apr 1 1:23:45 2000 /dev/fd on fd read/write/setuid on Sat Apr 1 1:23:45 2000 /tmp on swap read/write on Sat Apr 1 1:23:45 2000 /opt on /dev/dsk/c0t3d0s5 setuid/read/write on Sat Apr 1 1:23:45 2000

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. CDROMs 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 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. 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 Serial Ports Serial ports use standard pin-outs for the connectors. The most common of these standard is known as RS232. 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. Serial Ports Serial Ports 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 Pin 1 2 3 4 5 6 7

8 9 10 11 12 13 Name FG TD RD RTS CTS DSR SG DCD

SDCD SCTS Function Frame Ground Transmit Data Receive Data Request To Send Clear To Send Data Set Ready Signal Ground Data Carrier Detect + voltage - voltage Secondary DCD

Secondary CTS Pin 14 15 17 18 19 20 21 22 24 25 Name STD

TC SRD RC Function Secondary TD Transmit Clock Secondary RD Receive Clock SRTS DTR SQ RI DRS SCTE

Busy Secondary RTS Data Terminal Ready Signal Quality Ring Indicate Data Rate Selector Clock Transmit External Busy 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. 4-pin connection 1 ------- 1

2 ------- 2 3 ------- 3 7 ------- 7 Frame Ground Transmit Data Receive Data Signal Ground Serial Ports Devices which provide for limited modem control use 9 pin connections. 9-pin connection DB9 DB25 1 ------- 20 Data Terminal Ready

2 ------- 2 Transmit Data 3 ------- 3 Receive Data 4 ------- 8 Data Carrier Detect 5 ------- 7 Signal Ground 6 ------- 6 Data Set Ready 7 ------- 5 Clear To Send 8 ------- 4 Request To Send Serial Ports Hardwired connections generally use a straightthrough connection. Straight-Through Connection 1 ------- 1 Frame Ground 2 ------- 2 Transmit Data 3 ------- 3 Receive Data 4 ------- 4 Request To Send

5 ------- 5 Clear To Send 6 ------- 6 Data Set Ready 7 ------- 7 Signal Ground 8 ------- 8 Data Ca rrier Detect 20 ----- 20 Data Terminal Ready 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 its own modem control signals. Null Modem Connection 1 ------- 1 Frame Ground 2 ------- 3 Transmit Data

3 ------- 2 Receive Data 4 ------- 5 Request To Send 5 ------- 4 Clear To Send 6,8 ---- 20 Connect DSR/DCD to DTR 7 ------- 7 Signal Ground 20 ----- 6,8 Connect DTR to DSR/DCD Serial Ports Some manufacturers have come out with alternate connectors for use with RS-232 connections: Apple uses a Mini-Din 8 connector, PCs 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. Serial Ports Serial Ports 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 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 wyse50on 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 tty11 9600 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 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. Serial Ports Managing Terminals 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. Serial Ports Managing Terminals 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 its own environment and

start any processes required to enable the login process. Serial Ports Managing Terminals 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 Serial Ports Managing Terminals 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 -a -c cmd -d -e -g -G -k -l -L -n count -p pmtag -r -s -t type

-v ver -x -y Comment -z script Add a port monitor Execute the command string cmd Disable the port monitor pmtag d Do not enable the new port monitor x Do not start the new port monitor request output or modify /etc/saf/pmtag/_config request output or modify /etc/saf/_sysconfig Stop port monitor pmtag is used to request port monitor information same as -l except use condensed format output Set the restart count to count

Specifies the tag associated with a port monitor Remove port monitor pmtag Start a port monitor pmtag Specifies the port monitor type Specifies the version number of the port monitor Tells the SAC to read its database file (_sactab) Include comment in the _sactab entry for port monitor pmtag With -g / -G to specifies location of configuration script Serial Ports Managing Terminals 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.

Serial Ports Managing Terminals 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

Serial Ports Managing Terminals 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! Serial Ports Managing Terminals 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. Serial Ports Managing Terminals 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) Serial Ports Managing Terminals 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 , so you have to use 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 its 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 its 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=5551212:tc=dial9600 monet:[email protected]:tc=dial9600

The /etc/phones file contains entries of the form: monet cc 8,,510,555-4567,,,,xxxx-xxx 5552530 Modems Managing Modems 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:

Modems Managing Modems 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 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 servers 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 users 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 Computers 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: http://www.stokely.com/unix.port.resources/tutorials.html 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 UIDs Each user must have a unique user-id. Most Unix systems use integers in the range of 0 65536. Are there special (reserved) userids? What happens at a large company/university where there are more than 65536 employees? Are UIDs reused? For example, if an employee leaves the company, is their userid assigned to the next person hired in? Users Users - background information 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 Users Users - background information 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 Users Users - background information 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 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 UIDs. 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 users 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 users 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 users 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 persons 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 cant 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 wouldnt 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: 1. Dont 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 theyre on-line. Reasonable security can be attained using compress and crypt on sensitive files. 2. 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.

System Security Seven common sense rules of security: 3. Dont 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. System Security Seven common sense rules of security:

4. 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. 5. 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. System Security Seven common sense rules of security: 6. 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. Theyll explain that for only $50K they can make your site secure. 7. 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. System Security Account Security 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. System Security Account Security 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 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 dont 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 dont 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 decrypt 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 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. System Security Viruses 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. System Security Viruses 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:

System Security PC Viruses 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).

System Security PC Viruses 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). System Security

PC Viruses 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.

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. 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. Mounting File Systems 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 #to mount to fsck /proc fd swap /dev/dsk/c0t3d0s0 /dev/dsk/c0t3d0s6 /dev/dsk/c0t3d0s5 /dev/dsk/c0t3d0s1 /dev/dsk/c1t3d0s1

mount FS point type /proc proc /dev/fd fd /tmp tmpfs /dev/rdsk/c0t3d0s0 / /dev/rdsk/c0t3d0s6 /usr /dev/rdsk/c0t3d0s5 /opt - fsck pass

ufs ufs ufs swap swap mount at boot no no yes 1 2 5 -

mount options no no yes no no - 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 [email protected]

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 http://www.cwi.nl/~mdejonge/software/usermount/. 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): 11690 blocks 9292 files /usr (/dev/dsk/c0t3d0s6): 786776 blocks 322309 files /tmp (swap): 218816 blocks 3288 files /opt (/dev/dsk/c0t3d0s5):

91236 blocks 73801 files 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=800018 869622929 /dev/dsk/c0t3d0s6 /usr ufs rw,suid,dev=80001e 869622929 /proc /proc proc rw,suid,dev=2740000 869622929 fd /dev/fd fd rw,suid,dev=27c0000 869622929

/dev/dsk/c0t1d0s6 /var ufs rw,suid,dev=80000e 869622929 swap /tmp tmpfs dev=0 869622932 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:45 2000

/usr on /dev/dsk/c0t3d0s6 read/write/setuid on Sat Apr 1 1:23:45 2000 /proc on /proc read/write/setuid on Sat Apr 1 1:23:45 2000 /dev/fd on fd read/write/setuid on Sat Apr 1 1:23:45 2000 /tmp on swap read/write on Sat Apr 1 1:23:45 2000 /opt on /dev/dsk/c0t3d0s5 setuid/read/write on Sat Apr 1 1:23:45 2000 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 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. 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

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 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. 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. 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. 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.

Recognizing Failing Disks 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. Recognizing Failing Disks 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 systems 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. 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! Improving Disk Subsystem Performance

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.

Improving Disk Subsystem Performance 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. Improving Disk Subsystem Performance 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 files data blocks close together on the disk. When a large file is split over two or more cylinder groups, the files 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. Improving Disk Subsystem Performance 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.

Improving Disk Subsystem Performance 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. 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 administrators 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. 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 Strategy and Scheduling 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 Backup Strategy and Scheduling 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 Week 1 Tape Level Weeks 2, 3, 4 Level

Su A 0 H 3 M B 5 Tu C

5 W D 5 Th E 5 F F 5 Sa G

5 5 5 5 5 5 5 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 Mondays 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. Backup Strategy and Scheduling 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 Week 1 Tape A Level

0 Week 2 Tape H Level 5 Week 3 Tape H Level 5 Week 4 Tape H Level 5 Week 5 L Level 0 Week 6 Tape H Level

5 Week 7 Tape H Level 5 Week 8 Tape H Level 5 Week 9 Tape A Level 0 M B 5 Tu

C 5 W D 5 Th E 5 F F 5 Sa

G 3 I 3 J 3 K 3 M 3 G 3 I 3 J 3

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 months 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.

Backup Strategy and Scheduling 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 sevenday 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.

Week 1 Tape Level Week 2 Tape Level Week 3 Tape Level Week 4 Tape Level Week 5 Level Week 6 Tape Level Week 7 Tape Level Week 8 Tape Level

Week 9 Tape Level Su E 0 A 5 B 4 A 5 C 3 A 5

B 4 A 5 D 1 M A 5 D 1 A 5 B 4

A 5 C 3 A 5 B 4 A 5 Tu B 4 A 5

E 0 A 5 B 4 A 5 C 3 A 5 B 4 W

A 5 B 4 A 5 D 1 A 5 B 4 A 5 C 3

Th C 3 A 5 B 4 A 5 E 0 A 5 B 4

A 5 F A 5 C 3 A 5 B 4 A 5 D 1

A 5 B 4 Sa B 4 A 5 C 3 A 5 B 4

A 5 E 0 A 5 Backup Strategy and Scheduling 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 days 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 Week 1 Tape Level Week 2 Tape Level

Week 3 Tape Level Week 4 Tape Level M A 0 F 5 F 5 F 5 Tu

B 5 B 5 B 5 B 5 W C 5 C 5 C 5

C 5 Th D 5 D 5 D 5 D 5 F E 3

E 3 E 3 E 3 Sa 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 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. 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 highend 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 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 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-ROMs 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 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 largescale systems. However, disk drives are much more expensive than tapes.

Disk backups also consume large amounts of system resources. For example, you would need 100 2-Gb disks to back up 100 2Gb 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.

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 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. 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. Unix Backup Commands Example restore Commands # restore rbf 50 /dev/rmt/0 /dev/rdsk/c0t2d0s2 Unix Backup Commands

# restore ibf 50 /dev/rmt/0 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. 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, sub stituting the appropriate directory and device names. # dump 0f - /dev/rdsk/c0t2d0s2 | (rsh machine ; cd

/home;restore xf -) 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.

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-andrestore 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.

Windows Backup Commands 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. Windows Backup Commands 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 thirdparty 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? Dealing with Specific Backup Issues 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. Dealing with Specific Backup Issues 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 devices name at the prompt. Dealing with Specific Backup Issues 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 50 54000 /dev/nst0 /dev/ida/c0d1p2 dump 0bdfu 50 54000 /dev/nst0 /dev/ida/c0d2p1

dump 0bdfu 50 54000 /dev/nst0 /dev/ida/c0d3p1 dump 0bdfu 50 54000 /dev/nst0 /dev/ida/c0d4p1 dump 0bdfu 50 54000 /dev/nst0 /dev/ida/c0d5p1 dump 0bdfu 50 54000 /dev/nst0 /dev/ida/c0d1p3 mt -f /dev/nst0 rewind mt -f /dev/nst0 offline # sh -x /dodump Cross Platform Backups Several utilities are available for cross-platform backups: Veritas Legato Networker RaxCo Amanda free http://www.amanda.org/ 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. 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.

Printing Printer Setup (BSD) 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.

Printing Printer Setup (BSD) 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 machines 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:\ :sh:\ :ml=0:\ :mx=0:\ :sd=/var/spool/lpd/lj254-color:\ :af=/var/spool/lpd/lj254-color/lj254-color.acct:\ :lp=|/usr/share/printconf/util/jetdirectprint:\ :lpd_bounce=true:\ :if=/usr/share/printconf/util/mf_wrapper: 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. Printing Printer Setup (System V) 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. Printing Printer Setup (System V)

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) Printing Printer and Print Job Management (System V) 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 Printing Printer and Print Job Management (System V) 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) lpstat comes with a bag full of options: -a [list] -c [list] -d -f [list] [-l] -o [list] -p [list] [-D] [-l]

-P -r -R -s -S [list] [-l] -t -u [login-ID-list] -v [list] Reports which print destinations are accepting requests. Report status of all classes and their members. Report status of the system default destination. Verify [list] the forms recognized by LP print service. Report status of output requests. Report status of printers [description] [capabilities]. Report paper types.

Report the status of the LP request scheduler. Report the position of each job in the print queue. Report a status summary. Verify the character sets / print wheels. Report all status information. Report status of output requests for users. Report printer names and devices. 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 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! Windows Printing

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 realworld 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, Network Protocols (TCP/IP) Network Protocols (TCP/IP) 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.

Network Protocols (TCP/IP) Internet Protocol (Packets) As a packet travels through the levels of the TCP/IP protocol, each layer adds its own header information to the datagram. This process of each layer encoding its 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.

Network Protocols (TCP/IP) Internet Protocol Version 4 (IPv4) An IP address consists of four byte values separated by periods. For Example: 123.45.67.89 This notation is also known as the dotted quad format. Each of the values must be in the range of 0 - 255 (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. Network Protocols (TCP/IP) Internet Protocol (IPv4)

Class A Networks - The first byte is in the range of 1 - 127. 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. 110 .32.4.18 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)! Network Protocols (TCP/IP)

Internet Protocol (IPv4) Class B Networks - The first byte in the range of 128 - 191. 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. 129.74. 25.98 network host address Each Class B network can address up to 65,000 hosts. Notre Dame holds a Class B license (129.74.X.Y) All Class B networks are currently assigned and in use. (lie)!

Network Protocols (TCP/IP) Internet Protocol (IPv4) Class C Networks - The first byte in the range of 192 - 223. The first four bits of the address are 1 1 0 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. 210.43.2 .8 network host address Each Class C network can address up to 254 hosts. Most of the Class C networks are assigned and in use.

Network Protocols (TCP/IP) Internet Protocol (IPv4) Class D Networks - The first byte in the range of 224 - 239. The first four bits of the address are 1 1 1 0 These addresses are used for one to many communications (multicasting). Class E Networks - The first byte in the range of 240 - 254. The first four bits of the address are 1 1 1 1 These addresses are reserved for experimental use by the IANA/IETF. Network Protocols (TCP/IP) The numbers 0, and 255 have special meaning in some fields of IP addresses. A Zero host address refers to this network

For example 129.74.0.0 refers to the Class B network 129.74. A host address of all ones is called the broadcast address. For example 129.74.255.255 refers to all hosts on the 129.74 Class B network. The address 127.0.0.1 is the loopback address. This address is used for inter-process communications, and for network testing. All of the 127 network is reserved (127.0.0.0 127.255.255.255). Network Protocols (TCP/IP) 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 255.0.0.0 Standard netmask for Class B is 255.255.0.0 Standard netmask for Class C is 255.255.255.0 By logically ANDING the address and the netmask, we can determine the NETWORK portion of the address. Network Protocols (TCP/IP) 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 255.0.0.0 Class B netmask is 255.255.0.0 Class C netmask is 255.255.255.0 For example, a packet bound from a random host on the Internet, to my office host would generate the following operation: 129.74.25.98 = 10000001 . 01001010 . 00011001 . 01100010 255.255.0.0 = 11111111 . 11111111 . 00000000 . 00000000

10000001 . 01001010 . 00000000 . 00000000 == 129.74.0.0 or 129.74/16 Network Protocols (TCP/IP) The lab 129.74.46 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. 11111111 . 11111111 . 11111111 . 11100000 27 bits of network address, 5 bits of host address.

129.74.46.0 through 129.74.46.31 is one such network. 129.74.46.32 through 129.74.46.63 is one such network. 129.74.46.64 through 129.74.46.95 is one such network. 129.74.46.32/27 denotes a host on a classless network which employs a 27 bit netmask. This is referred to as Classless InterDomain Routing (CIDR) Network Protocols (TCP/IP) 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: 203.14.7.0 = 11001011 00001110 00000111 00000000 203.14.6.0 = 11001011 00001110 00000110 00000000 The first 23 bits are the same for both addresses so the ISP can advertise a single external route: 203.14.6/23 This only works if the ISP also owns 203.14.4.0 and 203.14.5.0. Network Protocols (TCP/IP) 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. Network Protocols (TCP/IP) 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). Network Protocols (TCP/IP) 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:222.33.44.55 Shorthand ::FFFF:222.33.44.55 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 zeros after it Network Protocols (TCP/IP) 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). Network Protocols (TCP/IP) 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, Im 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. Network Protocols (TCP/IP) 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 hosts 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) Network Protocols (TCP/IP) Net to Device -----hme0 hme0 hme0 hme0 hme0 hme0

hme0 hme0 hme0 hme0 hme0 hme0 Media Table IP Address Mask -------------------- --------------morticia.cse.nd.edu 255.255.255.255 wizard.cse.nd.edu 255.255.255.255 penny.helios.nd.edu 255.255.255.255 banzai.helios.nd.edu 255.255.255.255 bind.nd.edu

255.255.255.255 buckaroo.helios.nd 255.255.255.255 john.helios.nd.edu 255.255.255.255 authors.helios.nd.ed 255.255.255.255 lizardo.helios.nd.ed 255.255.255.255 hub25-1a.hub.nd.edu 255.255.255.255 grumpy.cse.nd.edu 255.255.255.255 BASE-ADDRESS.MCAST.NET 240.0.0.0 Flags Phys Addr ----- --------------00:05:02:20:dd:ba 08:00:20:10:0c:6a 00:60:2f:88:da:63 00:60:2f:88:da:63 00:60:2f:88:da:63

00:60:2f:88:da:63 00:60:2f:88:da:63 00:60:2f:88:da:63 00:60:2f:88:da:63 08:00:44:0c:17:7d SP 08:00:20:7e:80:69 SM 01:00:5e:00:00:00 Network Protocols (TCP/IP) 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. Network Protocols (TCP/IP) 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 namesthe 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!, Im 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. Im 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, PCs UNIX hosts. Other Protocols EtherTalk Actually AppleTalk over Ethernet. Two flavors are available: Phase 1 was Apples first Ethernet network. It was very buggy, and tended to flood the network with

broadcast packets. Phase 1 also had its 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 Apples 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 Bobs 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 PCs. 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 nonIPX 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 (NLMs) are available to add functionality to Novell IPX based networks. Other Protocols IPX

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 1974. 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 Digitals Network Services Protocol (NSP). Other Protocols DECnet 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 machines address is derived from the area and node number, not the hardware MAC address. All interfaces on the system use the same address! Other Protocols DECnet 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 weve 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 Working With Current Network Hardware 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 - 622 Mb / second throughput).

Network Hardware Working With Current Network Hardware 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. Network Hardware Working With Current Network Hardware Ethernet - developed by Xerox in the 1970s. 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. Network Hardware Working With Current Network Hardware There are many flavors of Ethernet available: 802.5 - 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 Network Hardware Working With Current Network Hardware 802.2 - 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 Network Hardware Working With Current Network Hardware 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. Network Hardware Working With Current Network Hardware

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 Network Hardware Working With Current Network Hardware 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 Network Hardware Working With Current Network Hardware 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. Network Hardware Working With Current Network Hardware 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. Network Hardware Working With Current Network Hardware 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. Network Hardware Working With Current Network Hardware 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! Network Hardware

Working With Current Network Hardware 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. Network Hardware

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. Network Hardware Working With Current Network Hardware

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 multiplechannel 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. Network Hardware Working With Current Network Hardware 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 1.544 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). Network Hardware Working With Current Network Hardware 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 64 - 1500 byte packets FDDI exchanges 64 - 4500 byte packets ATM exchanges 53 byte cells Each cell has a 5 byte header and 48 data bytes. Network Hardware Working With Current Network Hardware 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 administrators 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 hosts 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 (127.0.0.1) 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 addressFully.Qualified.Name[host_alias]* 192.168.44.55 grumpy.plc.com grumpy loghost 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. 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. 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. 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

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 hosts 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]

Host Configuration The destination field contains the IP address of the routes destination. This could be a host address (for example, 172.16.33.44) or a network address (for example, 192.168.10.0), 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 0.0.0.0 may also be used in place of the string default. Packets bound for a destination that does not have an explicit route in the

hosts 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

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 todays UNIX hosts. Host Configuration Solaris

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. 172.16.205.97 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 172.16.205.97 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 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.

172.16.0.0 172.16.70.64 172.16.46.32 172.16.46.48 172.16.46.64 255.255.0.0 255.255.255.224 255.255.255.240 255.255.255.240 255.255.255.224 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 127 # # Internet networks # arpanet 10 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 nonpersistent 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 317013 daemon.notice] ftp[13370] from 172.16.25.96 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 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. Host Configuration Multi-homed Hosts

Hosts with network interfaces on several networks are referred to as multihomed 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 dont 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 autosense 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 ; 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 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 /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=172.16.205.97 # 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="172.16.205.99" # Hosts static IP address NETWORK=172.16.205.96 # The network number BROADCAST=172.16.205.127 # The broadcast address

NETMASK="255.255.255.240" # The netmask ONBOOT="yes" # yes to configure at boot Host Configuration The ifup 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 script reads the interface files and parses the entries.

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. Host Configuration HPUX

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]=lan0 ROUTE_DESTINATION[0]=default ROUTE_MASK[0]=255.255.255.240 ROUTE_GATEWAY[0]=172.16.46.33 ROUTE_COUNT=1 IP_ADDRESS[0]=172.16.46.40 SUBNET_MASK[0]=255.255.255.240 INTERFACE_NAME[1]=snap1 ROUTE_GATEWAY[1]=172.16.70.33 IP_ADDRESS[1]=172.16.70.40 SUBNET_MASK[1]=255.255.255.240 GATED=0

# Ethernet link layer encapsulation # could also be net or host # 802.3 link layer encapsulation # set to 1 to enable gated Host Configuration

HPUX Network Utilities In addition to the rc.config.d/netconf file, HPUX provides a few utilities that provide information about the systems 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 AIXs 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 systems fully qualified domain name. This is used to locate the systems 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 172.16.205.0 network, and the other connects to the 192.168.1.128 network (with a subnet mask of 255.255.255.128). network_interfaces=xl0 xl1 lo0 hostname=poncho ifconfig_xl0=172.16.205.198 ifconfig_xl1=192.168.1.188 defaultrouter=172.16.205.254 static_routes=backbone private route_backbone=-net 172.16.205.0

route_private=-net 192.168.1.128 netmask 255.255.255.128 Host Configuration MacOS X 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 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 : Windows domain controller for this host #BEGIN_ALTERNATE: Used to group include statements

#END_ALTERNATE: Used to mark end of grouped include statements #INCLUDE : 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. 172.16.205.101 172.16.205.102 172.16.205.103 172.16.205.104 happy sleepy dopey

doc #PRE #DOM plc Host Configuration Configuration Programs 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 hosts 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 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 programs operation, but such customizations are usually not required. Lease information is stored in the /etc/dhclient.leases file. Host Configuration MacOS X 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. 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 255.255.255.255. 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 255.255.255.255 host, enter the following command (assuming your network device is eth0).

route add -host 255.255.255.255 dev eth0 If you get the message 255.255.255.255: Unknown host, add the following entry to the /etc/hosts file. 255.255.255.255 all-ones 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 172.16.1.199 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 172.16.1.199;

} 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=172.16.40.50 no=30 sm=255.255.0.0 hn=hpdhcpserver## This command defines the range of addresses to be used by defining the starting address (fip=172.16.40.50), 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.

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. *.alert;*.crit;*.err;*.warning;kern.notice;auth.notice @grumpy.plc.com 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. 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 workstations kernel and forwards it to the management station. 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. Host Configuration SNMP Under Linux 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. 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) 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 Microsystems 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. Suns 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 Hewlett-Packards 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 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 thirdparty sniffer called tcpdump. However, because Solaris and HPUX do not include this application, lets examine the snoop (Solaris) and nettl (HPUX) packet sniffers. Host Configuration snoop Solaris ships with Suns 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 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 99999 packets to the file /tmp/raw0. 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 http://www.tcpdump.org 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. 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 its 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.

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.

Missing or damaged terminators Broken or damaged cable (may not be visible) Faulty connectors Damaged transceiver (may be jamming the network) 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 Years Eve, the security of one sysadmins 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 Actions that might be considered hostile are not welcome. Such actions might include (but not be limited to) the use of network sniffers, abusive email, denial-of-service attacks, visiting certain types of web sites from corporate hosts, perusing other users files

or e-mail without permission, forging e-mail, 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 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 administrators 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: http://www.securityfocus.org/ 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, lets 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 http://csrc.nist.gov/publications/ nistpubs/800-30/sp800-30.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 elses 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 elses e-mail as it goes by

on the network, or reading user files because they are improperly protected, might be considered theft of data. Threats 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 administrators 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 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 hosts 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. 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 (e-mail), 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 administrators 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 sites 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 elses 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, e-mail 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. System Security Analysis 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. System Security Analysis 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. System Security Analysis 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. System Security Analysis 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 http://www.entercept.com/ System Security Analysis 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 System Security Analysis 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 http://www.cerias.purdue.edu/

System Security Analysis 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 http://www.cisecurity.org/ The CIS site also contains tools for checking your system for the SANS Top 20 security problems. System Security Analysis 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 http://www.sun.com/security/jass System Security Analysis 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 http://www.insecure.org/ System Security Analysis 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 http://www.nessus.org/ System Security Analysis Saint The Security Administrators 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 http://www.saintcorporation.com/saint/

System Security Analysis 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).

System Security Analysis 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 http://www.chkrootkit.org/ Defenses Network Services 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 http:// www2.lysator.liu.se/~pen/pidentd/ Defenses

Other Unnecessary Services Each operating system ships with a number of inet services that may not be needed. Services often disabled include :

tnamed, uucp, exec, rexd, comsat, finger, systat, netstat, time, sadmind, linuxconf,

rquotad, rpc.rusersd, sprayd, walld, rpc.statd, ufsd, cachefsd,

kerbd, gssd, and in.talkd. 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 cant 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 users 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:00000000 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 sites 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. 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.. 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 daemons 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

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 insecurehost.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: 172.16.0.0/255.255.0.0 rpcbind: 255.255.255.255 0.0.0.0 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 172.16.0.0 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 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 systems 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. 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 http://www.openssh.org/ 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 e-mail encryption tools. The PGP vendor (Network Associates) recently decided to discontinue distribution of its commercial version of PGP. Freeware versions remain available at http://www.pgpi.org/ 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 http://www.gnupg.org/ 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 http://www.winton.org.uk/zebedee

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 http://www.stunnel.org/ 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 users password. The sysadmin needs to replace the systems 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 http://srp.stanford.edu/

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.. 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 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.

Classification of Firewalls Firewalls Stateful Filters 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 systems 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 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, e-mail, 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 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 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 systems 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 hosts 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 TIP: An easy-to-use interface to ip chains, called brickhouse, is available for MacOS X. See http://personalpages.tds.net/~brian_hill/brickhouse.html 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, e-mail, ASP, and macro viruses. The tiny tools are available at http://www/tinysoftware.com/ 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 firewalls 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 10.2.3.4, 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 systems 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 todays 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 Ill 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 senders address was forged, so the reply packets (tens of thousands of them) all went to an unsuspecting target. For example, ping 172.16.255.255 would have caused all hosts on the 172.16.0.0 network to reply. This attack was called the smurf attack. Other forms of this attack

have used the local broadcast address (255.255.255.255) and directed subnet broadcast addresses (for example, 192.168.10.255). To minimize the ability of her sites hosts from responding to this type of attack, the administrator needs to disable the hosts 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 systems IP stack. Refer to your hosts 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

IP Forwarding 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 ndd set /dev/ip ip_forwarding=0 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 ndd set /dev/ip ip_forward_source_route=0 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 ndd set /dev/ip ip_forward_directed_broadcast=0 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_q0 10240 NOTE: On versions of Solaris prior to 2.6, use nddset /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

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 notation @ followed by a host name is used. mail.debug @log.astrocorp.com 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 e-mail 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 e-mail to alert the system administrator. swatch can be found at http://www.stanford.edu/~atkins/swatch/. Log File Parsers

logcheck logcheck is a log parser distributed by Psionic Corporation. logcheck is available for multiple versions of UNIX, at http://www.psionic.com/ abacus/logcheck/ 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 companys 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 http://www.networkintrusion.co.uk/N_ids.htm/ for more information on IDS freeware and commercial offerings. tcpdump

tcpdump was originally developed by Van Jacobsons 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 http://www.nswc.navy.mil/ISSEC/CID/ is one IDS system that employs tcpdump to collect raw packets for analysis. tcpdump is available at http://www.tcpdump.org/ 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 http://www.snort/org/ Log Files

bro 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 http://www-org.ee.lbl.gov/broinfo.html/ 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 wellrespected commercial IDS systems. Log Files

Network Flight Recorder (NFR) is a commercial IDS system produced by Network Flight Recorder. Information is available at http://www.nfr.com/ 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 http://www.enterasys.com/ Cisco IDS (Formerly NetRanger) is Ciscos second generation IDS system. Information on Cisco IDS is available at http://www.cisco.com/go/ids/ 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 attackers motives. The deception toolkit (dtk) is one honeypot package. The dtk package is available at http://www.all.net/dtk/ Others include BackOfficer Friendly, Mantrap, CyberCop Sting, and Spectre. Consult http://www.networkintrusion .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. Simple Network Monitor Protocol 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. Simple Network Monitor Protocol 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. When You Think You Have Been Hacked 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 Coroners 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 http://www,fish.com/security/ 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 http://www.encase.com/ When You Think You Have Been Hacked

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 hosts 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 www.cert.org/ , 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: OReilly & Associates, 1995, (ISBN 1-56592- 124-0). - (Covers the setup and maintenance of firewalls.) Computer Emergency Response Team (CERT);, http://www.cert.org/; [email protected]; 1-412-268-7090. - (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);, http://ciac.llnl.gov/; [email protected]; 1-510-422-8193. - (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: OReilly & Associates, 1996, (ISBN 156592-148-8).. - (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: OReilly & Associates, 1997, (ISBN 1-56592-269-7). -

(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: 0072193816. Northcutt, Steven, Network Intrusion Detection: An Analysts Handbook,. 2nd edition, Steven Northcutt, 2d ed., New Riders Books, Indianapolis, IN: New Riders, ISBN 0-7357-1008-2. Pomeranz, Hal (ed.), Solaris Security: Step by Step. Colorado Springs, SANS Institute, 1999; (719) 599-4303 or [email protected] (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 http://www.sans.org/ www.cs.purdue.edu/homes/spaf/hotlists/ csec-top.html. - (Professor Gene Spaffords 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 (RPCs). 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 wizard# cat /etc/dfs/dfstab # place share(1M) commands here for automatic execution # on entering init state 3. # # share [-F fstype] [ -o options] [-d ""] [resource] # .e.g, # share -F nfs -o rw=engineering -d "home dirs" /export/home2 share -F nfs -o rw=boole.cselab.nd.edu:branin.cselab.nd.edu -d "Mail Spool Files" /var/mail

Network File Sharing #device device #to mount to fsck # /dev/dsk/c0t0d0s1 /dev/dsk/c0t0d0s0 /dev/rdsk/c0t0d0s0 /dev/dsk/c0t0d0s6 /dev/rdsk/c0t0d0s6 /dev/dsk/c0t0d0s7 /dev/rdsk/c0t0d0s7 music:/export/Netwatch/lab -

mount point FS type fsck pass mount mount at boot options / /usr /export/home

/usr/lab swap ufs ufs ufs nfs 1 1 2 - no no no

yes yes rw,soft,intr,bg 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 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 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 TransArcs 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 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 (?) AFS

Add-in product client side caching is standard authenticated challenge on net scales well Uses Access Control Lists (ACLs) More secure than NFS Less reliable than NFS (?) Network File Sharing NFS 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) roots 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. Network File Sharing AFS 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 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. Network File Sharing AFS 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. Network File Sharing AFS 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. Automating File Sharing 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. Automating File Sharing This dialog includes three items to pay careful attention to. 1. 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. 2. 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. 3. 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. Automating File Sharing 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. Automating File Sharing 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. Automating File Sharing Automating File Sharing Automating File Sharing 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 users directories. Automating File Sharing What you want the system to do is map a file system from the server to an alternate mount point on the client Automating File Sharing 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: Automating File Sharing 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

Automating File Sharing 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

Automating File Sharing 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 Automating File Sharing 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. Automating File Sharing 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

Automating File Sharing 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) Automating File Sharing 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

Automating File Sharing 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 rewrite 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.

Automating File Sharing 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.

Automating File Sharing 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. Automating File Sharing # 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 129.74.70.77 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 its

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, email 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. 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

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 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 (129.74.70.77) 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 its data from the primary server via a zone transfer. Multiple secondary servers allowed within a domain. caching - loads a few important addresses into its 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 dont 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 hostresolved. If darwin does not find foyt.central.sun.com in its hosts file, it checks /etc/resolv.conf, finds the name of its nameserver. Darwin creates a DNS query packet, and sends it to the

nameserver. The nameserver receives the DNS query packet and examines it: Hi, Im darwin, I live at 129.74.250.114, 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 its master nameserver (.edu) saying Hi, Im bind.cc.nd.edu, I live at 129.74.250.100, 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 its database, then it will reply back through the chain that foyt.central.sun.com is at 123.45.67.89. 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 its 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 its 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, Im Darwin, my IP address is 129.74.250.114, 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 its MAC address. Otherwise the router replies with its MAC address. Name Services Darwin sends an IP packet to foyt.central.sun.com at IP address 123.45.67.89 saying Hi, Im darwin.cc.nd.edu, I live at 129.74.250.114 and my MAC address is 08:00:20:00:4e:3f. Id 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 its finger daemon on port 79. Foyt adds the darwin machine to its 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 123.45.67.89, 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 users terminal. Darwin adds the Foyt machine to its named cache. DONE The user finds out their friend wasnt 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 129.74.250.100 nameserver 129.74.37.173 nameserver 129.74.4.18 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). Well 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 { 129.74.70.77; }; 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 { 129.74.250.100; 129.74.4.18; 129.74.25.98; }; forwarders { 129.74.250.100; }; }; Name Services 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 { 129.74.250.100; 128.74.4.18; 129.74.25.98; }; allow-query { 129.74.0.0/16; }; }; zone "70.74.129.in-addr.arpa" IN {

type master; file "d.70.74.129.in-addr.arpa"; allow-transfer { 129.74.250.100; 128.74.4.18; 129.74.25.98; }; allow-update { none; }; allow-query { 129.74.0.0/16; }; }; Name Services zone "nd.edu" { type slave; file "nd.edu.zone"; masters { 129.74.250.100; 129.74.4.18; }; forwarders { 129.74.250.100; 129.74.4.18; }; allow-query { 129.74.0.0/16; };

}; zone "74.129.in-addr.arpa" IN { type slave; file "d.74.129.in-addr.arpa"; masters { 129.74.250.100; 129.74.4.18; }; forwarders { 129.74.250.100; }; allow-query { 129.74.0.0/16; }; }; Name Services zone "localhost" IN { type master; file "localhost.zone"; allow-update { none; };

}; zone "0.0.127.in-addr.arpa" IN { type master; file "127.0.0.zone"; allow-update { none; }; }; 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 zones data and defines global (zone) parameters. NS - Name Server - Identifies a domains 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. . 6D IN NS . 6D IN NS . 6D IN NS

. 6D IN NS . 6D IN NS . 6D IN NS . 6D IN NS . 6D IN NS . 6D IN NS . 6D IN NS . 6D IN NS

. 6D IN NS . 6D IN NS G.ROOT-SERVERS.NET. J.ROOT-SERVERS.NET. K.ROOT-SERVERS.NET. L.ROOT-SERVERS.NET. M.ROOT-SERVERS.NET. A.ROOT-SERVERS.NET. H.ROOT-SERVERS.NET. B.ROOT-SERVERS.NET. C.ROOT-SERVERS.NET. D.ROOT-SERVERS.NET. E.ROOT-SERVERS.NET. I.ROOT-SERVERS.NET.

F.ROOT-SERVERS.NET. G.ROOT-SERVERS.NET. J.ROOT-SERVERS.NET. K.ROOT-SERVERS.NET. L.ROOT-SERVERS.NET. M.ROOT-SERVERS.NET. A.ROOT-SERVERS.NET. H.ROOT-SERVERS.NET. B.ROOT-SERVERS.NET. C.ROOT-SERVERS.NET. D.ROOT-SERVERS.NET. E.ROOT-SERVERS.NET. I.ROOT-SERVERS.NET. F.ROOT-SERVERS.NET. 5w6d16h IN A 192.112.36.4

5w6d16h IN A 198.41.0.10 5w6d16h IN A 193.0.14.129 5w6d16h IN A 198.32.64.12 5w6d16h IN A 202.12.27.33 5w6d16h IN A 198.41.0.4 5w6d16h IN A 128.63.2.53 5w6d16h IN A 128.9.0.107 5w6d16h IN A 192.33.4.12 5w6d16h IN A 128.8.10.90 5w6d16h IN A 192.203.230.10 5w6d16h IN A 192.36.148.17 5w6d16h IN A 192.5.5.241 Name Services

Localhost zone files # cat localhost.zone ; Forward lookup for 127.0.0. zone $ORIGIN localhost. @ 1D IN SOA 42 3H 15M 1W 1D ) 1D IN NS 1D IN A @ root ( ; serial (d. adams)

; refresh ; retry ; expiry ; minimum @ 127.0.0.1 Name Services Localhost zone files # cat 127.0.0.zone ; Reverse information file for 127.0.0 zone $ORIGIN 0.0.127.in-addr.arpa. @

1D IN SOA localhost. root.localhost. ( 42 ; serial (d. adams) 3H ; refresh 15M ; retry 1W ; expiry 1D ) ; minimum 1D IN NS localhost. 1 1D IN PTR

localhost. # more d.cselab.nd.edu $ORIGIN nd.edu. ; Lab Start of Authority Record cselab 86400 IN SOA music.cselab.nd.edu. root.music.cselab.nd.edu. ( 261 86400 21600 604800 86400 ) 86400 IN NS music.cselab.nd.edu. music.cselab 86400 IN A 129.74.70.77 ; Now define the lab hosts $ORIGIN cselab.nd.edu.

localhost 86400 IN A 127.0.0.1 loghost 86400 IN A 127.0.0.1 stu-gw 86400 IN A 129.74.46.33 86400 IN HINFO "Cisco 4500" "IOS" stu-switch 86400 IN

A 129.74.46.34 86400 IN HINFO "Cisco 4500" "IOS" dilbert 86400 IN A 129.74.46.35 86400 IN HINFO "Generic PC" "Linux/BSD" # cat d.70.74.129.in-addr.arpa $ORIGIN 74.129.in-addr.arpa. 70 86400 IN SOA bind.nd.edu. root.music.cselab.nd.edu. ( 241 86400 21600 604800 86400 )

86400 IN NS bind.nd.edu. $ORIGIN 70.74.129.in-addr.arpa. 66 86400 IN PTR cselab-gw.cselab.nd.edu. 67 86400 IN PTR noise.cselab.nd.edu. 69 86400 IN PTR acapella.cselab.nd.edu. 70 86400 IN PTR latin.cselab.nd.edu.

71 86400 IN PTR swing.cselab.nd.edu. 72 86400 IN PTR spiritual.cselab.nd.edu. 73 86400 IN PTR march.cselab.nd.edu. 74 86400 IN PTR country.cselab.nd.edu. 75 86400 IN PTR salsa.cselab.nd.edu. 76

86400 IN PTR blues.cselab.nd.edu. 77 86400 IN PTR music.cselab.nd.edu. 78 86400 IN PTR pop.cselab.nd.edu. Name Services 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: 129.74.250.100 Name: wizard.cse.nd.edu Address: 129.74.25.101

Name Services grumpy% nslookup cse.nd.edu Server: bind.nd.edu Address: 129.74.250.100 grumpy% nslookup Default Server: bind.nd.edu Address: 129.74.250.100 Name: cse.nd.edu Address: 129.74.18.2 > set type=MX > cse.nd.edu Server: bind.nd.edu

Address: 129.74.250.100 grumpy% nslookup wizard Server: bind.nd.edu Address: 129.74.250.100 Name: wizard.cse.nd.edu Address: 129.74.25.101 cse.nd.edu preference = 1, mail exchanger = mail.cse.nd.edu cse.nd.edu nameserver = bind.nd.edu cse.nd.edu nameserver = iugate.ucs.indiana.edu cse.nd.edu nameserver = odin.cc.nd.edu cse.nd.edu nameserver = thor.cc.nd.edu mail.cse.nd.edu internet address = 129.74.25.101 mail.cse.nd.edu internet address = 129.74.18.4 bind.nd.edu internet address = 129.74.250.100

iugate.ucs.indiana.edu internet address = 129.79.1.9 odin.cc.nd.eduinternet address = 129.74.4.18 thor.cc.nd.edu internet address = 129.74.37.173 Name Services >? Commands: (identifiers are shown in uppercase, [] means optional) NAME - print info about the host/domain NAME using default server NAME1 NAME2 - as above, but use NAME2 as server help or ? - print info on common commands; see nslookup(1) for details set OPTION - set an option

all - print options, current server and host [no]debug - print debugging information [no]d2 - print exhaustive debugging information [no]defname - append domain name to each query [no]recurse - ask for recursive answer to query [no]vc - always use a virtual circuit domain=NAME - set default domain name to NAME srchlist=N1[/N2/.../N6] - set domain to N1 and search list to N1,N2, etc. root=NAME - set root server to NAME

retry=X - set number of retries to X timeout=X - set initial time-out interval to X seconds querytype=X - set query type, e.g., A,ANY,CNAME,HINFO,MX,PX,NS,PTR,SOA,TXT,WKS type=X - synonym for querytype class=X - set query class to one of IN (Internet), CHAOS, HESIOD or ANY Name Services server NAME - set default server to NAME, using current default server lserver NAME - set default server to NAME, using initial server finger [USER] - finger the optional USER at the current default host root

- set current default server to the root ls [opt] DOMAIN [> FILE] - list addresses in DOMAIN (optional: output to FILE) -a - list canonical names and aliases -h - list HINFO (CPU type and operating system) -s - list well-known services -d - list all records -t TYPE - list records of the given type (e.g., A,CNAME,MX, etc.) view FILE - sort an 'ls' output file and view it with more exit - exit the program, ^D also exits

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 browsers 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 Microsofts 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 Reals 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. Macromedias Flash animation player plug-in and Reals 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, Windows 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. Web Services

Client Security Issues 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.

Web Services Client Security Issues 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. Web Services Client Security Issues 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 browsers 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. Web Services Client Security Issues 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 users 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.

Web Services Choosing a Web Server 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. Web Services Choosing a Web Server 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. Web Services Choosing a Web Server WARNING: Based on a long string of security problems,

culminating in the infamous Code Red and Nimda worms, many organizations have moved away from Microsofts 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 http://www.apache.org/ 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 servers 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 e-mail 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. Web Services Basic Apache Directives 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. Web Services Basic Apache Directives 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 users username as follows. A user whose username is bob has his WWW directory

mapped to http://www.astro-corp.com/ ~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. Web Services Basic Apache Directives A new installation of Apache may also require changing the 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 line may be necessary. 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. SetHandler server-status Order deny,allow

Deny from all Allow from .astro.com 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 servers name were www.astro.com the URL used to access this page would be, http://www.astro.com/serverstatus/ 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 SSLVerifyClient require SSLVerifyDepth 1 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 e-mail 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 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 www.astro.com were set to listen on port 8000, the URL for the servers default page would be : http://www.astro.com:8000

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 servers 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 servers 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 Order Deny,Allow Deny from all # Allow access to users web directories Order Deny,Allow

Allow from all # Allow access to the system web directory Order Deny,Allow Allow from all 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 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. Options IncludesNOEXEC 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 Pandoras 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 4.1.2 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 2.2.1 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. Solariss 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. Web Services Unintended Web Servers 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 wellknown 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. Web Services Unintended Web Servers 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. Web Services Unintended Web Servers

Personal File Sharing Web servers running on users PCs 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 ones 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 servers 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. Web Services Web Performance Issues 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. Web Services Web Performance Issues 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. Web Services Web Caches 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. Web Services Web Caches 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. Web Services Web Caches 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 email. Understand the basic protocols used to deliver and transport mail.

Understand the basics of email 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! Email is assumed to be confidential It is not confidential! Email delivery delays are not tolerated Email 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 email services How to secure MUA services Email Email Overview Typical user complaints/questions: How do I send mail to my friend? I dont know their address, but I need to send them mail. I sent person X mail, why dont they respond? Why do I get all of this spam? Why cant 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 hosts 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 Email

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 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, [email protected], [email protected] mentor: suggest, henry tou: \[email protected] scott: \[email protected] Email Mail Strategy

To implement the delivery of e-mail at a site, the administrator has to make a few decisions about how mail will be handled at the site. There are two primary e-mail 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 e-mail. 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 users messages are not lost.

The individual machines are all running the SMTP daemon, and could be used as open relays. The fact that e-mail 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 e-mail management requires a large central e-mail 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 e-mail

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. Email Mail Strategy This model requires much more configuration at the beginning, but it also brings a certain amount of sanity to the e-mail 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. Email 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. Email 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 e-mail address on the corporate server, rather than the address on the users desktop. Email 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! Email Email Protocols The heart of e-mail is the collection of protocols used to transport e-mail from server to server and make it available to users. This collection of standard protocols allows the wide range of e-mail 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. Email Email 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 (MUAs) Some MUAs read mail directly from the spool (/var/mail, /var/spool/mail). (mailx) Mail spool must be mounted on machine where user reads mail. Some MUAs 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 (MUAs) Some MUAs 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 RPCs to act on messages. Displays message on client, does not copy to local disk. Email MUAs Have their own transport languages.

Typical commands: User Pass Get Put Delete Purge Write (Save) Email Mail transport agents (MTAs) Mail transport agents (MTAs) are the workhorses of the e-mail system. Several MTAs exist for a wide range of platforms. Some common choices are Sendmail, Microsofts

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. Email 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 (email strategy, security). The sendmail.cf file is used to customize the local delivery rules.

Email Sendmail Philosophy Dont actually deliver email route it. Too many local conventions. Too hard to customize sendmail to fit these conventions. Generalized crossbar switch Individual MUAs dont 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 MTAs)

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 MTAs 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 MTAs 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). Email

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 e-mail 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 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 systems idea, USE_TZ to use the users 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 Sendmails 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, e-mail sent to [email protected] is marked as sticky and is not forwarded to LOCAL_RELAY. With MAIL_HUB, mail addressed to [email protected] is forwarded to the mail hub, with the envelope address remaining [email protected] Without stickyhost, the envelope would be changed to [email protected]_hub, 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 e-mail 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 Email 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

Email Example: [email protected] ([email protected]) could become 7 tokens: curt @ cse . nd . edu $1 $2 $3 $4 $5 $6 $7 $* [email protected] $+ [email protected] $+ @ $+ $1=curt $2=cse.nd.edu $- @ $+

$1=curt $2=cse.nd.edu $+ @ $- . $D $1=curt $2=cse $+ . $+ . $=$T [email protected] $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 [email protected] $:default $) Generalized keyed mapping function $>n "Call" ruleset n $#mailer Resolve to mailer [email protected] 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} $* RRe: ${MPat} $* R${HPat} $* RRe: ${HPat} $* $#error $: 553 ${MMsg} $#error $: 553 ${MMsg} $#error $: 553 ${HMsg} $#error $: 553 ${HMsg}

Email LOCAL_RULESETS SLocal_check_mail R$* $:$1 $| $>Local_check_numb $1 R$* $| $#$* $#$2 R$* $| $* [email protected] $>Local_check_bull $1 R$* $| $#$* $#$2 # SLocal_check_numb R$* $: $>Parse0 $>3 $1

R$+ < @ $+. > $* $: $(allnumbers $1 $) [email protected] $#error $: 553 Header Error # SLocal_check_bull R$* $: $>Parse0 $>3 $1 R$+ < @ $+. > $* $: $(SpamFriend $1 $) [email protected] $#error $: 550 We no longer accept spam email from you # # now call Basic_check_mail to continue processing # R$* $| $* [email protected] $>"Basic_check_mail" $1

Email 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 macros 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 elses 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. Email Statistics

A small ISP reported that in 80 days they received 257,000 pieces of email 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 [email protected][email protected]_server 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 members 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 ISPs. 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 [email protected] Action is one of: OK, REJECT, or RELAY Email Access Database nd.edu cselab.nd.edu cse.nd.edu austin.ibm.com 129.74 [email protected] [email protected] [email protected]

bttb.net free-virtualweb.org thefreevirtual.org [email protected] RELAY RELAY RELAY RELAY OK REJECT REJECT REJECT REJECT REJECT 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. Email When building the sendmail binary, there are several options that need to be considered: By default, sendmail will use the OSs 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. Email Mail Logfiles An important part of the email 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 IDs 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. Email 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 e-mail 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 thirdparty 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 login/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 users 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. Email 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 users 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 users password, the user name and all of the users e-mail 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. Email 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 users 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 users password, the user name and all of the users e-mail still pass along the network in the clear. Email 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. Email IMAP The downside to POP is that the users e-mail is removed from the server and copied onto the users system. The Internet Message Access Protocol (IMAP) offers a solution by providing a file-server-like facility tailored to handling e-mail. 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 e-mail folders. Email

IMAP All of the users e-mail 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 e-mail 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 e-mail 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: Microsofts 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. Email 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, webbased mail can make use of the encrypted connection to protect the user ID, password, and message content.

Email 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 e-mail 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 e-mail through other filtering programs. spamassassin: One of the best tools for identifying those annoying and unwanted commercial e-mails 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 e-mail 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 sites e-mail model, user agents, and hardware required to provide this critical service. Users will benefit from a well-chosen combination of e-mail 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 RedHat up2date Notre Dames 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) PCs with Linux (250 hosts) How would you distribute a new version of sendmail to each host? Information Distribution 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. Information Distribution 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 Information Distribution 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). Information Distribution 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. Information Distribution 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. Information Distribution 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. Information Distribution 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} 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"; 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.4.000044673500/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} 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"; 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"; Information Distribution 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 "[email protected]@\r"} expect "ftp> " {send "bin\r"} expect "ftp> " {send "get np.tar /dev/null\r"} expect "ftp> " {send "quit\r"} exit

Information Distribution 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 #

# For all CSE clients (i.e. non-wizard) # F /.rhosts /afs/nd.edu/wsadmin/cse_254/common root sys F /.cshrc /afs/nd.edu/wsadmin/cse_254/common root sys F /.profile /afs/nd.edu/wsadmin/cse_254/common root sys F /var/spool/cron/crontabs/root 644

444 444 444 /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/211 root other 444 LA /etc/sendmail.cf /etc/mail/sendmail.cf root other 444 Information Distribution 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). MITs Hesoid - never caught on, difficult to build configuration files. Uses DNS to provide information from a central server. Netinfo - NeXT computers 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 users 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 Programming Shells 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. Shell Programming

Shells 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 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 $ HN=`uname -n` $ echo $HN grumpy $ who am i curt pts/5 $ 'who am i' who am i: not found $ `who am i` curt: not found Nov 11 13:47

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 M -eq, -ne, -gt, -lt, -ge, -le = != > < >= <= -o (or) -a (and) Shell Programming Test Conditions The shells also provides a way to test the external environment:

-r file -w file -x file -e file -o file -z file -f file -d file (read permission) (write permission) (execute permission) (file exists) (user owns file) (file is empty) (plain 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 string equality if [ $LOGNAME = root ] ; then general form: S R ; or 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 its arguments. General form: expr variable operation variable operations: +, -, *, /, % (remainder) sum=`expr $1 + $2` Shell Programming Conditional Processing

The shells all provide a way to do conditional processing: if [ condition ] ; then if ( condition) then statements else (or else if) statements fi endif Shell Programming

Conditional Processing for variable in list # BOURNE SHELL do statements done foreach i ( list ) statements end # CSH

Shell Programming Conditional Processing while condition #BOURNE while condition # CSH do statements statements done until condition do

statements done end Shell Programming Conditional Processing SH case variable in pattern 1) statements ;; pattern 2) statements ;;

*) #default case statements ;; esac Shell Programming Conditional Processing CSH switch ( variable ) case pattern 1: statements breaksw pattern 2: statements

breaksw default : statements breaksw 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 [email protected] access all variables

$* lumps all variables into a single string [email protected] 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 < file -- causes shell to read from file

<&n -- causes shell to read from file descriptor n <&- -- causes shell to close standard input 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 echo $1 $2 $3 >> $4

# overwrite $4 # 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

Shell Programming Other Shell Features The : command is a null command. Shells allow I/O operations: echo Enter your afsid: read AFSID 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 +1 -2 $* |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 The set command allows you to set $1 through $n to the words given as its arguments: who -r . run-level set `who -r`

echo $6 09:13 3 Nov 21 09:13 2 0 S Shell Programming 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" fi

fi 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 users 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 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.outs, 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 4755 -o -perm 2755 -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 Find Command 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: 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 Generic invocations: AWK 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 Notre Dame, IN 46656 Amy Vanderbilt 876 Hesburgh Library Notre Dame, IN 46656 AWK Awk You can set shell variables with the output of the awk command. input: name address phone John Doe, 123 Sorin Hall, 634-4444 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 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 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 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 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 dont 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 Drs database is: Species,Owner Name, Address, City, State, Zip, Phone, Animals 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." print "" print "" } }' Other Useful Tools Some other tools you might want to experiment with: cut - cut bytes from the input. first=Curt last=Freeland f1=`echo $first | cut -b1`

ln=`echo $last | cut -b1-7` f1=C ln=Freelan try=curt:x:1234:40:GECOS:/home/curt:/bin/csh found=`echo $try | cut -d: -f1` found=curt Other Useful Tools Its 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

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 systems 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. General Performance Tuning Rules Determine the hardware requirements of specific types of servers. Generally, e-mail and web servers require highthroughput 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, highspeed disk systems, and significant processing elements. Timeshare systems require significant processing elements, and large amounts of memory.

General Performance Tuning Rules 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. General Performance Tuning Rules 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: 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 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: 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 systems 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 http://developer.intel.com/software/ products/vtune/ SysInternals http://www.sysinternals.com/ 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? 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 How long does the users 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 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. 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 systems 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 systems 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 Its cheap Use limits theyre 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 (Its 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 RAIDs 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 8kilobyte 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 disks 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 drives storage capacity.

Disk Performance Zone Sectoring 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 users 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 Ext3s 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 drives 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. Ext3s 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, Ext3s 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 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 40 0 0 0 60 300 60 0 0 > /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 readmostly) 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 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: Dont 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 CPUs Dont run accounting/quotas if your goal is peak performance. Run system scripts late at night (or other off-hours). Dont 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 systems performance.

Recently Viewed Presentations

  • Our Mission Appalachian Crossroads empowers people with disabilities

    Our Mission Appalachian Crossroads empowers people with disabilities

    Matt Tasker was hired at Pifer& Son's Auto Repair. He works from 9:00 a.m. - 2:00 p.m, 4 days a week. He changes oil, tires, brakes, rotors, etc. Received additional DORS funding (tools, specialized clothing, safety gear).
  • Psychological, sociological &amp; philosophical perspectives on ...

    Psychological, sociological & philosophical perspectives on ...

    Psychological, sociological & philosophical perspectives on student learning. EDFGC 5807 Theory and Practice of Learning and Teaching. Week 4. Monday 20th March 2017
  • Advanced RDA CJK NACO Training Council on East

    Advanced RDA CJK NACO Training Council on East

    Advanced RDA CJK NACO Training Council on East Asian Libraries Annual Meeting March 24, 2014 Jessalyn Zoom Library of Congress*
  • PowerPoint Presentation

    PowerPoint Presentation

    Introduction to HTML HTML: HyperText Markup Language HTML documents are simply text documents with a specific form Documents comprised of content and markup tags Content: actual information being conveyed The markup tags tell the Web browser how to display the...
  • MIT course on Oscillations and Waves (by Prof. Walter Lewis)

    MIT course on Oscillations and Waves (by Prof. Walter Lewis)

    Solutions: Comparing Solutions: Waves are the key to sound, color, and much more: Rainbow Sunglint Tsnunamis Earthquakes Cel Phone signals Microwave ovens Musical Instruments … Rainbow Physics Cloud Rainbow observed from space: F-M. Breon, P. Goloub, 1998. The Sunglint What...
  • American Megafauna

    American Megafauna

    Winter Frontal Systems Dominant air masses: Warm Moist to the south Cold and Dry to the north Low pressures from the jet stream spin counter-clockwise This forces the warm moist air over cold dry air, causing storms 3. Winter Frontal...
  • Loving the Universe - St. Lawrence University

    Loving the Universe - St. Lawrence University

    A sea of light and particles. quarks that make up protons & neutrons. electrons, muons and other leptons (tiny!!) Uniformly bright. light coming from everywhere! like a very bright fog. the Universe was opaque. After a few hundred thousand years...
  • Network Security - EMMOS

    Network Security - EMMOS

    Network Security Lewis R. Folkerth, P. E. Consumers Energy Energy Management Systems [email protected]