Solaris 10 Handbook

Solaris Handbook
Info-ap@wilshiresoft.com Ph: 040-23757906 / 07, 64526173 info-ht@wilshiresoft.com

Version: 3 www.wilshiresoft.com Rev. Dt: 14-Sep-2012
Index
1. Introduction to Solaris ................................................................................................................... 5
1.1. History of UNIX................................................................................................................................................ 5
1.2. A Brief History of Sun Microsystems ............................................................................................................... 5
1.3. Working with Host ........................................................................................................................................... 6
1.4. Roles of Servers and Clients ........................................................................................................................... 7
2. Solaris Installation ........................................................................................................................ 10
2.1. Solaris Software Installation .......................................................................................................................... 10
2.1.1. The Solaris 10 OE Installation and Upgrade Options ............................................................................. 10
2.1.2. Hardware Requirements for Installation of the Solaris 10 OE ................................................................. 11
2.1.3. Solaris OE Software Groups................................................................................................................... 11
2.1.4. Pre-Installation Information ..................................................................................................................... 13
3. File Systems & Software Management ....................................................................................... 14
3.1. Directory Hierarchy........................................................................................................................................ 14
3.1.1. Root Subdirectories ................................................................................................................................ 14
3.1.2. File Components .................................................................................................................................... 14
3.1.3. File Types ............................................................................................................................................... 15
3.1.4. Links ....................................................................................................................................................... 16
3.2. Devices ......................................................................................................................................................... 17
3.2.1. Disk Architecture .................................................................................................................................... 18
3.2.2. Device Naming Convention .................................................................................................................... 20
3.2.3. Managing Devices .................................................................................................................................. 20
3.2.4. Reconfiguring Devices ............................................................................................................................ 21
3.2.5. Disk Partitioning ...................................................................................................................................... 22
3.2.6. Introducing Disk Labels .......................................................................................................................... 23
3.3. Solaris OE File Systems ................................................................................................................................ 23
3.3.1. Types of File Systems ............................................................................................................................ 23
3.3.2. UFS File System ..................................................................................................................................... 25
3.3.3. File System Maintenance ....................................................................................................................... 29
3.3.4. Monitoring File System Usage ................................................................................................................ 30
3.4. Mounting and Unmounting File Systems ....................................................................................................... 31
3.4.1. Mounting Fundamentals ......................................................................................................................... 31
3.4.2. Volume Management.............................................................................................................................. 33
3.5. Package Administration ................................................................................................................................. 34
3.6. Patch Administration ..................................................................................................................................... 39
4. Startup and Shutdown ................................................................................................................. 41
4.1. Boot PROM ................................................................................................................................................... 41
4.1.1. Boot PROM Fundamentals ..................................................................................................................... 41
4.1.2. Basic Boot PROM Commands ............................................................................................................... 42
4.1.3. Listing NVRAM Parameters .................................................................................................................... 43
4.1.4. Interrupting an Unresponsive System ..................................................................................................... 43
4.2. Perform System Boot and Shutdown ............................................................................................................ 43
4.2.1. SMF and the Boot Process ..................................................................................................................... 43
4.2.2. Run Levels.............................................................................................................................................. 46
4.2.3. SPARC Systems Boot Process .............................................................................................................. 47
4.2.4. SMF and Booting .................................................................................................................................... 51
4.2.5. Run Control Scripts ................................................................................................................................ 51
4.2.6. System Shutdown ................................................................................................................................... 53

5. Account Management & Security ............................................................................................... 55
5.1. What Are User Accounts and Groups? ......................................................................................................... 55
5.1.1. User Account Components ..................................................................................................................... 55
5.1.2. Where User Account and Group Information Is Stored .......................................................................... 59
5.1.3. Customizing a Users Work Environment ............................................................................................... 67
5.1.4. Quotas .................................................................................................................................................... 71
5.2. System Security ............................................................................................................................................ 71
5.2.1. Monitoring System Access ..................................................................................................................... 71
5.2.2. Switching Users on a System ................................................................................................................. 73
5.2.3. Controlling System Access ..................................................................................................................... 74
5.2.4. ftp, rlogin, ssh ......................................................................................................................................... 76
6. Printers .......................................................................................................................................... 79
6.1. Printing Terminology ..................................................................................................................................... 79
6.2. Printing in the Solaris Operating System ....................................................................................................... 80
6.3. Administering Printers ................................................................................................................................... 81
7. System Processes & Job Automation ........................................................................................ 87
7.1. Updating System Files .................................................................................................................................. 87
7.2. System Automation with Shell Scripts ........................................................................................................... 87
7.3. Automating Commands with cron and at ....................................................................................................... 87
7.3.1. Scheduling a Repetitive System Task (cron) .......................................................................................... 88
7.3.2. Scheduling a Single System Task (at) .................................................................................................... 90
7.4. Viewing System Processes ........................................................................................................................... 91
8. Backup and Restore ..................................................................................................................... 94
8.1. Fundamentals of Backups ............................................................................................................................. 94
8.2. Types of Backups .......................................................................................................................................... 95
8.3. Types of Backup Devices .............................................................................................................................. 99
8.4. Commands for Copying File Systems ......................................................................................................... 103
8.5. Backup Device Names ................................................................................................................................ 108
9. Network Basics ........................................................................................................................... 112
9.1. TCP/IP ......................................................................................................................................................... 113
9.2. Network Services ........................................................................................................................................ 116
10. Swap, Core & Crash Files ........................................................................................................ 124
10.1. Virtual Memory Concepts .......................................................................................................................... 124
10.2. Configuring Swap ...................................................................................................................................... 125
10.3. Core Files and Crash Dumps .................................................................................................................... 125
10.3.1. Core Files ........................................................................................................................................... 125
10.3.2. Crash Dumps...................................................................................................................................... 127
11. Network File Systems .............................................................................................................. 130
11.1. NFS terminology........................................................................................................................................ 130
11.2. Remote Procedure Call (RPC) .................................................................................................................. 130
11.3. NFS Commands ........................................................................................................................................ 131
11.4. NFS Daemons ........................................................................................................................................... 133
11.5. Commands for Troubleshooting NFS Problems ........................................................................................ 135
11.6. Autofs ........................................................................................................................................................ 136
11.6.1. Autofs Features .................................................................................................................................. 136
11.6.2. Autofs Maps ........................................................................................................................................ 137
11.6.3. How Autofs Works .............................................................................................................................. 140
12. Solaris Volume Manager .......................................................................................................... 142

12.1. Introduction to Storage Management ........................................................................................................ 142
12.2. Introduction to Solaris Volume Manager ................................................................................................... 143
12.3. Solaris Volume Manager Requirements .................................................................................................... 143
12.4. SVM Configuration .................................................................................................................................... 145
12.5. Overview of RAID-0 Volumes .................................................................................................................... 150
12.6. Overview of RAID-1 (Mirror) Volumes ....................................................................................................... 151
12.7. Overview of RAID-5 Volumes .................................................................................................................... 152
12.8. Overview of Hot Spares and Hot Spare Pools .......................................................................................... 153
12.9. Introduction to Disk Sets ........................................................................................................................... 154
13. RBAC and Syslog ..................................................................................................................... 156
13.1. RBAC ........................................................................................................................................................ 156
13.2. System Messaging .................................................................................................................................... 159
13.2.1. Syslog Function Fundamentals .......................................................................................................... 159
13.2.2. Customizing System Message Logging .............................................................................................. 159
14. Naming Services....................................................................................................................... 161
14.1. Name Service concept .............................................................................................................................. 161
14.2. Solaris Naming Services ........................................................................................................................... 161
14.3. The Name Service Switch ......................................................................................................................... 163
14.4. Domain Name Service .............................................................................................................................. 164
14.5. Network Information Service ..................................................................................................................... 169
15. Advanced Installations ............................................................................................................ 174
15.1. Solaris Containers ..................................................................................................................................... 174
15.1.1. Resource Management ...................................................................................................................... 174
15.1.2. Solaris Zones ...................................................................................................................................... 174
15.2. Custom JumpStart Introduction ................................................................................................................. 177
15.3. Solaris Flash Introduction .......................................................................................................................... 178
16. Performance Tuning................................................................................................................. 180
17. Miscellaneous ........................................................................................................................... 189
17.1. Dynamic Host Configuration Protocol ........................................................................................................ 189
17.2. Samba ....................................................................................................................................................... 192
17.3. Apache ...................................................................................................................................................... 193
Appendix .............................................................................................................................................. I

Chapter 1 Introduction to Solaris Page 5 of 198
1. Introduction to Solaris
1.1. History of UNIX
UNIX originated as a research project at AT&T Bell Labs in 1969. In 1976, it was made available at no charge to
universities and thus became the basis for many operating systems classes and academic research projects.
As the UNIX OS offered by AT&T evolved and matured, it became known as System V (five) UNIX. As the
developer of UNIX, AT&T licensed other entities to produce their own versions of the UNIX OS. One of the more
popular of these licensed UNIX variants was developed by The University of California at Berkeley Computer
Science Research Group. The Berkeley UNIX variant was dubbed Berkeley Software Distribution (BSD) UNIX.
The BSD version of UNIX rapidly incorporated networking, multiprocessing, and other innovations, which
sometimes led to instability. In an academic environment these temporary instabilities were not considered major
problems, and researchers embraced the quickly evolving BSD UNIX environment. In contrast, corporate
computing centers were wary of converting to OS with a history of instability.
Unlike BSD UNIX, AT&Ts System V UNIX offered stability and standardization. New capabilities were introduced
at a slower rate, often after evaluating the results of introducing the same capabilities in the BSD UNIX releases.
Corporate computing centers tended to favor the stability of AT&Ts version of UNIX over that of BSD UNIX.
1.2. A Brief History of Sun Microsystems

Sun Microsystems Computer Corporation was one of the manufacturers at the forefront of the distributed
computing revolution. The companys first workstations employed microprocessors from the Motorola MC68k chip
family. Sun Microsystems founders believed that a UNIX operating system would be the most desirable option for
their new line of workstations. The early Sun systems ran an operating system called SunOS (Sun Operating
System). SunOS was based on the BSD UNIX distribution.
NOTE: About Sun Microsystems, Inc. (NASDAQ: SUNW)
It was started in the year 1982 and and its singular vision is -- "The Network Is the Computer." It is a leading
provider of industrial-strength hardware, software and services that make the Net work. Sun can be found in more
than 100 countries and on the Web at http://sun.com
Enter the SPARC
Although the systems based on microprocessor chips were faster than many mainframes, there was still room for
improvement. Sun promptly began developing its own microprocessor. In the 1980s Sun introduced a Reduced
Instruction Set Computer (RISC) chip called the Scalable Processor ARChitecture (SPARC) processor. The first
implementation of the SPARC chip ran at twice the speed of the fastest MC68k-based systems Sun was
producing at the time.
The SPARC processor chip allowed Sun to produce very powerful, inexpensive, desktop workstations. The
SPARC systems also ran the SunOS operating system, thus preserving customers software development
investments. Many other workstation manufacturers were delivering operating systems based on AT&Ts System
V release 3 operating system standards. Suns customer base had to decide between the Sun BSD based
operating system and competitors System V based offerings.
Suns New Operating System
In the late 1980s Sun announced plans to develop a new operating system based on the AT&T System V release
4 UNIX. The new OS is called Solaris. In order to make the progression of OS release numbers easy to
remember, Suns original OS is still known as SunOS version 4.X. The new Solaris OS was referred to as SunOS
5.X. In 1999, Sun released a new version of the Solaris OS named Solaris 7 (SunOS 5.7), and so on.
The Solaris OS presented two problems for Sun customers. The first problem was that many applications
available under BSD UNIX were not available under System V UNIX. Software vendor had to expend great effort
to recode portions of respective applications in order to make them operate under Solaris.
The second problem presented by Solaris to customers was that many BSD-fluent system administrators had no
experience with a System V OS. Although most user-level commands are similar under SunOS and Solaris, the
system administration commands are very different. Many of the old reliable commands from BSD-based UNIX
are missing from Solaris. Next, new commands with more functionality replaced these BSD commands. The
architecture of the OS is also very different under Solaris. Access to and management of system devices under

Solaris is foreign to BSD sys-admins. SunOS is the heart of the Solaris OE. Like all OSs, SunOS is a collection of
software that manages system resources and schedules system operations.
Command Line Interface
A command line interface (CLI) enables users to type commands in a terminal or console window to interact with
an operating system. Users respond to a visual prompt by typing a command on a specified line, and receive a
response back from the system. Users type a command or series of commands for each task they want to
perform.
Graphical User Interfaces
A graphical user interface (GUI) uses graphics, along with a keyboard and a mouse, to provide an easy-to-use
interface to a program. A GUI provides windows, pull-down menus, buttons, scrollbars, iconic images, wizards,
other icons, and the mouse to enable users to interact with the operating system or application. The Solaris 10
operating environment supports two GUIs, the Common Desktop Environment (CDE) and the GNOME desktop.
Common Desktop Environment
The Common Desktop Environment (CDE) provides windows, workspaces, controls, menus, and the Front Panel
to help you organize and manage your work. You can use the CDE GUI to organize your files and directories,
read, compose and send email, access files, and manage your system.
GNOME Desktop
GNOME (GNU Network Object Model Environment) is a GUI and set of computer desktop applications. You can
use the GNOME desktop, panel, applications, and tool set to customize your working environment and manage
your system tasks. GNOME also provides an application set, including a word processor, a spreadsheet program,
a database manager, a presentation tool, a Web browser, and an email program.
1.3. Working with Host

Host is another word for a computer. The term host comes from the notion that the computer hardware hosts the
OS and applications. The hardware is like a house in which the guests(programs) live. In order to distinguish
one computer from another, hosts are assigned names, or hostnames. To continue the house metaphor, the
hostname would be the systems address. In the Solaris OE, the system administrator assigns hostnames.
Assigning Hostnames
Hostnames usually follow a uniform naming convention. An advantage of the naming convention is to make it
easier to keep track of which hosts belong to which organizations. Another advantage of the naming scheme is
that it makes it easy for system users to remember the name when reporting problems or describing tasks.
192.168.0.0. Network
Alice Humpty Dumpty Queen

The illustration shows four hosts connected to a network. The host named Queen is a large-capacity computer
that provides network services to other computers connected to the network. These are frequently referred to as
datacenters or servers. The hosts named Alice, Humpty, and Dumpty are desktop workstations that use the
network services provided by Queen. Desktop workstations are often referred to as clients.
Assigning network addresses
Along with hostname, the sys-admin assigns each host an Internet Address. Each Ethernet interface on a host
also has a Ethernet address, built into the Ethernet hardware. The address resolution protocol (ARP) maps the
Internet addresses to Ethernet addresses.
Internet Address

The Internet address, similar to a telephone number, enables hosts to communicate with one another. For
example, in the case of a long distance telephone call, the caller dials the area code, exchange number, and line
number in order to communicate with a specific telephone location. In the same way, a hosts Internet address
describes where a host is on the Internet, which in turn allows network traffic to be directed to the host.
In the previous illustration, the hosts are connected to the Internet network number 192.168.0.0. The Internet
address assigned to a host can and often changes over the hosts lifetime.
Host Ethernet Address
An Ethernet address functions like a passport number in that it is unique and permanent hardware address
assigned by the hardware manufacturer. Hosts are identified via such addresses on the Ethernet, which in turn
enables them to communicate.
1.4. Roles of Servers and Clients

Servers and clients are two types of hosts in a network environment. A server is a process or program that
provides services to hosts on a network. If a host runs one or more server processes, it can also be referred to as
a server. A client is both a process that uses services provided by the server and a host that runs a client
process.
Process here refers to the program currently running. It is possible to have multiple instances of a single program,
each separately serving different clients. The MTA, sendmail, is a good example.
Examples for different types of servers are: file servers (share disk storage with hosts), application servers,
applications, boot servers, and boot services. Print servers attach printers and provide network printing services.
A typical file server providing html pages for a client

Host Configurations
Two standard host configurations are
1. Standalone
2. Diskless
NOTE: Host Configuration refers to how the host boots.
Standalone
Standalone hosts boot up independently of network services. We even have Networked Standalone which refers
to a standalone host connected to a network and they are up and running independent of the state of the network.
NOTE: In order for a host to boot into the multi-user state, it must be able to locate the / and swap filesystems.
The root contains the boot code, system files, and directories necessary for host operation. Swap is used for
virtual memory, which extends the hosts available memory.
Diskless Client
These are totally dependent on the network services to boot and operate. A diskless clients root, swap and usr
are supplied by a client server on the network. Advantages of this configuration include reduced equipment cost,
and centralized services and a drawback is the network load.

For example, the /export filesystem of the boot server contains a directory known as root. The /export/root
directory contains a sub-directory for each diskless client supported by the server.
The diskless client swap is used in a fashion similar to the root area. Special swap files, one per supported
diskless client, are located under the /export/swap file system. Take a look at the illustration:
192.168.0.0 Network
root
swap
/export/root
Diskless Boot Server
/export/swap
Client Disk
Diskless Client and Boot Server Configuration
Host
root, swap
Disk
A standalone host configuration

Solaris Release History

Date Release Notes
1982 Sun UNIX 0.7 First version of Suns UNIX, based on 4.BSD from UniSoft.
Bundled with the Sun-1, Suns first workstation based on the Motorola 68k processor;
Sun Windows GUI.
1983 SunOS 1.0 Sun-2 workstation, 68010 based.
1985 SunOS 2.0 NFS implemented.
1988 SunOS 4.0 New virtual memory system integrates the file system cache with the memory system.
The first SPARC-based Sun workstation, the Sun-4. Support for the Intel-based Sun
386i.
1990 SunOS 4.1 Supports the SPARCstation1+, IPC, SLC.
OpenWindows graphics environment.
1992 Solaris 2.0 Solaris 2.x is born, based on a port of System V Release 4.0.
Uniprocessor only.
First release of Solaris 2, version 2.0, is a desktop-only developers release.
1993 Solaris 2.1 Four-way symmetric multiprocessing (SMP).
1993 Solaris 2.2 Large (>2 Gbyte) file system support.
SPARCserver 1000 and SPARCcenter 2000 (sun4d architecture).
1993 Solaris 2.1-x86 Solaris ported to the Intel i386 architecture.
1993 Solaris 2.3 8-way SMP.
Device power management and system suspend/resume functionality added.
1994 Solaris 2.4 20-way SMP.
Caching file system (cachefs).
CDE windowing system.
1995 Solaris 2.5 NFS Version 3.
Supports sun4u (UltraSPARC) architecture UltraSPARC-I-based products introduced
the Ultra-1 workstation.
1996 Solaris 2.6 Added support for large (> 2 Gbyte files).
UFS direct I/O.
1998 Solaris 7 64-bit kernel and process address space.
Logging UFS integrated.
2000 Solaris 8 SMC 2.0
Diskless Client Management
RBAC
2001 Solaris 9 Built in SVM
Secure Shell
Integration of directory server and LDAP server
2005 Solaris 10 Solaris Containers
Solaris Service Manager
Dynamic Tracing

Chapter 2 Solaris Installation Page 10 of 198
2. Solaris Installation
2.1. Solaris Software Installation
2.1.1. The Solaris 10 OE Installation and Upgrade Options
There are a number of ways to install the Solaris 10 OE on your system. They include:
1. Solaris installation program
2. Solaris installation program over the network
3. Custom Jumpstart
4. Solaris Flash archives
5. WAN boot
6. Solaris Live Upgrade
7. Solaris Zones
Solaris Installation over the network

Network installations enable you to install the Solaris software from the system, called an install server that has
access to the Solaris 10 disc images. You copy the contents of the Solaris 10 DVD or CD media to the install
servers hard disk. Then, you can install the Solaris software from the network by using any of the Solaris
installation methods.
Custom JumpStart Installation
The custom JumpStart installation method is a commandline interface that enables you to automatically install or
upgrade several systems, based on profiles that you create. The profiles define specific software installation
requirements. You can also incorporate shell scripts to include preinstallation and postinstallation tasks. You
choose which profile and scripts to use for installation or upgrade. The custom JumpStart installation method
installs or upgrades the system, based on the profile and scripts that you select. Also, you can use a sysidcfg file
to specify configuration information so that the custom JumpStart installation is completely hands-off.
Solaris Flash Archives
The Solaris Flash installation feature enables you to use a single reference installation of the Solaris OS on a
system, which is called the master system. Then, you can replicate that installation on a number of systems,
which are called clone systems. You can replicate clone systems with a Solaris Flash initial installation that
overwrites all files on the system or with a Solaris Flash update that only includes the differences between two
system images. A differential update changes only the files that are specified and is restricted to systems that
contain software consistent with the old master image.
WAN boot
The WAN boot installation method enables you to boot and install software over a wide area network (WAN) by
using HTTP. By using WAN boot, you can install the Solaris OS on SPARC based systems over a large public
network where the network infrastructure might be untrustworthy. You can use WAN boot with security features to
protect data confidentiality and installation image integrity.
The WAN boot installation method enables you to transmit an encrypted Solaris Flash archive over a public
network to a remote SPARC based client. The WAN boot programs then install the client system by performing a
custom JumpStart installation. To protect the integrity of the installation, you can use private keys to authenticate
and encrypt data. You can also transmit your installation data and files over a secure HTTP connection by
configuring your systems to use digital certificates.
Solaris Live Upgrade
Solaris Live Upgrade provides a method of upgrading a system while the system continues to operate. While your
current boot environment is running, you can duplicate the boot environment, then upgrade the duplicate. Or,
rather than upgrading, you can install a Solaris Flash archive on a boot environment. The original system
configuration remains fully functional and unaffected by the upgrade or installation of an archive. When you are
ready, you can activate the new boot environment by rebooting the system. If a failure occurs, you can quickly
revert to the original boot environment with a simple reboot. This switch eliminates the normal downtime of the
test and evaluation process.

Solaris Zones
After the Solaris OS is installed, you can install and configure zones. In a zones environment, the global zone is
the single instance of the operating system that is running and is contained on every Solaris system. The global
zone is both the default zone for the system and the zone that is used for system-wide administrative control.
A non-global zone is a virtualized operating system environment. Solaris Zones are a software partitioning
technology used to virtualize operating system services and provide an isolated and secure environment for
running applications. When you create a zone, you produce an application execution environment in which
processes are isolated from all other zones. This isolation prevents processes that are running in one zone from
monitoring or affecting processes that are running in any other zones. Even a process running in a non-global
zone with superuser credentials cannot view or affect activity in any other zones. A process running in the global
zone with superuser credentials can affect any process in any zone.
The global zone is the only zone from which a non-global zone can be configured, installed, managed, or
uninstalled. Only the global zone is bootable from the system hardware. Administration of the system
infrastructure, such as physical devices, routing, or dynamic reconfiguration (DR), is only possible in the global
zone. Appropriately privileged processes running in the global zone can access objects associated with any or all
other zones.
2.1.2. Hardware Requirements for Installation of the Solaris 10 OE

Perform the following tasks before you begin your installation.
SPARC systems
1. Ensure that you have the following media.
a. For a DVD installation, the Solaris 10 Operating System for SPARC platforms DVD
b. For a CD installation, use Solaris 10 Software CDs.
2. Verify that your system meets the minimum requirements.
3. Your system should meet the following requirements.
a. Memory 128 Mbytes or greater
b. Disk space 12 Gbytes or greater
c. Processor speed 200 MHz or greater
x86 systems
1. Ensure that you have the following media.
a. If you are installing from a DVD, use the Solaris 10 Operating System for x86
platforms DVD.
b. If you are installing from CD media, use Solaris 10 Software CDs.
c. Check your system BIOS to make sure you can boot from CD or DVD media.
2. Verify that your system meets the minimum requirements.
3. Your system should meet the following requirements.
a. Memory 128 Mbytes or greater
b. Disk space 12 Gbytes or greater
c. Processor speed 120 MHz or greater with hardware floating point
2.1.3. Solaris OE Software Groups

Software groups are collections of Solaris OE software packages. Each software group includes support for
different functions and hardware drivers. When you are planning disk space, remember that you can add or
remove individual software packages from the software group that you select.
The Solaris OE is made up of six software groups:
1. Reduced Network Support Software Group
2. Core System Support Software Group
3. End User Solaris Software Group
4. Developer Solaris Software Group
5. Entire Distribution
6. Entire Distribution plus OEM Support

The table summarizes the different Software Groups and their space requirements
Software Group Description Recommended
Disk Space
Entire Solaris Software Contains the packages for the Entire Solaris Software Group 6.7 Gbytes
Group Plus OEM Support plus additional hardware drivers, including drivers for hardware
that is not on the system at the time of installation.
Entire Solaris software Group Contains the packages for the Developer Solaris Software 6.5 Gbytes
Group and additional software that is needed for servers.
Developer Solaris Software Contains the packages for the End User Solaris Software 6.0 Gbytes
Group Group plus additional support for software development. The
additional software development support includes libraries,
include files, man pages, and programming tools. Compilers
are not included.
End User Solaris Software Contains the packages that provide the minimum code that is 5.0 Gbytes
Group required to boot and run a networked Solaris system and the
Common Desktop Environment.
Core System Support Contains the packages that provide the minimum code that is 2.0 Gbytes
Software Group required to boot and run a networked Solaris system.
Reduced Network Support Contains the packages that provide the minimum code that is 2.0 Gbytes
Software Group required to boot and run a Solaris system with limited network
service support. The Reduced Network Support Software
Group provides a multiuser text-based console and system
administration utilities.
This software group also enables the system to recognize
network interfaces, but does not activate network services.
Installation Media
This release has one installation DVD and several installation CDs. The Solaris 10 Operating System DVD
includes the content of all the installation CDs.
Solaris Software 1 This CD is the only bootable CD. From this CD, you can access both the Solaris installation
graphical user interface (GUI) and the console-based installation. This CD also enables you to install selected
software products from both the GUI and the console-based installation.
For both CD and DVD media, the GUI installation is the default (if your system has enough memory). However,
you can specify a console-based installation with the text boot option. The installation process has been
simplified, enabling you to select the language support at boot time, but select locales later.
To install the OS, simply insert the Solaris Software - 1 CD or the Solaris Operating System DVD and type one of
the following commands.
For the default GUI installation (if system memory permits), type boot cdrom.
For the console-based installation, type boot cdrom - text.
Accessing the GUI or Console-based Installations

You can choose to install the software with a GUI or with or without a windowing environment. Given sufficient
memory, the GUI is displayed by default. If the memory is insufficient for the GUI, other environments are
displayed by default. You can override defaults with the nowin or text boot options. But, you are limited by the
amount of memory in your system or by installing remotely. Also, if the Solaris installation program does not
detect a video adapter, the program is automatically displayed in a console-based environment. The following
table describes these environments and lists minimal memory requirements for displaying them.
Detailed descriptions for each installation option are as follows:
Installation with 128383 MB minimal memory

This option contains no graphics, but provides a window and the ability to open other windows. This option
requires a local or remote DVD-ROM or CD-ROM drive or network connection, video adapter, keyboard, and
monitor. If you install by using the text boot option and have enough memory, you are installing in a windowing
environment. If you are installing remotely through a tip line or by using the nowin boot option, you are limited to
the console-based installation.

Installation with 384 MB memory or greater

This option provides windows, pull-down menus, buttons, scrollbars, and iconic images. A GUI requires a local or
remote DVD-ROM or CD-ROM drive or network connection, video adapter, keyboard, and monitor.
2.1.4. Pre-Installation Information

Consider the following general guidelines while planning an installation:
1. Allocate additional space in the /var file system if you plan to have your system support printing or mail.
2. Allocate double the amount of physical memory in the /var file system if you plan to use the crash dump
feature savecore on your system.
3. Allocate additional space in the /export file system if you plan to provide a home directory file system for
users on the Solaris 10 OE.
4. Allocate space for the Solaris software group you want to install.
5. Allocate an additional 30 percent more disk space for each file system that you create, and create a
minimum number of file systems. This leaves room for upgrades to future software releases.
Note By default, the Solaris OE installation methods create only the / (root) file system and the swap partition.
Allocate additional disk space for additional software or third-party software.

Chapter 3 File Systems & Software Management Page 14 of 198
3. File Systems & Software Management

3.1. Directory Hierarchy
3.1.1. Root Subdirectories
A file system can be defined in two ways.
1. One is at the operating system level and the other at the user level.
2. At the OS level a file system is a data structure of a disk slice or other media storage device, which allows
for efficient data storage and management
And at the user level, a file system is nothing but - hierarchical collection of directories, sub-directories and files.
And this hierarchy is called the Directory Hierarchy.
Solaris OE Directory Hierarchy (Its not a complete tree)
3.1.2. File Components

All files in the Solaris OE make use of a file name and a record called an inode. Most files also make use of data
blocks. In general, a file name is associated with an inode, and an inode provides access to data blocks.
File Names
File names are the objects most often used to access and manipulate files. A file must have a name that is
associated with an inode.
Inodes
Inodes are the objects the Solaris OE uses to record information about a file. In general, inodes contain two parts.
First, inodes contain information about the file, including its owner, its permissions, and its size. Second, inodes
contain pointers to data blocks associated with the file. Inodes are numbered, and each file system contains its
own list of inodes. When a new file system is created, a complete list of new inodes is also created in that file
system.
Data Blocks
Data blocks are units of disk space that are used to store data. Regular files, directories, and symbolic links make
use of data blocks. Device files do not hold data.

3.1.3. File Types

There are four main file types
Regular or ordinary files
Directories
Symbolic links
Device files
Use the ls command to distinguish different file types from one another. The character in the first column of
information that the ls l command displays indicates the file type. The following examples, taken from a
SPARC technology Ultra 10 workstation, show partial listings of directories that contain a variety of different file
types:
# cd /etc
# ls -l |more
total 588
lrwxrwxrwx 1 root root 14 Oct 22 11:05 TIMEZONE->
./default/init
drwxr-xr-x 6 root other 512 Oct 22 12:10 X11
drwxr-xr-x 2 adm adm 512 Oct 22 12:41 acct
lrwxrwxrwx 1 root root 14 Oct 22 11:21 aliases ->
./mail/aliases
drwxr-xr-x 7 root bin 512 Oct 22 12:47 apache
drwxr-xr-x 2 root bin 512 Oct 22 12:43 apache2
drwxr-xr-x 2 root other 512 Oct 22 11:53 apoc
-rw-r--r-- 1 root bin 194 Oct 22 11:17 auto_home
-rw-r--r-- 1 root bin 248 Oct 22 11:17 auto_master
(output truncated)
# cd /devices/pci@1f,0/pci@1,1/ide@3
# ls -l|more
total 4
drwxr-xr-x 2 root sys 512 Oct 22 13:11 dad@0,0
brw-r----- 1 root sys 136, 8 Oct 22 13:27 dad@0,0:a
crw-r----- 1 root sys 136, 8 Oct 22 15:25 dad@0,0:a,raw
brw-r----- 1 root sys 136, 9 Oct 22 13:46 dad@0,0:b
(output truncated)
The character in the first column identifies each file type, as follows:
- Regular files
d Directories
l Symbolic links
b Block-special device files
c Character-special device files

Regular File
The above illustrate what a regular file contains and how they can be created.
Directory File
Directories hold a list of file names and the inode numbers associated with them.
3.1.4. Links
There are 2 types of links:
Symbolic link
Hard Link
Symbolic Link:
A symbolic link is a file that points to another file. They contain the path name of the file to which they are
pointing. The size of a symbolic link always matches the number of characters in the path name it contains. In the
following example, the symbolic link called /dev/dsk/c0t0d0s0 points to the physical device
./devices/pci@1f, 0/pci@1, 1/ide@3/dad@0, 0:a. The size of the symbolic link is 46 bytes because
the path name ./devices/pci@1f, 0/pci@1, 1/ide@3/dad@0, 0:a contains 46 characters.
# cd /dev/dsk
# ls -l c0t0d0s0
lrwxrwxrwx 1 root root 46 Oct 22 11:22 c0t0d0s0 ->
../../devices/
pci@1f,0/pci@1,1/ide@3/dad@0,0:a
Creating a Symbolic Link:
The ln command with s option is used to create symbolic links

# ln -s file1 link1
# ls -l link1
lrwxrwxrwx 1 root root 5 Oct 22 15:56 link1 -> file1
From the output, we see that link1 is pointing towards file1. (Symbolic links are similar to short cuts in
Windows).
HARD LINKS
A hard link is the association between a file name and an inode. Information in each inode keeps count of the
number of file names associated with it. This is called a link count. In the output from the ls -l command, the
link count appears between the column of file permissions and the column identifying the owner. In the following
example, the file called alice uses one hard link.
# cd dir1
# touch alice
# ls -l
total 0
-rw-r--r-- 1 root root 0 Oct 22 16:18 alice
A new hard link for a file name increments the link count in the associated inode. For example:
# ln alice humpty-dumpty
# ls -l
total 0
-rw-r--r-- 2 root root 0 Oct 22 16:18 alice
-rw-r--r-- 2 root root 0 Oct 22 16:18 humpty-dumpty
# ls -li
total 0
16601 -rw-r--r-- 2 root root 0 Oct 22 16:18 alice
16601 -rw-r--r-- 2 root root 0 Oct 22 16:18 humpty-
dumpty
# find . -inum 16601
./alice
./humpty-dumpty
The ln command creates new hard links to regular files. Unlike symbolic links, hard links cannot span file
systems.
3.2. Devices
A device file provides access to a device. The inode information of device files holds numbers that point to the
devices. For example:
# cd /devices/pci@1f,0/pci@1
# ls -l
total 4
drwxr-xr-x 2 root sys 512 Oct 22 13:11 pci@2
crw------- 1 root sys 115, 255 Oct 22 16:04 pci@2:devctl
drwxr-xr-x 2 root sys 512 Oct 22 13:11 scsi@1
crw------- 1 root sys 50, 0 Oct 22 16:04 scsi@1:devctl
crw------- 1 root sys 50, 1 Oct 22 16:04 scsi@1:scsi
A long listing shows 2 numbers:
major number
minor number
A major device number identifies the specific device driver required to access a device. A minor device number
identifies the specific unit of the type that the device driver controls.

Device files fall into two categories: character-special devices and block-special devices. Character-special
devices are also called character or raw devices. Block-special devices are often called block devices. Device
files in these two categories interact with devices differently.
Character-Special Device Files

The file type c identifies character-special device files. For disk devices, character-special device files call for
input/output (I/O) operations based on the disks smallest addressable unit, a sector. Each sector is 512 bytes in
size.
Block-Special Device Files
The file type b identifies block-special device files. For disk devices, block-special device files call for I/O
operations based on a defined block size. The block size depends on the particular device, but for UNIX file
systems (ufs), the default block size is 8 Kbytes.
3.2.1. Disk Architecture

One of most important peripherals on any computer system is the mass storage subsystem consisting of disk
drives, tape drives and optical media. Proper system optimization requires understanding of how the mass
storage subsystem is organized.
Formatted disk drives consist of data storage areas called sectors. Each Solaris sector is capable of storing 512
bytes of data. A UNIX filesystem consists of a particular number of sectors that have been bound together by the
newfs command. Before delving deep, let us start by looking at the internal disk layout (the figure below).
Physical Disk Media

A disk drive contains several magnetic surfaces, called platters, which are coated with a thin layer of magnetic
oxide. A typical SCSI disk may contain nine platters. A disk platter is divided into sectors, tracks, and cylinders.
The number of sectors per track varies with the radius of a track on the platter. Because a disk spins continuously
and the read/write heads move as a single unit, the most efficient seeking occurs when the sectors to be read
from or written to are located in a single cylinder.
DEFINITIONS
Sector: The smallest addressable unit on a platter. One sector can hold 512 bytes of data. Sectors are also
known as disk blocks.
Track: A series of sectors positioned end-to-end in a circular path.
Cylinder: A stack of tracks.
Disk Slices
In Solaris, disks are logically divided into individual partitions known as disk slices. Disk slices are groupings of
cylinders that are commonly used to organize data by function. For example, one slice can store critical system
files and programs while another slice on the same disk can store user-created files.

Note Slices are sometimes referred to as partitions. Certain interfaces, such as the format utility, refer to slices
as partitions.
Disk Slice Naming Convention

An eight-character string typically represents the full name of a slice. The string includes the controller number,
the target number, the disk number, and the slice number.
The embedded SCSI configuration and the integrated device electronics (IDE) configuration represent the disk
slice naming conventions across two different architectures. The disk number is always set to d0 with embedded
SCSI disks.
Figure shows the eight-character string that represents the full name of a disk slice.
Controller number: Identifies the host bus adapter (HBA), which controls communications between the system
and disk unit. The HBA takes care of sending and receiving both commands and data to the device. The
controller number is assigned in sequential order, such as c0, c1, c2, and so on.
Target number: Target numbers, such as t0, t1, t2, and t3, correspond to a unique hardware address that is
assigned to each disk, tape, or CD-ROM. Some external disk drives have an address switch located on the rear
panel. Some internal disks have address pins that are jumpered to assign that disks target number.
Disk number: The disk number is also known as the logical unit number (LUN). This number reflects the number
of disks at the target location.
Slice number: A slice number ranging from 0 to 7.
The Figures shown below apply only to SPARC machines. For x86 machines, there is no target number for IDE
architecture. On an IDE disk for an x86 machine, if we want to refer to slice 3 on a disk, which is primary master,
the slice name would be c0d0s3.
Embedded SCSI configuration

IDE Configuration
3.2.2. Device Naming Convention

In the Solaris OE, all devices are represented by three different types of names, depending on how the device is
being referenced:
Logical device names
Physical device names
Instance names
Logical Device Names
Logical disk device names are symbolic links to the physical device names kept in the /devices directory.
Logical device names are used primarily to refer to a device when you are entering commands on the command
line. All logical device names are kept in the /dev directory.
Physical Device Names
Physical device names uniquely identify the physical location of the hardware devices on the system and are
maintained in the /devices directory. A physical device name contains the hardware information, represented
as a series of node names, separated by slashes that indicate the path to the device.
Instance Names
Instance names are abbreviated names assigned by the kernel for each device on the system. An instance name
is a shortened name for the physical device name.
3.2.3. Managing Devices

In the Solaris OE, there are several ways to list a systems devices, including:
1. Using the /etc/path_to_inst file
2. Using the prtconf command
3. Using the format command
The /etc/path_to_inst file
For each device, the system records its physical name and instance name in the /etc/path_to_inst file.
These names are used by the kernel to identify every possible device. This file is read only at boot time.
The prtconf Command

Use the prtconf command to display the systems configuration information, including the total amount of
memory installed and the configuration of system peripherals, which is formatted as a device tree. The prtconf
command lists all possible instances of devices, whether the device is attached or not attached to the system. To
view a list of only attached devices on the system, perform the command:
# prtconf | grep -v not
System Configuration: Sun Microsystems sun4u
Memory size: 512 Megabytes
System Peripherals (Software Nodes):
SUNW,Ultra-5_10
scsi_vhci, instance #0
options, instance #0
pci, instance #0
pci, instance #0
ebus, instance #0
power, instance #0
su, instance #0
su, instance #1
fdthree, instance #0
SUNW,CS4231, instance #0
network, instance #0
SUNW,m64B, instance #0
ide, instance #0
sd, instance #2
dad, instance #1
pseudo, instance #0
The format Command
Use the format command to display both logical and physical device names for all currently available disks. To
view the logical and physical devices for currently available disks, perform the command:
# format
Searching for disks...done
AVAILABLE DISK SELECTIONS:
0. c0t0d0 <ST320413A cyl 38790 alt 2 hd 16 sec 63>
/pci@1f,0/pci@1,1/ide@3/dad@0,0
Specify disk (enter its number):
3.2.4. Reconfiguring Devices

The system recognizes a newly added peripheral device if a reconfiguration boot is invoked or if the devfsadm
command is run.
Performing a Reconfiguration Boot
For example, you can use a boot process to add a new device to a newly generated /etc/path_to_inst file
and to the /dev and /devices directories. The following steps reconfigure a system to recognize a newly
attached disk.
1. Create the /reconfigure file. This file causes the system to check for the presence of any newly
installed devices the next time it is powered on or booted.
# touch /reconfigure
2. Shut down the system by using the init 5 command. This command safely powers off the system, allowing
for addition or removal of devices. (If the device is already attached to your system, you can shut down to
the ok prompt with the command init 0.)
# init 5
3. Turn off the power to all external devices.

4. Install the peripheral device. Make sure that the address of the device being added does not conflict with
the address of other devices on the system.
5. Turn on the power to all external devices.
6. Turn on the power to the system. The system boots to the login window.
7. Verify that the peripheral device has been added by issuing either the prtconf or format command.
After the disk is recognized by the system, begin the process of defining disk slices.
Note If the /reconfigure file was not created before the system was shut down, you can invoke a manual
reconfiguration boot with the programmable read-only memory (PROM) level command: boot -r.
Using the devfsadm Command
Many systems are running critical customer applications on a 24-hour, 7-day-a-week basis. It might not be
possible to perform a reconfiguration boot on these systems. In this situation, you can use the devfsadm
command.
The devfsadm command performs the device reconfiguration process and updates the /etc/path_to_inst
file and the /dev and /devices directories during reconfiguration events.
The devfsadm command attempts to load every driver in the system and attach all possible device instances. It
then creates the device files in the /devices directory and the logical links in the /dev directory. In addition to
managing these directories, the devfsadm command also maintains the /etc/path_to_inst file.
To restrict the operation of the devfsadm command to a specific device class, use the -c option.
# devfsadm -c device_class
The values for device_class include disk, tape, port, audio, and pseudo. For example, to restrict the devfsadm
command to the disk device class, perform the command:
# devfsadm -c disk
Use the -c option more than once on the command line to specify multiple device classes. For example, to
specify the disk, tape, and audio device classes, perform the command:
# devfsadm -c disk -c tape -c audio
To restrict the use of the devfsadm command to configure only devices for a named driver, use the -i option.
# devfsadm -i driver_name
The following examples use the -i option.
To configure only those disks supported by the dad driver, perform the command:
# devfsadm -i dad
To configure only those disks supported by the sd driver, perform the command:
# devfsadm -i sd
To configure devices supported by the st driver, perform the command:
# devfsadm -i st
To print the changes made by the devfsadm command to the /dev and /devices directories perform the
command:
# devfsadm -v
To invoke cleanup routines that remove unreferenced symbolic links for devices, perform the command:
# devfsadm -C
3.2.5. Disk Partitioning

In order to use a disk drive under Solaris, the drive must be partitioned, and the sectors must be bound together
with newfs to form a filesystem. But why are disks partitioned in the first place? In order to understand the need
to partition the disks, it is necessary to review a page of computer history.

At the time UNIX was first released, most machines that ran UNIX used 16-bit hardware. Consequently, a 16-bit
unsigned integer number could address 65,536 sectors on the disk drive. As a result, the disk drive could be no
larger than 65,536 sectors * 512 bytes/sector, or roughly 32Mb.
When large disk drives (300 Mb or more) became available, provisions were made to allow their use on UNIX
systems. The solution was to divide such drives into multiple logical drives, each consisting of 32 MB of data. By
creating several logical drives on a single physical drive, the entire capacity of the 300-Mb disk drive could be
utilized. These logical drives became known as partitions. Each disk drive may have 8 partitions. Under Solaris
the partitions are numbered zero (0) through (7).
Let us look at the other advantages of partioning.
On a system with multiple partitions, the administrator has more control over disk space usage. A user shouldnt
be capable of running the system out of disk space with an errant job. Due to the buffering characteristics of the
Solaris disk drivers, it is often desirable to make multiple partition systems, and place the most active filesystems
in the middle of the disk drive. This allows for more optimal I/O performance, as the disk read-write heads are
certain to pass over these partitions quite often. It is also usually desirable to have the swap space spread across
several drives, and the easy way to do this is to create multiple partitions on the systems disks.
Another reason to create a multiple parition server is to enable control over exported file systems. When the disks
are partitioned, the administrator has better control over which files are exported to other systems, This occurs
because the NFS allows the administrator to export the /opt partition to all hosts without giving those hosts access
to the /usr file system on the server. On single-partition system, the administrator would have to export the entire
disk to other systems, thereby giving the client machines access to files that might be sensitive in nature.
Partitions are also called as slices in Solaris.
A Solaris slice can be used as:
Filesystem
Swap Space
Raw Device
Introducing Disk Partition Tables

As the root user, when you use the format utility and select a disk to partition, a copy of the disks partition table is
read from the label on the disk into memory and is displayed as the current disk partition table.
The format utility also works with a file called /etc/format.dat, which is read when you invoke the format
utility.
The /etc/format.dat file is a table of available disk types and a set of predefined partition tables that you can
use to partition a disk quickly.
3.2.6. Introducing Disk Labels

The disks label is the area set aside for storing information about the disks controller, geometry, and slices.
Another term used to describe a disk label is the volume table of contents (VTOC). The disks label or VTOC is
stored on the first sector of the disk.
To label a disk means to write slice information onto the disk. If you fail to label a disk after defining slices, the
slice information is lost. An important part of the disk label is the partition table, which identifies a disks slices, the
slice boundaries in cylinders, and the total size of the slices.
Note The terms disk slice and disk partition are interchangeable.
3.3. Solaris OE File Systems

3.3.1. Types of File Systems
The Solaris OS supports three types of file systems:
Disk-based
Network-based
Virtual
Disk-Based File Systems

Disk-based file systems are stored on physical media such as hard disks, CD-ROMs, and diskettes. Each type of
disk-based file system is customarily associated with a particular media device, as follows:
UFS with hard disk
HSFS with CD-ROM
PCFS with diskette
UDF with DVD
PCFS with diskette
Network-Based File Systems
The network file system allows users to share files among many types of systems on the network. The NFS file
system makes part of a file system on one system appear as though it were part of the local directory tree.
Virtual File Systems
Virtual file systems are memory-based file systems that provide access to special kernel information and
facilities. Most virtual file systems do not use file system disk space. However, the CacheFS file system uses a file
system on the disk to contain the cache. Also, some virtual file systems, such as the temporary file system
(TMPFS), use the swap space on a disk. CacheFS software provides the ability to cache one file system on
another. In an NFS environment, CacheFS software increases the client per server ratio, reduces server and
network loads, and improves performance for clients on slow links, such as Point-to-Point Protocol (PPP). You
can also combine a CacheFS file system with the AutoFS service to help boost performance and scalability.
Temporary File System
The temporary file system (TMPFS) uses local memory for file system reads and writes. Typically, using memory
for file system reads and writes is much faster than using a UFS file system. Using TMPFS can improve system
performance by saving the cost of reading and writing temporary files to a local disk or across the network. For
example, temporary files are created when you compile a program. The OS generates a much disk activity or
network activity while manipulating these files. Using TMPFS to hold these temporary files can significantly speed
up their creation, manipulation, and deletion. Files in TMPFS file systems are not permanent. These files are
deleted when the file system is unmounted and when the system is shut down or rebooted.
TMPFS is the default file system type for the /tmp directory in the Solaris OS. You can copy or move files into or
out of the /tmp directory, just as you would in a UFS file system. The TMPFS file system uses swap space as a
temporary backing store. If a system with a TMPFS file system does not have adequate swap space, two
problems can occur: The TMPFS file system can run out of space, just as regular file systems do. Because
TMPFS allocates swap space to save file data (if necessary), some programs might not execute because of
insufficient swap space.
The process file system (PROCFS) resides in memory and contains a list of active processes, by process
number, in the /proc directory. Information in the /proc directory is used by commands such as ps. Debuggers
and other development tools can also access the address space of the processes by using file system calls.
Caution Do not delete files in the /proc directory.
Additional, virtual filesystems supported in Solaris are:
CTFS
CTFS (the contract file system) is the interface for creating, controlling, and observing contracts. A contract
enhances the relationship between a process and the system resources it depends on by providing richer error
reporting and (optionally) a means of delaying the removal of a resource. The service management facility (SMF)
uses process contracts (a type of contract) to track the processes that compose a service, so that a failure in a
part of a multi-process service can be identified as a failure of that service.
MNTFS
Provides read-only access to the table of mounted file systems for the local system
OBJFS
The OBJFS (object) file system describes the state of all modules currently loaded by the kernel. This file system
is used by debuggers to access information about kernel symbols without having to access the kernel directly.
SWAPFS
Used by the kernel for swapping

DEVFS
The devfs file system manages devices in this Solaris release. Continue to access all devices through entries in
the /dev directory, which are symbolic links to entries in the /devices directory.
3.3.2. UFS File System

UFS (Unix File System) is the default file system in Solaris.
Logical Components of a UFS filesystem:
Boot Block
Superblock
Cylinder Group Block
Inode Block
Data Block
The above tabulates the features of UFS FileSystem.

Typical UFS Filesystem Structure
Bootblock: This stores the bootable objects that are necessary for booting the system. And though space is
reserved for boot block in all the cylinder groups, only the first cylinder group has bootable information.
Superblock: This stores all the information about the filesystem, like:
Size and status of the file system

Label, which includes the 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 in a cylinder group
Summary data block
File system state
Path name of the last mount point
Because the superblock contains critical data, multiple superblocks are made when the file system is created (and
they are called back-up superblocks).
A summary information block is kept within the superblock. The summary information block is not replicated, but
is grouped with the primary superblock, usually in cylinder group 0. The summary block records changes that take
place as the file system is used. In addition, the summary block lists the number of inodes, directories, fragments,
and storage blocks within the file system.
Inodes: An inode contains all the information about a file except its name, which is kept in a directory. An inode is
128 bytes. The inode information is kept in the cylinder information block, and contains the following:
The type of the file
The mode of the file (the set of read-write-execute permissions)
The number of hard links to the file
The user ID of the owner of the file
The group ID to which the file belongs
The number of bytes in the file
An array of 15 disk-block addresses
The date and time the file was last accessed
The date and time the file was last modified
The date and time the file was created
Data Blocks
Data blocks, also called storage blocks, contain the rest of the space that is allocated to the file system. The size
of these data blocks is determined when a file system is created. By default, data blocks are allocated in two
sizes: an 8-Kbyte logical block size, and a 1-Kbyte fragment size.
Free Blocks
Blocks that are not currently being used as inodes, as indirect address blocks, or as storage blocks are marked as
free in the cylinder group map. This map also keeps track of fragments to prevent fragmentation from degrading
disk performance.
Customizing UFS File System Parameters
Logical Block Size

The logical block size is the size of the blocks that the UNIX kernel uses to read or write files. The logical block
size is usually different from the physical block size. The physical block size is usually 512 bytes, which is the size
of the smallest block that the disk controller can read or write. Logical block size is set to the page size of the
system by default. The default logical block size is 8192 bytes (8 Kbytes) for UFS file systems. The UFS file
system supports block sizes of 4096 or 8192 bytes (4 or 8 Kbytes). The recommended logical block size is 8
Kbytes.
To choose the best logical block size for your system, consider both the performance you want and the available
space. For most UFS systems, an 8-Kbyte file system provides the best performance, offering a good balance
between disk performance and the use of space in primary memory and on disk.
As a general rule, to increase efficiency, use a larger logical block size for file systems when most of the files are
very large. Use a smaller logical block size for file systems when most of the files are very small. You can use the
quot -c filesystem command on a file system to display a complete report on the distribution of files by block size.
However, the page size set when the file system is created is probably the best size in most cases.
Fragment Size

As files are created or expanded, they are allocated disk space in either full logical blocks or portions of logical
blocks called fragments. When disk space is needed for a file, full blocks are allocated first, and then one or
more fragments of a block are allocated for the remainder. For small files, allocation begins with fragments. The
ability to allocate fragments of blocks to files, rather than just whole blocks, saves space by reducing
fragmentation of disk space that results from unused holes in blocks. You define the fragment size when you
create a UFS file system. The default fragment size is 1 Kbyte. Each block can be divided into 1, 2, 4, or 8
fragments, which results in fragment sizes from 8192 bytes to 512 bytes (for 4-Kbyte file systems only). The lower
bound is actually tied to the disk sector size, typically 512 bytes.
For multiterabyte file systems, the fragment size must be equal to the file system block size.
Note The upper bound for the fragment is the logical block size, in which case the fragment is not a fragment at
all. This configuration might be optimal for file systems with very large files when you are more concerned with
speed than with space. When choosing a fragment size, consider the trade-off between time and space: A small
fragment size saves space, but requires more time to allocate. As a general rule, to increase storage efficiency,
use a larger fragment size for file systems when most of the files are large. Use a smaller fragment size for file
systems when most of the files are small.
Minimum Free Space
The minimum free space is the percentage of the total disk space that is held in reserve when you create the file
system. The default reserve is ((64 Mbytes/partition size) * 100), rounded down to the nearest integer and limited
between 1 percent and 10 percent, inclusively. Free space is important because file access becomes less and
less efficient as a file system gets full. As long as an adequate amount of free space exists, UFS file systems
operate efficiently. When a file system becomes full, using up the available user space, only root can access the
reserved free space.
Commands such as df report the percentage of space that is available to users, excluding the percentage
allocated as the minimum free space. When the command reports that more than 100 percent of the disk space in
the file system is in use, some of the reserve has been used by root. If you impose quotas on users, the amount
of space available to them does not include the reserved free space. You can change the value of the minimum
free space for an existing file system by using the tunefs command.
Optimization Type
The optimization type parameter is set to either space or time.
Space When you select space optimization, disk blocks are allocated to minimize fragmentation and disk use is
optimized.
Time When you select time optimization, disk blocks are allocated as quickly as possible, with less emphasis on
their placement. When sufficient free space exists, allocating disk blocks is relatively easy, without resulting in too
much fragmentation. The default is time.
You can change the value of the optimization type parameter for an existing file system by using the tunefs
command.
Number of Inodes (Files)
The number of bytes per inode specifies the density of inodes in the file system. The number is divided into the
total size of the file system to determine the number of inodes to create. Once the inodes are allocated, you
cannot change the number without re-creating the file system. The default number of bytes per inode is 2048
bytes (2 Kbytes) if the file system is less than 1 Gbyte. If the file system is larger than 1 Gbyte, the following
formula is used:
If you have a file system with many symbolic links, they can lower the average file size. If your file system is going
to have many small files, you can give this parameter a lower value. Note, however, that having too many inodes
is much better than running out of inodes. If you have too few inodes, you could reach the maximum number of
files on a disk slice that is practically empty.
Maximum UFS File and File System Size
The maximum size of a UFS file system is about 16 Tbytes of usable space, minus about one percent overhead.
A sparse file can have a logical size of one terabyte. However, the actual amount of data that can be stored in a
file is approximately one percent less than 1 Tbyte because of the file system overhead.
Maximum Number of UFS Subdirectories

The maximum number of subdirectories per directory in a UFS file system is 32,767. This limit is predefined and
cannot be changed.
Note on UFS logging
In some operating systems, a file system with logging enabled is known as a journaling file system.
UFS Logging
UFS logging bundles the multiple metadata changes that comprise a complete UFS operation into a transaction.
Sets of transactions are recorded in an on-disk log. Then, they are applied to the actual UFS file systems
metadata. At reboot, the system discards incomplete transactions, but applies the transactions for completed
operations. The file system remains consistent because only completed transactions are ever applied. This
consistency remains even when a system crashes. A system crash might interrupt system calls and introduces
inconsistencies into a UFS file system.
UFS logging provides two advantages: If the file system is already consistent due to the transaction log, you might
not have to run the fsck command after a system crash or an unclean shutdown. UFS logging improves or
exceeds the level of performance of non logging file systems. This improvement can occur because a file system
with logging enabled converts multiple updates to the same data into single updates. Thus, reduces the number
of overhead disk operations required.
The UFS transaction log has the following characteristics:
Is allocated from free blocks on the file system
Sized at approximately 1 Mbyte per 1 Gbyte of file system, up to a maximum of 64 Mbytes
Continually flushed as it fills up
Planning UFS File Systems
When laying out file systems, you need to consider possible conflicting demands. Here are some suggestions:
Distribute the workload as evenly as possible among different I/O systems and disk drives. Distribute the
/export/home file system and swap space evenly across disks.
Keep pieces of projects or members of groups within the same file system.
Use as few file systems per disk as possible. On the system (or boot) disk, you should have three file
systems: root (/), /usr, and swap space. On other disks, create one or at most two file systems; with
one file system preferrably being additional swap space. Fewer, roomier file systems cause less file
fragmentation than many small, over crowded file systems. Higher-capacity tape drives and the ability of
the ufsdump command to handle multiple volumes make it easier to back up larger file systems.
If you have some users who consistently create very small files, consider creating a separate file system
with more inodes. However, most sites do not need to keep similar types of user files in the same file
system.
Features of Format Command
Creating a UFS FileSystem

1. You must define a slice.

2. Create the UFS file system.

# newfs [-N] [-b size] [-i bytes] /dev/rdsk/device-name
-N Displays what parameters the newfs command would pass to the mkfs command without actually
creating the file system. This option is a good way to test the newfs command.
-b size Specifies the block size for the file system, either 4096 or 8192 bytes per block. The default is
8192.
-i bytes Specifies the number of bytes per inode. The default varies depending on the disk size.
device-name Specifies the disk device name on which to create the new file system.
The system asks for confirmation.
Caution Be sure you have specified the correct device name for the slice before. After creating filesystems, we
can access it by mounting.
3.3.3. File System Maintenance

The UNIX filesystem is reliable, and it does a remarkable job of coping with unexpected system crashes.
However, filesystems can become damaged or inconsistent in a number of ways. Any time the kernel panics or
the power fails, small inconsistencies may be introduced into the filesystems that were active immediately
preceding the crash. Since the kernel buffers both data blocks and summary information, the most recent image
of the filesystem is split between disk and memory. During a crash, the memory portion of the image is lost. The
buffered blocks are effectively overwritten with the versions that were most recently saved to disk.
For fixing some common inconsistencies we have the fsck command (filesystem consistency check, spelled
aloud or pronounced fs check or fisk).
The most common types of damage fsck can repair are:
1. Unreferenced inodes
2. Inexplicably large link counts
3. Unused data blocks not recorded in the block maps
4. Data blocks listed as free that are also used in a file
5. Incorrect summary information in the superblock
fsck can safely and automatically fix these five problems. If fsck makes corrections to a filesystem, you should
rerun it until the filesystem comes up completely clean.
Disks are normally checked at boot time with fsck p, which examines all local filesystems listed in
/etc/vfstab and corrects the five errors listed above. It accepts both block and character (raw) devices; it
usually runs faster on the raw device. Errors that dont fall into one of the 5 categories above are potentially
serious. They cause fsck p to ask for help and then quit. In this case, run fsck without the p option. When
run in manual mode, fsck asks you to confirm each of the repairs that it wants to make.
Few of the errors, which it considers dangerous, are:
1. Blocks claimed by more than one file
2. Blocks claimed outside the range of the filesystem.
3. Link counts that are too small
4. Blocks that are not accounted for
5. Directories that refer to unallocated inodes
6. Various format errors
If fsck knows only the inode number of a file, you can use the ncheck command on some systems to discover
the files pathname. To zero out a bad inode that fsck isnt able to fix, use the clri command (the data will be
lost).
If fsck finds a file whose parent directory cant be determined, it will put the file in the lost+found directory in
the top level of the filesystem. Since the name given to a file is recorded only in the files parent directory, names
for orphan files will not be available and the files placed in lost+found will be named with their inode numbers.

3.3.4. Monitoring File System Usage

This table summarizes the commands available for displaying information about file size and disk space.

3.4. Mounting and Unmounting File Systems
The table above displays the Solaris filesystems and their mount points.
3.4.1. Mounting Fundamentals

In the Solaris OE, you use the mounting process to attach individual file systems to their mount points on the
directory hierarchy. This action makes a file system accessible to the system and to the users. You use the
unmounting process to detach a file system from its mount point in the directory hierarchy. This action makes a
file system unavailable to the system or users.
Introducing the Virtual File System Table: /etc/vfstab

The /etc/vfstab file lists all the file systems to be automatically mounted at system boot time. The file format
includes seven fields per line entry. By default, a tab separates each field, but any whitespace can be used for
separators. The dash (-) character is used as a placeholder for fields when text arguments are not appropriate.
To add a line entry, you need the following information:
device to mount The device to be mounted. For example, a local ufs file system /dev/dsk/c#t#d#s#, or
a
pseudo file system /proc.
device to fsck The raw or character device checked by the file system check program (fsck) if applicable.
A
pseudo file system has a dash (-) in this field.
mount point The name of the directory that serves as the attach mount point in the Solaris OE directory
hierarchy.
FS type The type of file system to be mounted.
fsck pass Indicates whether the file system is to be checked by the fsck utility at boot time. A 0
(zero) or a nonnumeric in this field indicates no. A 1 in this field indicates the fsck utility
gets
started for that entry and runs to completion. A number greater than 1 indicates that the
device
is added to the list of devices to have the fsck utility run. The fsck utility can run on up to
eight
devices in parallel. This field is ignored by the mountall command.
mount at boot Enter yes to enable the mountall command to mount the file systems at boot time. Enter
no to
prevent a file system mount at boot time.
mount options A comma-separated list of options passed to the mount command. A dash (-) indicates the
use of default mount options.
Note For / (root), /usr, and /var (if it is a separate file system) file systems, the mount at boot field value is
specified as no. The kernel mounts these file systems as part of the boot sequence before the mountall command
is run.
Introducing the /etc/mnttab File
The /etc/mnttab file is really an mntfs file system that provides read-only information directly from the kernel
about mounted file systems on the local host. Each time a file system is mounted, the mount command adds an
entry to this file. Whenever a file system is unmounted, its entry is removed from the /etc/mnttab file.
Mount Point The mount point or directory name where the file system is to be attached within the / (root) file
system (for example, /usr, /opt).
Device Name The name of the device that is mounted at the mount point. This block device is where the file
system is physically located.
Mount Options The list of mount options in effect for the file system.
dev=number The major and minor device number of the mounted file system.
Date and Time The date and time that the file system was mounted to the directory hierarchy.
Mounting a Local File System Manually

The mount command not only lists, which file systems, are currently mounted, it also provides you, as the root
user, with a method for mounting file systems.
Default Behavior of the mount Command
To mount a local file system manually, you need to know the name of the device where the file system resides
and its mount point directory name. Perform the command:
# mount /dev/dsk/c0t0d0s7 /export/home

In this example, the default action mounts the file system with the following options: read/write, setuid, intr,
nologging, and largefiles, xattr, and onerror. The following list explains the default options for the mount
command.
read/write Indicates whether reads and writes are allowed on the file system.
setuid Permits the execution of setuid programs in the file system.
intr/nointr Allows and forbids keyboard interrupts to kill a process that is waiting for an operation on a
locked
file system.
nologging Indicates that logging is not enabled for the ufs file system.
largefiles Allows for the creation of files larger than 2 Gbytes. A file system mounted with this option can
contain files larger than 2 Gbytes.
xattr Supports extended attributes not found in standard UNIX attributes.
onerror=action Specifies the action that the ufs file system should take to recover from an internal
inconsistency on
a file system. An action can be specified as:
panic Causes a forced system shutdown. This is the default.
lock Applies a file system lock to the file system.
umount Forcibly unmounts the file system.
The /etc/vfstab file provides you with another important feature. Because the /etc/vfstab file contains the mapping
between the mount point and the actual device name, the root user can manually mount by just specifying the
mount point.
# mount /export/home
3.4.2. Volume Management

Essentially, volume management enables you to access removable media just as manual mounting does, but
more easily and without the need for superuser access. To make removable media easier to work with, you can
mount removable media in easy-to-remember locations.
Troubleshooting Volume Management Problems:
If CD-ROM fails to eject from the drive, as the root user attempt to stop Volume Management. If this is
unsuccessful, kill the vold daemon.
# /etc/init.d/volmgt stop
or as a last resort:
# pkill -9 vold
Push the button on the system to eject the CD-ROM. The CD-ROM tray ejects. Remove the CD-ROM, and leave
the tray out. Then restart the Volume Management service.
# /etc/init.d/volmgt start
Wait a few seconds, and then push the CD-ROM tray back into the drive.
Accessing a Diskette or CD-ROM without Volume Management:
When Volume Management is not running, only the root user can mount and access a diskette or CD-ROM.
Follow these steps:
Insert the media device.
Become the root user.
Create a mount point, if necessary.

Determine the file system type.

1. Mount the device by using the appropriate mount options.
2. Work with files on the media device.
3. Unmount the media device.
4. Eject the media device.
5. Exit the root session.
Using the mount Command
To mount a file system that resides on a CD-ROM when the Volume Management services are stopped, as the
root user, perform the command:
# mount -F hsfs -o ro /dev/dsk/c0t6d0s0 /cdrom
In this example, the file system type is hsfs, the file system resides on disk slice /dev/dsk/c0t6d0s0, and the
mount point /cdrom is a pre-existing directory in the Solaris OE. To mount a file system that resides on a diskette
when the Volume Management services are stopped, as the root user, perform the command:
# mkdir /pcfs
# mount -F pcfs /dev/diskette /pcfs
In this example, the file system type is pcfs. This file system resides on the /dev/diskette device, and the mount
point used is /pcfs.
3.5. Package Administration

Overview of Software Packages
Software management involves installing or removing software products. Sun and its third-party vendors deliver
software products in a form called a package. The term packaging generically refers to the method for distributing
and installing software products to systems where the products will be used. A package is a collection of files and
directories in a defined format. This format conforms to the application binary interface (ABI), which is a
supplement to the System V Interface Definition. The Solaris OS provides a set of utilities that interpret this format
and provide the means to install a package, to remove a package, or to verify a package installation.
A patch is a collection of files and directories that replace or update existing files and directories that are
preventing proper execution of the existing software.
Signed Packages and Patches
Packages can include a digital signature. A package with a valid digital signature ensures that the package has
not been modified since the signature was applied to the package. Using signed packages is a secure method of
downloading or adding packages because the digital signature can be verified before the package is added to
your system.
The same holds true for signed patches. A patch with a valid digital signature ensures that the patch has not been
modified since the signature was applied to the patch. Using signed patches is a secure method of downloading
or applying patches because the digital signature can be verified before the patch is applied to your system.
A signed package is identical to an unsigned package, except for the digital signature. The package can be
installed, queried, or removed with existing Solaris packaging tools. A signed package is also binary-compatible
with an unsigned package.
Before you can use pkgadd and patchadd to add a package or patch with a digital signature to your system,
you must set up a package keystore with trusted certificates. These certificates are used to identify that the digital
signature on the package or patch is valid. Note that the keystore and certificates are automatically set up when
you use Patch Manager to apply signed patches.
The following describes the general terms associated with signed packages and patches.
Keystore A repository of certificates and keys that is queried when needed.
1. Java keystore A repository of certificates that is installed by default with the Solaris release. The Java
keystore is usually stored in the /usr/j2se/jre/lib/security directory.
2. Package keystore A repository of certificates that you import when adding signed packages and
patches to your system. The package keystore is stored in the /var/sadm/security directory by
default.

Trusted certificate A certificate that holds a public key that belongs to another entity. The trusted certificate is
named as such because the keystore owner trusts that the public key in the certificate indeed belongs to the
identity identified by the subject or owner of the certificate. The issuer of the certificate vouches for this trust by
signing the certificate. Trusted certificates are used when verifying signatures, and when initiating a connection to
a secure (SSL) server.
User key Holds sensitive cryptographic key information. This information is stored in a protected format to
prevent unauthorized access. A user key consists of both the users private key and the public key certificate that
corresponds to the private key. The process of using the pkgadd or patchadd command to add a signed
package or patch to your system involves three basic steps:
1. Adding the certificates to your systems package keystore by using the pkgadm command
2. (Optional) Listing the certificates by using the pkgadm command
3. Adding the package with the pkgadd command or applying the patch by using the patchadd
command
If you use Patch Manager to apply patches to your system, you do not need to manually set up the keystore and
certificates, as it is automatically set up.
Using Suns Certificates to Verify Signed Packages and Patches
Digital certificates, issued and authenticated by Sun Microsystems, are used to verify that the downloaded
package or patch with the digital signature has not been compromised. These certificates are imported into your
systems package keystore. A stream-formatted SVR4-signed package or patch contains an embedded PEM-
encoded PKCS7 signature. This signature contains at a minimum the encrypted digest of the package or patch,
along with the signers X.509 public key certificate. The package or patch can also contain a certificate chain that
is used to form a chain of trust from the signers certificate to a locally stored trusted certificate.
The PEM-encoded PKCS7 signature is used to verify the following information:
1. The package came from the entity that signed it.
2. The entity indeed signed it.
3. The package hasnt been modified since the entity signed it.
4. The entity that signed it is a trusted entity.
All Sun certificates are issued by Baltimore Technologies, which recently bought GTE CyberTrust.
Access to a package keystore is protected by a special password that you specify when you import the Sun
certificates into your systems package keystore. If you use the pkgadm listcert command, you can view
information about your locally stored certificates in the package keystore. For example:
# pkgadm listcert -P pass:store-pass
Keystore Alias: GTE CyberTrust Root
Common Name: GTE CyberTrust Root
Certificate Type: Trusted Certificate
Issuer Common Name: GTE CyberTrust Root
Validity Dates: <Feb 23 23:01:00 1996 GMT> - <Feb 23 23:59:00 2006 GMT>
MD5 Fingerprint: C4:D7:F0:B2:A3:C5:7D:61:67:F0:04:CD:43:D3:BA:58
SHA1 Fingerprint: 90:DE:DE:9E:4C:4E:9F:6F:D8:86:17:57:9D:D3:91:BC:65:A6...
The following describes the output of the pkgadm listcert command.
Keystore Alias When you retrieve certificates for printing, signing, or removing, this name must be used to
reference the certificate.
Command Name The common name of the certificate. For trusted certificates, this name is the same as the
keystore alias.
Certificate Type Can be one of two types:
1. Trusted certificate A certificate that can be used as a trust anchor when verifying other certificates. No
private key is associated with a trusted certificate.
2. Signing certificate A certificate that can be used when signing a package or patch. A private key is
associated with a signing certificate.

Issuer Command Name The name of the entity that issued, and therefore signed, this certificate. For trusted
certificate authority (CA) certificates, the issuer common name and common name are the same.
Validity Dates A date range that identifies when the certificate is valid.
MD5 Fingerprint An MD5 digest of the certificate. This digest can be used to verify that the certificate has not
been altered during transmission from the source of the certificate.
SHA1 Fingerprint Similar to an MD5 fingerprint, except that it is calculated using a different algorithm.
Each certificate is authenticated by comparing its MD5 and SHA1 hashes, also called fingerprints, against the
known correct fingerprints published by the issuer.
Importing Suns Trusted Certificates
You can obtain Suns trusted certificates for adding signed packages and patches in the following ways:
Java keystore Import Suns Root CA certificate that is included by default in the Java keystore when you install
the Solaris release.
Suns Public Key Infrastructure (PKI) site If you do not have a Java keystore available on your system, you can
import the certificates from this site. https://ra.sun.com:11005/
PatchPros keystore If you have installed PatchPro for applying signed patches with the smpatch command, you
can import Suns Root CA certificate from the Java keystore.
Setting Up a Package Keystore
In previous Solaris releases, you could download the patch management tools and create a Java keystore, for
use by PatchPro, by importing the certificates with the keytool command.
If your system already has a populated Java keystore, you can now export the Sun Microsystems root CA
certificate from the Java keystore with the keytool command. Then, use the pkgadm command to import this
certificate into the package keystore. After the Root CA certificate is imported into the package keystore, you can
use the pkgadd and patchadd commands to add signed packages and patches to your system.
Note The Sun Microsystems root-level certificates are only required when adding Sun-signed patches and
packages.
Tools for Managing Software Packages
The following table describes the tools for adding and removing software packages from a system after the
Solaris release is installed on a system.

Adding or Removing a Software Package (pkgadd)

All the software management tools that are listed in the above table are used to add, remove, or query information
about installed software. The Solaris Product Registry prodreg viewer and the Solaris installation GUI both access
install data that is stored in the Solaris Product Registry. The package tools, such as the pkgadd and pkgrm
commands, also access or modify install data.
When you add a package, the pkgadd command uncompresses and copies files from the installation media to a
local systems disk. When you remove a package, the pkgrm command deletes all files associated with that
package, unless those files are also shared with other packages.
Package files are delivered in package format and are unusable as they are delivered.
The pkgadd command interprets the software packages control files, and then uncompresses and installs the
product files onto the systems local disk.

Although the pkgadd and pkgrm commands do not log their output to a standard location, they do keep track of
the package that is installed or removed. The pkgadd and pkgrm commands store information about a package
that has been installed or removed in a software product database.
By updating this database, the pkgadd and pkgrm commands keep a record of all software products installed
on the system.
Key Points for Adding Software Packages (pkgadd)
Keep the following key points in mind before you install or remove packages on your system:
1. Package naming conventions Sun packages always begin with the prefix SUNW, as in SUNWaccr,
SUNWadmap, and SUNWcsu. Third-party packages usually begin with a prefix that corresponds to the
companys stock symbol.
2. What software is already installed You can use the Solaris installation GUI, Solaris Product Registry
prodreg viewer (either GUI or CLI) or the pkginfo command to determine the software that is already
installed on a system.
3. How servers and clients share software Clients might have software that resides partially on a server
and partially on the client. In such cases, adding software for the client requires that you add packages to
both the server and the client.
Guidelines for Removing Packages (pkgrm)
You should use one of the tools listed in the above table to remove a package, even though you might be tempted
to use the rm command instead. For example, you could use the rm command to remove a binary executable
file. However, doing so is not the same as using the pkgrm command to remove the software package that
includes that binary executable. Using the rm command to remove a packages files will corrupt the software
products database. If you really only want to remove one file, you can use the removef command. This
command will update the software product database correctly so that the file is no longer a part of the package.
For more information, see the removef(1M) man page.
If you intend to keep multiple versions of a package, install new versions into a different directory than the already
installed package by using the pkgadd command.
For example, if you intended to keep multiple versions of a document processing application. The directory where
a package is installed is referred to as the base directory. You can manipulate the base directory by setting the
basedir keyword in a special file called an administration file. For more information on using an administration
file and on setting the base directory, see the Avoiding User Interaction When Adding Packages (pkgadd) on
page 266 and admin(4) man page.
Note If you use the upgrade option when installing Solaris software, the Solaris installation software checks the
software product database to determine the products that are already installed on the system.
Avoiding User Interaction When Adding Packages (pkgadd)
This section provides information about avoiding user interaction when adding packages with the pkgadd
command.
Using an Administration File
When you use the pkgadd -a command, the command consults a special administration file for information
about how the installation should proceed. Normally, the pkgadd command performs several checks and
prompts the user for confirmation before it actually adds the specified package. You can, however, create an
administration file that indicates to the pkgadd command that it should bypass these checks and install the
package without user confirmation.
The pkgadd command, by default, checks the current working directory for an administration file. If the pkgadd
command doesnt find an administration file in the current working directory, it checks the
/var/sadm/install/admin directory for the specified administration file. The pkgadd command also
accepts an absolute path to the administration file.
Note Use administration files judiciously. You should know where a packages files are installed and how a
packages installation scripts run before using an administration file to avoid the checks and prompts that the
pkgadd command normally provides.
The following example shows an administration file that prevents the pkgadd command from prompting the user
for confirmation before installing the package.

mail=
instance=overwrite
partial=nocheck
runlevel=nocheck
idepend=nocheck
rdepend=nocheck
space=nocheck
setuid=nocheck
conflict=nocheck
action=nocheck
networktimeout=60
networkretries=3
authentication=quit
keystore=/var/sadm/security
proxy=
basedir=default
Besides using administration files to avoid user interaction when you add packages, you can use them in several
other ways. For example, you can use an administration file to quit a package installation (without user
interaction) if theres an error or to avoid interaction when you remove packages by using the pkgrm command.
You can also assign a special installation directory for a package, which you might do if you wanted to maintain
multiple versions of a package on a system. To do so, set an alternate base directory in the administration file by
using the basedir keyword. The keyword specifies where the package will be installed. For more information,
see the admin(4) man page.
Using a Response File (pkgadd)
A response file contains your answers to specific questions that are asked by an interactive package. An
interactive package includes a request script that asks you questions prior to package installation, such as
whether optional pieces of the package should be installed.
If you know prior to installation that the package is an interactive package, and you want to store your answers to
prevent user interaction during future installations, use the pkgask command to save your response. For more
information on this command, see pkgask(1M).
Once you have stored your responses to the questions asked by the request script, you can use the pkgadd -
r command to install the package without user interaction.
3.6. Patch Administration

A patch is a collection of files and directories that replace or update existing files and directories that are
preventing proper execution of the existing software.
Patch management involves applying Solaris patches to a system. Patch management might also involve
removing unwanted or faulty patches. Removing patches is also called backing out patches.
A patch is a collection of files and directories that replaces or updates existing files and directories that are
preventing proper execution of the existing software. The existing software is derived from a specified package
format.
Signed and Unsigned Patches
A signed patch is one that has a digital signature applied to it. A patch that has its digital signature verified has not
been modified since the signature was applied. The digital signature of a signed patch is verified after the patch is
downloaded to your system. Patches for the Solaris 2.6, Solaris 7, Solaris 8, Solaris 9, and Solaris 10 releases
are available as signed patches and as unsigned patches. Unsigned patches do not have a digital signature.
Signed patches are stored in Java archive format (JAR) files and are available from the SunSolve OnlineSM web
site. Unsigned patches are stored in directory format and are also available from the SunSolve Online web site as
.zip files.
Solaris Patch Numbering

Patches are identified by unique patch IDs. A patch ID is an alphanumeric string that is a patch base code and a
number that represents the patch revision number joined with a hyphen. For example, patch 108528-10 is the
patch ID for the SunOS 5.8 kernel update patch.
Managing Solaris Patches
When you apply a patch, the patch tools call the pkgadd command to apply the patch packages from the patch
directory to a local systems disk.
Caution Do not run the pkgadd command directly to apply patches.
More specifically, the patch tools do the following:
1. Determine the Solaris version number of the managing host and the target host
2. Update the patch packages pkginfo file with this information:
Patches that have been obsoleted by the patch being applied
Other patches that are required by this patch
Patches those are incompatible with this patch
While you apply patches, the patchadd command logs information in the /var/sadm/patch/patch-
id/log file.
3. The patchadd command cannot apply a patch under the following conditions:
The package is not fully installed on the system.
The patch packages architecture differs from the systems architecture.
The patch packages version does not match the installed packages version.
A patch with the same base code and a higher revision number has already been applied.
A patch that obsoletes this patch has already been applied.
The patch is incompatible with a patch that has already been applied to the system. Each patch that has
been applied keeps this information in its pkginfo file.
The patch being applied depends on another patch that has not yet been applied.

Chapter 4 Startup & Shutdown Page 41 of 198
4. Startup and Shutdown

4.1. Boot PROM
4.1.1. Boot PROM Fundamentals
All Sun systems have resident boot PROM firmware that provides basic hardware testing and initialization prior to
booting. The boot PROM also enables you to boot from a wide range of devices. In addition, there is a user
interface that provides several important functions.
The OpenBoot Architecture Standard
The overall goal of the Institute of Electrical and Electronics Engineers (IEEE) standard for the OpenBoot
architecture is to provide the capabilities to:
1. Test and initialize system hardware.
2. Determine the systems hardware configuration.
3. Boot the operating environment.
4. Provide an interactive interface for configuration, testing, and debugging.
5. Enable the use of third-party devices.
Boot PROM
Each Sun system has a boot PROM chip. The main functions of the boot PROM are to test the system hardware
and to boot the operating environment (Sun calls its operating system as the Solaris Operating Environment
Solaris OE). The boot PROM firmware is referred to as the monitor program.
The boot PROM firmware controls the operation of the system before the operating environment has been booted
and the kernel is available. The boot PROM also provides the user with a user interface and firmware utility
commands, known as the FORTH command set. Commands include the boot commands, diagnostics
commands, and commands to modify the default configuration.
NVRAM
Another important hardware element in each Sun system is the NVRAM chip. This removable chip is often
located on the main system board. The NVRAM module contains the electronically erasable programmable read-
only memory (EEPROM). The EEPROM stores user-configurable parameters that have been changed or
customized from the boot PROMs default parameters settings. This behavior gives you a certain level of flexibility
in configuring the system to behave in a particular manner for a specific set of circumstances. A single lithium
battery within the NVRAM module provides battery backup for the NVRAM and the clock. The NVRAM contains
editable and noneditable areas. The noneditable area includes the following:
The Ethernet address, such as 8:0:20:5d:6f:9e
The system host ID value, such as 805d6f9e
The editable area includes the following:
The time-of-day (TOD) clock value
The configuration data describing system operating parameters
The device name and the path to the default boot device, etc
Note Remember to retain the NVRAM chip, because it contains the host ID. Many licensed software packages
are based on the system host ID. The NVRAM chip has a yellow sticker with a bar code on it. If the chip fails, Sun
can replace the chip if given the numbers below this bar code. The replacement chip has the same host ID and
Ethernet address. It can be plugged into the same location on the motherboard as the chip it is replacing.
POST
When a systems power is turned on, a low-level POST is initiated. This low-level POST code is stored in the boot
PROM and is designed to test the most basic functions of the system hardware. At the successful completion of
the low-level POST phase, the boot PROM firmware takes control and performs the following initialization
sequence:
Probes the memory and then the CPU
Probes bus devices, interprets their drivers, and builds a device tree

Installs the console

After the boot PROM initializes the system, the banner displays on the console. The system checks parameters
stored in the boot PROM and NVRAM to determine if and how to boot the operating environment.
Controlling the POST Phase
One of the first tests that POST runs is to check to determine if a keyboard is connected to the system and if a
Stop-key option is present.
Note You can control the POST phase through the Sun keyboard only. The Stop key is located on the left side
of the keyboard. To enable various diagnostic modes, hold down the Stop key simultaneously with another key.
The Stop-key sequences have an effect on the OpenBoot PROM and define how POST runs when a systems
power is turned on. The following is a list of the Stop-key sequences:
1. Stop-D key sequence Hold down the Stop and D keys simultaneously while system power is turned on,
and the firmware automatically switches to diagnostic mode. This mode runs more extensive POST
diagnostics on the system hardware. The OpenBoot PROM variable diag-switch? is set to true.
2. Stop-N key sequence Hold down the Stop and N keys simultaneously while the system power is turned
on to set the NVRAM parameters to the default values. When you see the light emitting diodes (LEDs) on
the keyboard begin to flash, you can release the keys, and the system should continue to boot. Incorrect
NVRAM settings can cause system boot failure. For example, during a flash PROM download, if a power
failure occurs, some of the contents of the NVRAM can become unusable. If the system does not boot
and you suspect that the NVRAM parameters are set incorrectly, the parameters can easily be changed
to the default values.
3. Stop-A key sequence Hold down the Stop and A keys simultaneously to interrupt any program that is
running at the time these keys are pressed and to put the system into the command entry mode for the
OpenBoot PROM. The system presents an ok prompt for the user, which signifies it is ready to accept
OpenBoot PROM commands.
Caution The Stop-A key sequence, as a method for getting to the ok prompt, is not recommended unless there
is absolutely no alternative. The Stop-A key sequence can cause Solaris OE file system corruption that can be
difficult to repair.
4.1.2. Basic Boot PROM Commands

The boot PROM monitor provides a user interface for invoking OpenBoot commands. The following are the
frequently used commands:
banner Displays the power-on banner
boot Boots the system
help Lists the main help categories
words Displays the FORTH words in the dictionary
sifting <text> Displays the FORTH commands containing text
printenv Displays all parameters current and default values
setenv Sets the specified NVRAM parameter to some value
reset-all Resets the entire system; software stimulated reset
set-defaults Resets all parameter values to the factory defaults
probe-ide Identifies devices on the internal integrated device electronics (IDE) bus
probe-scsi Identifies the devices on the internal Small Computer System Interface (SCSI) bus
probe-scsi-all Identifies the devices on all SCSI buses
probe-fcal-all Identifies devices on all Fiber Channel loops
.version Displays the version and the date of the boot PROM
probe-pci Probes all devices on a specific peripheral component interconnect (PCI) bus
probe-pci-slot Probes a specific PCI slot on a specific PCI bus

test Runs self-tests on specified devices

.enet-addr Displays the Ethernet address
.idprom Displays the ID PROM contents
.speed Displays the speed of the processor and of the buses attached to the system
.registers Displays the contents of the registers
4.1.3. Listing NVRAM Parameters

Use the printenv command to list all the NVRAM parameters. If the parameter can be modified, the printenv
command displays its default setting and current setting.
setenv is used for changing the NVRAM parameters.
Viewing and Changing NVRAM Parameters from the Shell
Use the /usr/sbin/eeprom command to view and to change the NVRAM parameters while the Solaris OE is
running.
Be aware of the following guidelines when using the eeprom command:
Only the root user can change the value of a parameter.
You must enclose parameters with a trailing question mark in single quotation marks (single quotes)
when the command is executed in the C shell.
All changes are permanent. You cannot run a reset command to undo the parameter changes.
4.1.4. Interrupting an Unresponsive System

When a system freezes or stops responding to the keyboard, you might have to interrupt it. When you interrupt
the system, all active processes stop immediately, and the processor services the OpenBoot PROM exclusively. It
does not allow you to flush memory or to synchronize file systems.
To abort or interrupt an unresponsive system:
1. Attempt a remote login on the unresponsive system to locate and kill the offending process.
2. Attempt to reboot the unresponsive system gracefully.
3. Hold down the Stop-A key sequence on the keyboard of the unresponsive system. The system is placed
at the ok prompt.
Note If an ASCII terminal is being used as the system console, use the Break sequence keys.
4. Manually synchronize the file systems by using the OpenBoot PROM sync command.
ok sync
This command causes the syncing of file systems, a crash dump of memory, and then a reboot of the system.
4.2. Perform System Boot and Shutdown

4.2.1. SMF and the Boot Process
Introduction to SMF (Service Management Facility)
SMF provides an infrastructure that augments the traditional UNIX start-up scripts, init run levels, and
configuration files. SMF provides the following functions:
Automatically restarts failed services in dependency order, whether they failed as the result of
administrator error, software bug, or were affected by an uncorrectable hardware error. The dependency
order is defined by dependency statements.
Makes services objects that can be viewed, with the new svcs command, and managed, with
svcadm and svccfg commands. You can also view the relationships between services and
processes using svcs -p, for both SMF services and legacy init.d scripts.
Mkes it easy to backup, restore, and undo changes to services by taking automatic snapshots of service
configurations.

Makes it easy to debug and ask questions about services by providing an explanation of why a service
isnt running by using svcs -x. Also, this process is eased by individual and persistent log files for each
service.
Alows for services to be enabled and disabled using svcadm. These changes can persist through
upgrades and reboots. If the -t option is used, the changes are temporary.
Enhances the ability of administrators to securely delegate tasks to non-root users, including the ability
to modify properties and enable, disable, or restart services on the system.
Boots faster on large systems by starting services in parallel according to the dependencies of the
services. The opposite process occurs during shutdown.
Allows you to customize the boot console output to either be as quiet as possible, which is the default, or
to be verbose by using boot -m verbose.
Dependency statements define the relationships between services. SMF defines a set of actions that can be
invoked on a service by an administrator. These actions include enable, disable, refresh, restart, and maintain.
Each service is managed by a service restarter that carries out the administrative actions. In general, the
restarters carry out actions by executing methods for a service. Methods for each service are defined in the
service configuration repository. These methods allow the restarter to move the service from one state to another
state. The service configuration repository provides a per-service snapshot at the time that each service is
successfully started so that fallback is possible. In addition, the repository provides a consistent and persistent
way to enable or disable a service, as well as a consistent view of service state. This capability helps you debug
service configuration problems.
Changes in Behavior When Using SMF
Most of the features that are provided by SMF happen behind the scenes, so users are not aware of them. Other
features are accessed by new commands. Here is a list of the behavior changes that are most visible.
1. The boot process creates many fewer messages now. Services do not display a message by default
when they are started. All of the information that was provided by the boot messages can now be found in
a log file for each service that is in /var/svc/log. You can use the svcs command to help diagnose
boot problems. In addition, you can use the -v option to the boot command, which generates a
message when each service is started during the boot process.
2. Since services are automatically restarted if possible, it may seem that a process refuses to die. If the
service is defective, the service will be placed in maintenance mode, but normally a service is restarted if
the process for the service is killed. The svcadm command should be used to disable any SMF service
that should not be running.
3. Many of the scripts in /etc/init.d and /etc/rc*.d have been removed. The scripts are no longer
needed to enable or disable a service. Entries from /etc/inittab have also been removed, so that the
services can be administered using SMF. Scripts and inittab entries that are are locally developed will
continue to run. The services may not start at exactly the same point in the boot process, but they are not
started before the SMF services, so that any service dependencies should be OK.
SMF Concepts
SMF Service
The fundamental unit of administration in the SMF framework is the service instance. An instance is a specific
configuration of a service. A web server is a service. A specific web server daemon that is configured to listen on
port 80 is an instance. Multiple instances of a single service are managed as child objects of the service object.
Generically, a service is an entity that provides a list of capabilities to applications and other services, local and
remote. A service is dependent on an implicitly declared list of local services.
A milestone is a special type of service. Milestone services represent high-level attributes of the system. For
example, the services which constitute run levels S, 2, and 3 are each represented by milestone services.
Service Identifiers
Each service instance is named with a Fault Management Resource Identifier or FMRI. The FMRI includes the
service name and the instance name. For example, the FMRI for the rlogin service is
svc:/network/login:rlogin, where network/login identifies the service and rlogin identifies the
service instance.
Equivalent formats for an FMRI are as follows:

svc://localhost/system/system-log:default
svc:/system/system-log:default
system/system-log:default
The service names usually include a general functional category. The categories include the following:
application, device, milestone, network, platform, site, system.
Legacy init.d scripts are also represented with FMRIs that start with lrc instead of svc, for example:
lrc:/etc/rcS_d/S35cacheos_sh. The legacy services can be monitored using SMF. However, you cannot
administer these services. When booting a system for the first time with SMF, services listed in
/etc/inetd.conf are automatically converted into SMF services. The FMRIs for these services are slightly
different. The syntax for a converted inetd services is:
network/<service-name>/<protocol>
In addition, the syntax for a converted service that uses the RPC protocol is:
network/rpc-<service-name>/rcp_<protocol>
Where <service-name> is the name defined in /etc/inetd.conf and <protocol> is the protocol for the service.
For instance, the FMRI for the rpc.cmsd service is network/rpc-100068_2-/rpc_udp.
Service States
The svcs command displays the state, start time, and FMRI of service instances. The state of each service is one
of the following:
1. degraded The service instance is enabled, but is running at a limited capacity.
2. disabled The service instance is not enabled and is not running.
3. legacy_run The legacy service is not managed by SMF, but the service can be observed. This state is
only used by legacy services.
4. maintenance The service instance has encountered an error that must be resolved by the administrator.
5. offline The service instance is enabled, but the service is not yet running or available to run.
6. online The service instance is enabled and has successfully started.
7. uninitialized This state is the initial state for all services before their configuration has been read.
SMF Manifests
An SMF manifest is an XML file that contains a complete set of properties that are associated with a service or a
service instance. The files are stored in /var/svc/manifest. Manifests should not be used to modify the
properties of a service. The service configuration repository is the authoritative source of configuration
information. To incorporate information from the manifest into the repository, you must either run svccfg
import or allow the service to import the information during a system boot.
SMF Profiles
An SMF profile is an XML file that lists the set of service instances that are enabled when a system is booted. The
profiles are stored in /var/svc/profile. These are some the profiles that are included:
1. generic_open.xml This profile enables most of the standard internet services that have been enabled
by default in earlier Solaris releases. This is the default profile.
2. generic_limited_net.xml This profile disables many of the standard internet services. The sshd service
and the NFS services are started, but most of the rest of the internet services are disabled.
Service Configuration Repository
The service configuration repository stores persistent configuration information as well as SMF runtime data for
services. The repository is distributed among local memory and local files. SMF is designed so that eventually,
service data can be represented in the network directory service. The network directory service is not yet
available. The data in the service configuration repository allows for the sharing of configuration information and
administrative simplicity across many Solaris instances. The service configuration repository can only be
manipulated or queried using SMF interfaces.
SMF Repository Backups
SMF automatically takes the following backups of the repository:

1. The boot backup is taken immediately before the first change to the repository is made during each
system startup.
2. The manifest_import backup occurs after svc:/system/manifest-import:default completes,
if it imported any new manifests or ran any upgrade scripts.
Four backups of each type are maintained by the system. The system deletes the oldest backup, when
necessary. The backups are stored as /etc/svc/repository-type-YYYYMMDD_HHMMSWS, where
YYYYMMDD (year, month, day) and HHMMSS (hour, minute, second), are the date and time when the backup
was taken. Note that the hour format is based on a 24hour clock. You can restore the repository from these
backups, if an error occurs. To do so, use the /lib/svc/bin/restore_repository command.
SMF Snapshots
The data in the service configuration repository includes snapshots, as well as a configuration that can be edited.
Data about each service instance is stored in the snapshots. The standard snapshots are as follows:
initial Taken on the first import of the manifest
running Used when the service methods are executed
start Taken at the last successful start
The SMF service always executes with the running snapshot. This snapshot is automatically created if it does not
exist. The svcadm refresh command, sometimes followed by the svcadm restart command, makes a snapshot
active. The svccfg command is used to view or revert to instance configurations in a previous snapshot.
SMF Components
SMF includes a master restarter daemon and delegated restarters.
SMF Master Restarter Daemon
The svc.startd daemon is the master process starter and restarter for the Solaris OS. The daemon is
responsible for managing service dependencies for the entire system. The daemon takes on the previous
responsibility that init held of starting the appropriate /etc/rc*.d scripts at the appropriate run levels. First,
svc.startd retrieves the information in the service configuration repository. Next, the daemon starts services when
their dependencies are met. The daemon is also responsible for restarting services that have failed and for
shutting down services whose dependencies are no longer satisfied. The daemon keeps track of service state
through an operating system view of availability through events such as process death.
SMF Delegated Restarters
Some services have a set of common behaviors on startup. To provide commonality among these services, a
delegated restarter might take responsibility for these services. In addition, a delegated restarter can be used to
provide more complex or application-specific restarting behavior. The delegated restarter can support a different
set of methods, but exports the same service states as the master restarter. The restarters name is stored with
the service. A current example of a delegated restarter is inetd, which can start Internet services on demand,
rather than having the services always running.
4.2.2. Run Levels

A systems run level (also known as an init state) defines what services and resources are available to users. A
system can be in only one run level at a time.
The Solaris OS has eight run levels, which are described in the following table. The default run level is run level
3.
Run Init State Type Purpose
Level
0 Power-down State Power-down To shut down the OS so that it is safe to turn off power to the
system.
s or S Single-user state Single-user To run as a single user with some filesystems mounted and
accessible.
1 Administrative State Single-user To access all available filesystems. User logins are disabled.
2 Multi-user State Multiuser For normal operations. Multiple users can access the system
and all file system.

3 Multiuser with NFS Multiuser Default run-level with NFS enabled

4 Alternative multiuser Not configured by default but available for customer use.
state
5 Powerdown state Powerdown To shut down the operating system so that it is safe to turn
off power to the system. If possible, automatically turns off
power on systems that support this feature
6 Reboot State Reboot To shutdown the system to run-level 0, and then reboot to
default run-level.
The init command can be used to change the run-levels. Even the svcadm command can be used to change the
run level of a system, by selecting a milestone at which to run. The following table shows which run level
corresponds to each milestone.
Run level information is displayed by the who -r command.

/etc/inittab file
When you boot the system or change run levels with the init or shutdown command, the init daemon starts
processes by reading information from the /etc/inittab file. This file defines these important items for the init
process:
That the init process will restart
What processes to start, monitor, and restart if they terminate
What actions to take when the system enters a new run level
Each entry in the /etc/inittab file has the following fields:
id:rstate:action:process
id Is a unique identifier for the entry.
rstate Lists the run levels to which this entry applies.
action Identifies how the process that is specified in the process field is to be
run. Possible values include: sysinit, boot, bootwait, wait, and respawn.
process Defines the command or script to execute.
4.2.3. SPARC Systems Boot Process

The first step of the boot process relies on the physical hardware of the workstation to initialize itself and load a
small program. This program is usually stored in a ROM (read-only memory) or PROM (programmable read-only
memory) chip. The program loaded at power-on is called a PROM monitor.
NOTE: As personal computer users we are more familiar with the term basic input/output system (BIOS). The
BIOS of an x86 system is functionally equivalent to the Sparc PROM monitor.
Step 1: PROM monitor executes
power-on self-test (POST). PROM chip
PROM monitor loads boot
block from boot device.
Step 2: Boot block loads ufsboot

from boot device and ufsboot
Disk
in turn loads the kernel.

Step 3: Kernel initializes itself and starts

the init process which in turn
reads the /etc/inittab file and
starts other processes.
Services
Step 4: The /sbin/init process starts
/lib/svc/bin/svc.startd, which
starts the system services and
runs the rc scripts.
Step 1
The PROM monitor has several functions. It can be used to modify basic hardware parameters such as serial port
configurations or the amount of memory that should be tested upon system power-up. Another PROM
configurable parameter is the system boot-device specification. This parameter tells the PROM monitor where it
should look for the next stage of the boot process. Most important, the PROM monitor has routines to load the
next stage into memory and start it running.
Similar to the PROM monitor, the boot block gets its name from the location in which it is stored. Typically, the
boot block is stored in the first few blocks (sectors 1 to 15) on the hard disk attached to the workstation. The boot
blocks job is to initialize some of the systems peripherals and memory, and to load the program, which in turn will
load the SunOS kernel. A boot block is placed on the disk as part of the Solaris installation process, or in some
circumstances, by the system administrator using the installboot program.
Step 2
Depending on the location of the boot block, its next action is to load a boot program such as ufsboot into memory
and execute it. The boot program includes a device driver as required for the device (such as a disk drive or
network adapter) that contains the SunOS kernel. Once started, the boot program loads the SunOS kernel into
memory, and then starts it running.
Step 3
The kernel is the heart of the operating system. Once loaded into memory by the boot program, the kernel has
several tasks to perform before the final stages of the boot process can proceed. First, the kernel initializes
memory and the hardware associated with the memory management. Next, the kernel performs a series of device
probes. These routines check for the presence of various devices such as graphics displays, Ethernet controllers,
disk controllers, disk drives, tape devices, and so on. This search for memory and devices is sometimes referred
to as auto-configuration.
With memory and devices identified and configured, the kernel finishes its start-up routine by creating init, the first
system process. The init process is given process ID number I and is the parent of all the processes on the
system. Process I (init) is also responsible for the remainder of the boot process.
Step 4
The init process and the files it reads and the shell scripts it executes are the most configurable part of the boot
process. Management of the processes that offer the login prompt to terminals, the start-up for daemons, network
configuration, disk checking, and more occur during this stage of the boot sequence. The init process starts the
svc.startd daemon, which starts all the services and it also executes the rc scripts for compatibility.
System Booting
We have different boot options for booting a Solaris Operating Environment:
Interactive boot (We can customize the kernel and device path)
Reconfiguration boot (To support newly added hardware)
Recovery boot (If the system is hung or its not coming up due to illegal entries)
Kernel - - - bit and modes:

The core of the kernel is two pieces of static code called genunix and unix, where genunix is the platform-
independent generic kernel file and unix is the platform-specific kernel file.

When ufsboot loads these two files into memory, they are combined to form the running kernel.
On a system running in 32-bit mode, the two-part kernel is located in the directory /platform/uname -m/kernel.
On a system running in 64-bit mode, the two-part kernel is located in the directory /platform/uname -
m/kernel/sparcv9.
Note To determine the platform name (for example, the system hardware class), type the uname -m command.
For example, when you type this command on an Ultra 10 workstation, the console displays sun4u.
The kernel Initialization Phase
The following describes the kernel initialization phase:
The kernel reads its configuration file, called /etc/system.
The kernel initializes itself and begins loading modules.
Modules can consist of device drivers, binary files to support file systems, and streams, as well as other module
types used for specific tasks within the system. The modules that make up the kernel typically reside in the
directories /kernel and /usr/kernel. Platform-dependent modules reside in the /platform/uname -m/kernel and
/platform/uname -i/kernel directories. Each subdirectory located under these directories is a collection of similar
modules.
x86-boot process

The following describes the types of module subdirectories contained in the /kernel, /usr/kernel, /platform/uname
-m/kernel, or /platform/uname -i/kernel directories:
drv Device drivers
exec Executable file formats
fs File system types, for example, ufs, nfs, and proc
misc Miscellaneous modules (virtual swap)
sched Scheduling classes (process execution scheduling)
strmod Streams modules (generalized connection between users and device drivers)
sys System calls (defined interfaces for applications to use)
The /kernel/drv directory contains all of the device drivers that are used for system boot. The /usr/kernel/drv
directory is used for all other device drivers. Modules are loaded automatically as needed either at boot time or on
demand, if requested by an application. When a module is no longer in use, it might be unloaded on the basis that
the memory it uses is needed for another task. After the boot process is complete, device drivers are loaded when
devices, such as tape devices, are accessed.
The advantage of this dynamic kernel arrangement is that the overall size of the kernel is smaller, which makes
more efficient use of memory and allows for simpler modification and tuning.
4.2.4. SMF and Booting

SMF provides new methods for booting a system. For instance:
There is a additional system state which is associated with the all milestone. This milestone is different than the
multiuser init state because SMF only knows about the services that are defined. If you have added services,
such as third party products, they may not be started automatically unless you use the following command:
# boot -m milestone=all
If you boot a system using one of the milestones, it is important to use the s option as well. If you do not include
the -s, then the system will stay in the milestone state that you booted the system in. The system will not go into
multiuser state automatically by typing Control-D. You can get into the multiuser state by using the following
command:
# svcadm milestone -t all
4.2.5. Run Control Scripts

The Solaris software provides a detailed series of run control (rc) scripts to control run-level changes. Each run
level has an associated rc script that is located in the /sbin directory:
rc0

rc1
rc2
rc3
rc5
rc6
rcS
For each rc script in the /sbin directory, there is a corresponding directory named /etc/rcn.d that contains scripts to
perform various actions for that run level. For example, /etc/rc2.d contains files that are used to start and stop
processes for run level 2. The /etc/rcn.d scripts are always run in ASCII sort order. The scripts have names of the
form:
[KS][0-9][0-9]*
Files that begin with K are run to terminate (kill) a system service. Files that begin with S are run to start a system
service.
Run control scripts are located in the /etc/init.d directory. These files are linked to corresponding run control
scripts in the /etc/rcn.d directories. The actions of each run control script are summarized in the following section.
The /sbin/rc0 Script
The /sbin/rc0 script runs the /etc/rc0.d scripts to perform the following tasks:
Stops system services and daemons
Terminates all running processes
Unmounts all file systems
Stops system services and daemons
Terminates all running user processes
Unmounts all remote file systems
Mounts all local file systems if the previous run level was S
The /sbin/rc2 script runs the /etc/rc2.d scripts to perform the following tasks, grouped by function:
Starts system accounting and system auditing, if configured
Configures serial device stream
Starts the Solaris PPP server or client daemons (pppoed or pppd), if configured
Configures the boot environment for the Live Upgrade software upon system startup or system shutdown
Checks for the presence of the /etc/.UNCONFIGURE file to see if the system should be reconfigured
Note Many of the system services and applications that are started at run level 2 depend on what software is
installed on the system.
Starts the Apache server daemon (tomcat), if configured
Starts the Samba daemons (smdb and nmdb), if configured
The /sbin/rc5 and /sbin/rc6 Scripts
The /sbin/rc5 and /sbin/rc6 scripts run the /etc/rc0.d/K* scripts to perform the following tasks:
Kills all active processes
Unmounts the file systems
The /sbin/rcS Script
The /sbin/rcS script runs the /etc/rcS.d scripts to bring the system up to run level S.

4.2.6. System Shutdown

We can shut down the Solaris OE to perform administration tasks or maintenance activities if you are anticipating
a power outage or if you need to move the system to a new location.
The Solaris OE requires a clean and orderly shutdown, which stops processes, writes data in memory to disks,
and unmounts file systems. Of course, the type of work you need to do while the system is shut down determines
how the system is shut down and which command you use.
The following describes the different types of system shutdowns.
Shut down the system to single-user mode
Shut down the system to stop the Solaris OE, and display the ok prompt
Shut down the system and turn off power
Shut down the system and automatically reboot to multiuser mode
The commands available to the root user for doing these types of system shutdown procedures include:
/sbin/init (using run levels S, 0, 1, 2, 5, or 6)
/usr/sbin/shutdown (using run levels S, 0, 1, 5, or 6)
/usr/sbin/halt
/usr/sbin/poweroff
/usr/sbin/reboot
The /usr/sbin/shutdown Command
The shutdown command is a script that invokes the init daemon to shut down, power off, or reboot the system. It
executes the rc0 kill scripts to shut down processes and applications gracefully. But unlike the init command, the
shutdown command does the following:
Notifies all logged-in users that the system is being shut down
Delays the shutdown for 60 seconds by default
Enables you to include an optional descriptive message to inform your users of what will transpire
The command format for the shutdown command is:
shutdown -y -g grace-period -i init-state optional message
The -y option pre-answers the final shutdown confirmation question so that the command runs without your
intervention.
The /usr/sbin/halt Command
The halt command performs an immediate system shutdown. It does not execute the rc0 kill scripts. It does not
notify logged-in users, and there is no grace period.
The /usr/sbin/poweroff Command
The poweroff command performs an immediate shutdown. It does not execute the rc0 kill scripts. It does not
notify logged-in users, and there is no grace period.
The /usr/sbin/reboot Command
The reboot command performs an immediate shutdown and reinitialization, bringing the system to run level 3 by
default. The reboot command differs from the init 6 command because it does not execute the rc0 kill scripts.


Chapter 5 Account Management & Security Page 55 of 198
5. Account Management & Security

5.1. What Are User Accounts and Groups?
One basic system administration task is to set up a user account for each user at a site. A typical user account
includes the information a user needs to log in and use a system, without having the systems root password.
When you set up a user account, you can add the user to predefined groups of users. A typical use of groups is to
set up group permissions on a file and directory, which allows access only to users who are part of that group.
For example, you might have a directory containing confidential files that only a few users should be able to
access. You could set up a group called topsecret that includes the users working on the topsecret project.
And, you could set up the topsecret files with read permission for the topsecret group. That way, only the
users in the topsecret group would be able to read the files. A special type of user account, called a role, is
used to give selected users special privileges.
5.1.1. User Account Components

The following sections describe the specific components of a user account.
User (Login) Names
User names, also called login names, let users access their own systems and remote systems that have the
appropriate access privileges. You must choose a user name for each user account that you create.
Consider establishing a standard way of assigning user names so that they are easier for you to track. Also,
names should be easy for users to remember. A simple scheme when selecting a user name is to use the first
name initial and first seven letters of the users last name. For example, Ziggy Ignatz becomes zignatz. If this
scheme results in duplicate names, you can use the first initial, middle initial, and the first six characters of the
users last name. For example, Ziggy Top Ignatz becomes ztignatz. If this scheme still results in duplicate
names, consider using the following scheme to create a user name:
1. The first initial, middle initial, first five characters of the users last name
2. The number 1, or 2, or 3, and so on, until you have a unique name
Note Each new user name must be distinct from any mail aliases that are known to the system or to an NIS or
NIS+ domain. Otherwise, mail might be delivered to the alias rather than to the actual user.
User ID Numbers
Associated with each user name is a user identification number (UID). The UID number identifies the user name
to any system on which the user attempts to log in. And, the UID number is used by systems to identify the
owners of files and directories. If you create user accounts for a single individual on a number of different
systems, always use the same user name and ID number. In that way, the user can easily move files between
systems without ownership problems.
UID numbers must be a whole number that is less than or equal to 2147483647. UID numbers are required for
both regular user accounts and special system accounts. The following table lists the UID numbers that are
reserved for user accounts and system accounts.
Reserved UID Numbers
Do not assign UIDs 0 through 99, which are reserved for system use, to regular user accounts. By definition, root
always has UID 0, daemon has UID 1, and pseudo-user bin has UID 2. In addition, you should give uucp logins

and pseudo user logins, such as who, tty, and ttytype, low UIDs so that they fall at the beginning of the passwd
file.
As with user (login) names, you should adopt a scheme to assign unique UID numbers. Some companies assign
unique employee numbers. Then, administrators add a number to the employee number to create a unique UID
number for each employee.
To minimize security risks, you should avoid reusing the UIDs from deleted accounts. If you must reuse a UID,
wipe the slate clean so that the new user is not affected by attributes set for a former user. For example, a
former user might have been denied access to a printer by being included in a printer deny list. However, that
attribute might be inappropriate for the new user.
Using Large User IDs and Group IDs
UIDs and group IDs (GIDs) can be assigned up to the maximum value of a signed integer, or 2147483647.
However, UIDs and GIDs over 60000 do not have full functionality and are incompatible with many Solaris
features. So, avoid using UIDs or GIDs over 60000. The following table describes interoperability issues with
Solaris products and previous Solaris releases.
Interoperability Issues for UIDs or GIDs Over 60000

Large UID or GID Limitation Summary
UNIX Groups
A group is a collection of users who can share files and other system resources. For example, users who working
on the same project could be formed into a group. A group is traditionally known as a UNIX group.
Each group must have a name, a group identification (GID) number, and a list of user names that belong to the
group. A GID number identifies the group internally to the system. The two types of groups that a user can belong
to are as follows:
Primary group Specifies a group that the operating system assigns to files that are created by the user. Each
user must belong to a primary group.
Secondary groups Specifies one or more groups to which a user also belongs. Users can belong to up to 15
secondary groups.
Sometimes, a users secondary group is not important. For example, ownership of files reflect the primary group,
not any secondary groups. Other applications, however, might rely on a users secondary group memberships.
For example, a user has to be a member of the sysadmin group (group 14) to use the Admintool software in
previous Solaris releases. However, it doesnt matter if group 14 is his or her current primary group.
The groups command lists the groups that a user belongs to. A user can have only one primary group at a time.
However, a user can temporarily change the users primary group, with the newgrp command, to any other
group in which the user is a member.
When adding a user account, you must assign a primary group for a user or accept the default group, staff
(group 10). The primary group should already exist. If the primary group does not exist, specify the group by a
GID number. User names are not added to primary groups. If user names were added to primary groups, the list
might become too long. Before you can assign users to a new secondary group, you must create the group and
assign it a GID number.
Groups can be local to a system or managed through a name service. To simplify group administration, you
should use a name service such as NIS or a directory service such as LDAP. These services enable you to
centrally manage group memberships.
User Passwords
You can specify a password for a user when you add the user. Or, you can force the user to specify a password
when the user first logs in. User passwords must comply with the following syntax:

1. Password length must at least match the value identified by the PASSLENGTH variable in the
/etc/default/passwd file. By default, PASSLENGTH is set to 6.
2. The first 6 characters of the password must contain at least two alphabetic characters and have at least
one numeric or special character.
3. You can increase the maximum password length to more than eight characters by configuring the
/etc/policy.conf file with an algorithm that supports greater than eight characters.
Although user names are publicly known, passwords must be kept secret and known only to users. Each user
account should be assigned a password. The password can be a combination of six to eight letters, numbers, or
special characters.
To make your computer systems more secure, users should change their passwords periodically. For a high level
of security, you should require users to change their passwords every six weeks. Once every three months is
adequate for lower levels of security. System administration logins (such as root and sys) should be changed
monthly, or whenever a person who knows the root password leaves the company or is reassigned.
Many breaches of computer security involve guessing a legitimate users password. You should make sure that
users avoid using proper nouns, names, login names, and other passwords that a person might guess just by
knowing something about the user.
Good choices for passwords include the following:
1. Phrases (beammeup).
2. Nonsense words made up of the first letters of every word in a phrase. For example, swotrb for
SomeWhere over the RainBow.
3. Words with numbers or symbols substituted for letters. For example, sn00py for snoopy.
Do not use these choices for passwords:
1. Your name (spelled forwards, backwards, or jumbled)
2. Names of family members or pets
3. Car license numbers
4. Telephone numbers
5. Social Security numbers
6. Employee numbers
7. Words related to a hobby or interest
8. Seasonal themes, such as Santa in December
9. Any word in the dictionary
Home Directories
The home directory is the portion of a file system allocated to a user for storing private files. The amount of space
you allocate for a home directory depends on the kinds of files the user creates, their size, and the number of files
that are created.
A home directory can be located either on the users local system or on a remote file server. In either case, by
convention the home directory should be created as /export/home/username. For a large site, you should
store home directories on a server. Use a separate file system for each /export/homen directory to facilitate
backing up and restoring home directories. For example, /export/home1, /export/home2.
Regardless of where their home directory is located, users usually access their home directories through a mount
point named /home/username. When AutoFS is used to mount home directories, you are not permitted to create
any directories under the /home mount point on any system. The system recognizes the special status of /home
when AutoFS is active.
To use the home directory anywhere on the network, you should always refer to the home directory as $HOME, not
as /export/home/username. The latter is machine-specific. In addition, any symbolic links created in a users
home directory should use relative paths (for example, ../../../x/y/x) so that the links are valid no matter
where the home directory is mounted.
Name Services
If you are managing user accounts for a large site, you might want to consider using a name or directory service
such as LDAP, NIS, or NIS+. A name or directory service enables you to store user account information in a

centralized manner instead of storing user account information in every systems /etc files. When you use a
name or directory service for user accounts, users can move from system to system using the same user account
without having site-wide user account information duplicated on every system. Using a name or directory service
also promotes centralized and consistent user account information.
Users Work Environment
Besides having a home directory to create and store files, users need an environment that gives them access to
the tools and resources they need to do their work. When a user logs in to a system, the users work environment
is determined by initialization files. These files are defined by the users startup shell, such as the C, Korn, or
Bourne shell.
A good strategy for managing the users work environment is to provide customized user initialization files, such
as .login, .cshrc, .profile, in the users home directory.
Note Do not use system initialization files, such as /etc/profile or /etc/.login, to manage a users work
environment. These files reside locally on systems and are not centrally administered. For example, if AutoFS is
used to mount the users home directory from any system on the network, you would have to modify the system
initialization files on each system to ensure a consistent environment whenever a user moved from system to
system.
Guidelines for Using User Names, User IDs, and Group Ids
User names, UIDs, and GIDs should be unique within your organization, which might span multiple domains.
Keep the following guidelines in mind when creating user or role names, UIDs, and GIDs:
User names They should contain from two to eight letters and numerals. The first character should be a letter.
At least one character should be a lowercase letter.
Note Even though user names can include a period (.), underscore (_), or hyphen (-), using these characters is
not recommended because they can cause problems with some software products.
System accounts Do not use any of the user names, UIDs, or GIDs that are contained in the default
/etc/passwd and /etc/group files. UIDs and GIDs 0-99 are reserved for system use and should not be
used by anyone. This restriction includes numbers not currently in use.
For example, gdm is the reserved user name and group name for the GNOME Display Manager daemon and
should not be used for another user. For a complete listing of the default /etc/passwd and /etc/group
entries, see Table 46 and Table 49.
The nobody and nobody4 accounts should never be used for running processes. These two accounts are
reserved for use by NFS. Use of these accounts for running processes could lead to unexpected security risks.
Processes that need to run as a non-root user should use the daemon or noaccess accounts.
System account configuration The configuration of the default system accounts should never be changed.
This includes changing the login shell of a system account that is currently locked. The only exception to this rule
is the setting of a password and password aging parameters for the root account.
5.1.2. Where User Account and Group Information Is Stored

Depending on your site policy, user account and group information can be stored in your local systems /etc
files or in a name or directory service as follows:
1. The NIS+ name service information is stored in tables.
2. The NIS name service information is stored in maps.
3. The LDAP directory service information is stored in indexed database files.
Note To avoid confusion, the location of the user account and group information is generically referred to as a
file rather than as a database, table, or map. Most user account information is stored in the passwd file.
Password information is stored as follows:
1. In the passwd file when you are using NIS or NIS+
2. In the /etc/shadow file when you are using /etc files
3. In the people container when you are using LDAP

Password aging is available when you are using NIS+ or LDAP, but not NIS. Group information is stored in the
group file for NIS, NIS+ and files. For LDAP, group information is stored in the group container.
Fields in the passwd File
The fields in the passwd file are separated by colons and contain the following information:
username:password:uid:gid:comment:home-directory:login-shell
For example:
kryten:x:101:100:Kryten Series 4000 Mechanoid:/export/home/kryten:/bin/csh
The following table describes the passwd file fields.
Fields in the passwd File
Default passwd File

The default Solaris passwd file contains entries for standard daemons. Daemons are processes that are usually
started at boot time to perform some system-wide task, such as printing, network administration, or port
monitoring.
root:x:0:1:Super-User:/:/sbin/sh
daemon:x:1:1::/:
bin:x:2:2::/usr/bin:
sys:x:3:3::/:
adm:x:4:4:Admin:/var/adm:
lp:x:71:8:Line Printer Admin:/usr/spool/lp:
uucp:x:5:5:uucp Admin:/usr/lib/uucp:
nuucp:x:9:9:uucp Admin:/var/spool/uucppublic:/usr/lib/uucp/uucico
smmsp:x:25:25:SendMail Message Submission Program:/:
listen:x:37:4:Network Admin:/usr/net/nls:
gdm:x:50:50:GDM Reserved UID:/:
webservd:x:80:80:WebServer Reserved UID:/:
nobody:x:60001:60001:NFS Anonymous Access User:/:

noaccess:x:60002:60002:No Access User:/:

nobody4:x:65534:65534:SunOS 4.x NFS Anonymous Access User:/:

Default passwd File Entries
Fields in the shadow File

The fields in the shadow file are separated by colons and contain the following information:
username:password:lastchg:min:max:warn:inactive:expire
For example:
rimmer:86Kg/MNT/dGu.:8882:0::5:20:8978
The following table describes the shadow file fields.

Fields in the shadow File
Fields in the group File

The fields in the group file are separated by colons and contain the following information:
group-name:group-password:gid:user-list
For example:
bin::2:root,bin,daemon
The following table describes the group file fields.
Fields in the group File

Default group file

Default Solaris group file contains following system groups that support some system-wide task, such as
printing, network administration, or electronic mail. Many of these groups having corresponding entries in passwd
file.
root::0:
other::1:
bin::2:root,daemon
sys::3:root,bin,adm
adm::4:root,daemon
uucp::5:root
mail::6:root
tty::7:root,adm
lp::8:root,adm
nuucp::9:root
staff::10:
daemon::12:root
smmsp::25:
sysadmin::14:
gdm::50:
webservd::80:
nobody::60001:
noaccess::60002:
nogroup::65534:

Default group File Entries
Tools for Managing User Accounts and Groups

The following table lists the recommended tools for managing users and groups. These tools are included in the
Solaris Management Console suite of tools.

Tools for Managing Users and Groups
Use the Solaris Management Console online help for information on performing these tasks.
For information on the Solaris commands that can be used to manage user accounts and groups, see Table 16.
These commands provide the same functionality as the Solaris management tools, including authentication and
name service support.
Tasks for Solaris User and Group Management Tools
The Solaris user management tools enable you to manage user accounts and groups on a local system or in a
name service environment. This table describes the tasks you can do with the Users tools User Accounts feature.
Task Descriptions for User Accounts Tool

5.1.3. Customizing a Users Work Environment

Part of setting up a users home directory is providing user initialization files for the users login shell. A user
initialization file is a shell script that sets up a work environment for a user after the user logs in to a system.
Basically, you can perform any task in a user initialization file that you can do in a shell script. However, a user
initialization files primary job is to define the characteristics of a users work environment, such as a users search
path, environment variables, and windowing environment. Each login shell has its own user initialization file or
files, which are listed in the following table.
User Initialization Files for Bourne, C, and Korn Shells
The Solaris environment provides default user initialization files for each shell in the /etc/skel directory on
each system, as shown in the following table.
Default User Initialization Files
You can use these files as a starting point and modify them to create a standard set of files that provide the work
environment common to all users. Or, you can modify these files to provide the working environment for different
types of users. Although you cannot create customized user initialization files with the Users tool, you can
populate a users home directory with user initialization files located in a specified skeleton directory. You can do
this by creating a user template with the User Templates tool and specifying a skeleton directory from which to
copy user initialization files.
For step-by-step instructions on how to create sets of user initialization files for different types of users, see How
to Customize User Initialization Files on page 103. When you use the Users tool to create a new user account
and select the create home directory option, the following files are created, depending on which login shell is
selected.
TABLE 419 Files Created by Users Tool When Adding a User
If you use the useradd command to add a new user account and specify the /etc/skel directory by using the
-k and -m options, all three /etc/skel/local* files and the /etc/skel/.profile file are copied into the
users home directory. At this point, you need to rename them to whatever is appropriate for the users login shell.
Using Site Initialization Files
The user initialization files can be customized by both the administrator and the user. This important feature can
be accomplished with centrally located and globally distributed user initialization files, called site initialization files.
Site initialization files enable you to continually introduce new functionality to the users work environment, while
enabling the user to customize the users initialization file.
When you reference a site initialization file in a user initialization file, all updates to the site initialization file are
automatically reflected when the user logs in to the system or when a user starts a new shell. Site initialization

files are designed for you to distribute site-wide changes to users work environments that you did not anticipate
when you added the users.
You can customize a site initialization file the same way that you customize a user initialization file. These files
typically reside on a server, or set of servers, and appear as the first statement in a user initialization file. Also,
each site initialization file must be the same type of shell script as the user initialization file that references it.
To reference a site initialization file in a C-shell user initialization file, place a line similar to the following at the
beginning of the user initialization file:
source /net/machine-name/export/site-files/site-init-file
To reference a site initialization file in a Bourne-shell or Korn-shell user initialization file, place a line similar to the
following at the beginning of the user initialization file:
. /net/machine-name/export/site-files/site-init-file
Avoiding Local System References
You should not add specific references to the local system in the user initialization file. You want the instructions
in a user initialization file to be valid regardless of which system the user logs into. For example:
1. To make a users home directory available anywhere on the network, always refer to the home directory
with the variable $HOME. For example, use $HOME/bin instead of /export/home/username/bin. The
$HOME variable works when the user logs in to another system and the home directories are
automounted.
2. To access files on a local disk, use global path names, such as /net/system-name/directory-name. Any
directory referenced by /net/system-name can be mounted automatically on any system on which the
user logs in, assuming the system is running AutoFS.
Shell Features
The following table lists basic shell features that each shell provides, which can help you determine what you can
and cant do when creating user initialization files for each shell.
Shell Environment
A shell maintains an environment that includes a set of variables defined by the login program, the system
initialization file, and the user initialization files. In addition, some variables are defined by default. A shell can
have two types of variables:
Environment variables Variables that are exported to all processes spawned by the shell. Their settings can be
seen with the env command. A subset of environment variables, such as PATH, affects the behavior of the shell
itself.
Shell (local) variables Variables that affect only the current shell. In the C shell, a set of these shell variables
have a special relationship to a corresponding set of environment variables. These shell variables are user, term,
home, and path. The value of the environment variable counterpart is initially used to set the shell variable.
In the C shell, you use the lowercase names with the set command to set shell variables. You use uppercase
names with the setenv command to set environment variables. If you set a shell variable, the shell sets the
corresponding environment variable and vice versa. For example, if you update the path shell variable with a
new path, the shell also updates the PATH environment variable with the new path.
In the Bourne and Korn shells, you can use the uppercase variable name equal to some value to set both shell
and environment variables. You also have to use the export command to activate the variables for any
subsequently executed commands.
For all shells, you generally refer to shell and environment variables by their uppercase names.
In a user initialization file, you can customize a users shell environment by changing the values of the predefined
variables or by specifying additional variables. The following table shows how to set environment variables in a
user initialization file.
The PATH Variable
When the user executes a command by using the full path, the shell uses that path to find the command.
However, when users specify only a command name, the shell searches the directories for the command in the
order specified by the PATH variable.

If the command is found in one of the directories, the shell executes the command. A default path is set by the
system. However, most users modify it to add other command directories. Many user problems related to setting
up the environment and accessing the correct version of a command or a tool can be traced to incorrectly defined
paths.
Setting Path Guidelines
Here are some guidelines for setting up efficient PATH variables:
1. If security is not a concern, put the current working directory (.) first in the path. However, including the
current working directory in the path poses a security risk that you might want to avoid, especially for
superuser.
2. Keep the search path as short as possible. The shell searches each directory in the path. If a command is
not found, long searches can slow down system performance.
3. The search path is read from left to right, so you should put directories for commonly used commands at
the beginning of the path.
4. Make sure that directories are not duplicated in the path.
5. Avoid searching large directories, if possible. Put large directories at the end of the path.
6. Put local directories before NFS mounted directories to lessen the chance of hanging when the NFS
server does not respond. This strategy also reduces unnecessary network traffic.
ExamplesSetting a Users Default Path

The following examples show how to set a users default path to include the home directory and other NFS
mounted directories. The current working directory is specified first in the path. In a C-shell user initialization file,
you would add the following:
set path=(. /usr/bin $HOME/bin /net/glrr/files1/bin)
In a Bourne-shell or Korn-shell user initialization file, you would add the following:
PATH=.:/usr/bin:/$HOME/bin:/net/glrr/files1/bin
export PATH
Locale Variables
The LANG and LC environment variables specify the locale-specific conversions and conventions for the shell.
These conversions and conventions include time zones, collation orders, and formats of dates, time, currency,
and numbers. In addition, you can use the stty command in a user initialization file to indicate whether the
terminal session will support multibyte characters.
The LANG variable sets all possible conversions and conventions for the given locale. You can set various
aspects of localization separately through these LC variables:
LC_COLLATE, LC_CTYPE, LC_MESSAGES, LC_NUMERIC, LC_MONETARY, and LC_TIME.
The following table describes some of the values for the LANG and LC environment variables.
Default File Permissions (umask)
When you create a file or directory, the default file permissions assigned to the file or directory are controlled by
the user mask. The user mask is set by the umask command in a user initialization file. You can display the
current value of the user mask by typing umask and pressing Return.
The user mask contains the following octal values:
1. The first digit sets permissions for the user
2. The second digit sets permissions for group
3. The third digit sets permissions for other, also referred to as world
Note that if the first digit is zero, it is not displayed. For example, if the user mask is set to 022, 22 is displayed.
To determine the umask value you want to set, subtract the value of the permissions you want from 666 (for a
file) or 777 (for a directory). The remainder is the value to use with the umask command. For example, suppose
you want to change the default mode for files to 644 (rw-r--r--). The difference between 666 and 644 is 022,
which is the value you would use as an argument to the umask command.

You can also determine the umask value you want to set by using the following table. This table shows the file
and directory permissions that are created for each of the octal values of umask.
Examples of User and Site Initialization Files

The following sections provide examples of user and site initialization files that you can use to start customizing
your own initialization files. These examples use system names and paths that you need to change for your
particular site.
The .profile File
(Line 1) PATH=$PATH:$HOME/bin:/usr/local/bin:/usr/ccs/bin:.
(Line 2) MAIL=/var/mail/$LOGNAME
(Line 3) NNTPSERVER=server1
(Line 4) MANPATH=/usr/share/man:/usr/local/man
(Line 5) PRINTER=printer1
(Line 6) umask 022
(Line 7) export PATH MAIL NNTPSERVER MANPATH PRINTER
1. Defines the users shell search path
2. Defines the path to the users mail file
3. Defines the users Usenet news server
4. Defines the users search path for man pages
5. Defines the users default printer
6. Sets the users default file creation permissions
7. Sets the listed environment variables
The .cshrc File
(Line 1) set path=($PATH $HOME/bin /usr/local/bin /usr/ccs/bin)
(Line 2) setenv MAIL /var/mail/$LOGNAME
(Line 3) setenv NNTPSERVER server1
(Line 4) setenv PRINTER printer1
(Line 5) alias h history
(Line 6) umask 022
(Line 7) source /net/server2/site-init-files/site.login
1. Defines the users shell search path.
2. Defines the path to the users mail file.
3. Defines the users Usenet news server.
4. Defines the users default printer.
5. Creates an alias for the history command. The user needs to type only h to run the history
command.
6. Sets the users default file creation permissions.
7. Sources the site initialization file.
Site Initialization File

The following shows an example site initialization file in which a user can choose a particular version of an
application.
# @(#)site.login
main:
echo "Application Environment Selection"
echo ""
echo "1. Application, Version 1"
echo "2. Application, Version 2"
echo ""
echo -n "Type 1 or 2 and press Return to set your
application environment: "

set choice = $<

if ( $choice !~ [1-2] ) then
goto main
endif
switch ($choice)
case "1":
setenv APPHOME /opt/app-v.1
breaksw
case "2":
setenv APPHOME /opt/app-v.2
endsw
This site initialization file could be referenced in a users .cshrc file (C shell users only) with the following line:
source /net/server2/site-init-files/site.login
In this line, the site initialization file is named site.login and is located on a server named server2. This line
also assumes that the automounter is running on the users system.
5.1.4. Quotas
What Are Quotas?
Quotas enable system administrators to control the size of UFS file systems. Quotas limit the amount of disk
space and the number of inodes, which roughly corresponds to the number of files that individual users can
acquire. For this reason, quotas are especially useful on the file systems where user home directories reside.
Using Quotas
Once quotas are in place, they can be changed to adjust the amount of disk space or the number of inodes that
users can consume. Additionally, quotas can be added or removed, as system needs change.
In addition, quota status can be monitored. Quota commands enable administrators to display information about
quotas on a file system, or search for users who have exceeded their quotas.
Setting Soft Limits and Hard Limits for Quotas
You can set both soft limits and hard limits. The system does not allow a user to exceed his or her hard limit.
However, a system administrator might set a soft limit, which the user can temporarily exceed. The soft limit must
be less than the hard limit. Once the user exceeds the soft limit, a quota timer begins. While the quota timer is
ticking, the user is allowed to operate above the soft limit but cannot exceed the hard limit. Once the user goes
below the soft limit, the timer is reset. However, if the users usage remains above the soft limit when the timer
expires, the soft limit is enforced as a hard limit. By default, the soft limit timer is set to seven days.
The timeleft field in the repquota and quota commands shows the value of the timer.
For example, lets say a user has a soft limit of 10,000 blocks and a hard limit of 12,000 blocks. If the users block
usage exceeds 10,000 blocks and the seven-day timer is also exceeded, the user cannot allocate more disk
blocks on that file system until his or her usage drops below the soft limit.
The Difference between Disk Block and File Limits
A file system provides two resources to the user, blocks for data and inodes for files. Each file consumes one
inode. File data is stored in data blocks. Data blocks are usually made up of 1Kbyte blocks.
5.2. System Security

5.2.1. Monitoring System Access
All systems should be monitored routinely for unauthorized user access. You can determine who is or who has
been logged into the system by executing commands and examining log files.
Displaying Users on the Local System

The who command displays a list of users currently logged in to the local system. It displays each users login
name, the login device (TTY port), the login date and time. The command reads the binary file /var/adm/utmpx
to obtain this information and information about where the users logged in from.
If a user is logged in remotely, the who command displays the remote host name, or Internet Protocol (IP)
address in the last column of the output.
# who
root console Oct 29 16:09 (:0)
root pts/4 Oct 29 16:09 (:0.0)
root pts/5 Oct 29 16:10 (192.168.0.234)
alice pts/7 Oct 29 16:48 (192.168.0.234)
The second field displayed by the who command defines the users login device, which is one of the following:
console The device used to display system boot and error messages
pts The pseudo device that represents a login or window session without a physical device
term The device physically connected to a serial port, such as a terminal or a modem
Displaying Users on Remote Systems
The rusers command produces output similar to that of the who command, but it displays a list of the users logged
in on local and remote hosts. The list displays the users name and the hosts name in the order in which the
responses are received from the hosts.
A remote host responds only to the rusers command if its rpc.rusersd daemon is enabled. The rpc.rusersd
daemon is the network server daemon that returns the list of users on the remote hosts.
Note The full path to this network server daemon is /usr/lib/netsvc/rusers/rpc.rusersd.
Displaying User Information
To display detailed information about user activity that is either local or remote, use the finger command.
The finger command displays:
1. The users login name
2. The home directory path
3. The login time
4. The login device name
5. The data contained in the comment field of the /etc/passwd file (usually the users full name)
6. The login shell
7. The name of the host, if the user is logged in remotely, and any idle time
Note You get a response from the finger command only if the in.fingerd daemon is enabled.
Displaying a Record of Login Activity
Use the last command to display a record of all logins and logouts with the most recent activity at the top of the
output. The last command reads the binary file /var/adm/wtmpx, which records all logins, logouts, and reboots.
Each entry includes the user name, the login device, the host that the user is logged in from, the date and time
that the user logged in, the time of logout, and the total login time in hours and minutes, including entries for
system reboot times.
The output of the last command can be extremely long. Therefore, you might want to use it with the -n number
option to specify the number of lines to display.
Recording Failed Login Attempts
When a user logs in to a system either locally or remotely, the login program consults the /etc/passwd and the
/etc/shadow files to authenticate the user. It verifies the user name and password entered.
If the user provides a login name that is in the /etc/passwd file and the correct password for that login name,
the login program grants access to the system.

If the login name is not in the /etc/passwd file or the password is not correct for the login name, the login
program denies access to the system. You can log failed command-line login attempts in the
/var/adm/loginlog file. This is a useful tool if you want to determine if attempts are being made to break into
a system.
By default, the loginlog file does not exist. To enable logging, you should create this file with read and write
permissions for the root user only, and it should belong to the sys group.
# touch /var/adm/loginlog
# chown root:sys /var/adm/loginlog
# chmod 600 /var/adm/loginlog
All failed command-line login activity is written to this file automatically after five consecutive failed attempts.
The loginlog file contains one entry for each of the failed attempts. Each entry contains the users login name,
login device (TTY port), and time of the failed attempt. If there are fewer than five consecutive failed attempts, no
activity is logged to this file.
5.2.2. Switching Users on a System

As the system administrator, you should log in to a system as a regular user, and then switch to the root account
only to perform administrative tasks.
You should avoid logging in directly as the root user. This precaution helps protect the system from unauthorized
access, because it reduces the likelihood that the system will be left unattended with the root user logged in. Also,
critical mistakes are less likely to occur if you perform routine work as a regular system user.
Introducing the su Command

su command is used to gain root privileges.
The su command is an application, which provides a means of gaining the authority of another user by supplying
the users password when prompted. If the password is correct, the su command creates a new shell process, as
specified in the shell field of that user accounts /etc/passwd file entry.
The su - (dash) option specifies a complete login by reading all of the users shell initialization files. The - (dash)
option changes your work environment to what would be expected if you had logged in directly as that specified
user. It also changes the users home directory.
Displaying the Effective User ID

When you run the su command, the user ID and the user group ID (GID) change to that of the user to which you
have switched, becoming the EUID and effective group ID (EGID), respectively.
Access to files and directories is determined by the value of the EUID and EGID for the effective user, rather than
by the UID and GID numbers of the original user who logged in to the system.
The whoami command displays the login name of the EUID.
Note The whoami command resides in the /usr/ucb directory.
Displaying the Real User ID

To determine the login name of the original user use the who command with the am i option.
To use the who am i command, at the shell prompt, type the su command and the login name of the user
account to which you want to switch, and press Return. Type the password for the user account, and press
Return. Invoked without a user name, the su command offers access to root account. Because of the authority
given to the root user, the su command maintains its own log file, /var/adm/sulog
How to monitor who is using the su Command

The sulog file lists every use of the su command, not only the su attempts that are used to switch from user to
superuser.
The entries of /var/adm/sulog display the following information:
1. The date and time that the command was entered.

2. If the attempt was successful. A plus sign (+) indicates a successful attempt. A minus sign (-) indicates an
unsuccessful attempt.
3. The port from which the command was issued.
4. The name of the user and the name of the switched identity.
The su logging in this file is enabled by default through the following entry in the /etc/default/su file:
SULOG=/var/adm/sulog
5.2.3. Controlling System Access

System security ensures that the systems resources are used properly. Access controls can restrict who is
permitted access to resources on the system. The Solaris OS features for system security and access control
include the following:
Login administration tools Commands for monitoring and controlling a users ability to log in.
Hardware access Commands for limiting access to the PROM, and for restricting who can boot the system.
Resource access Tools and strategies for maximizing the appropriate use of machine resources while
minimizing the misuse of those resources.
Role-based access control (RBAC) Architecture for creating special, restricted user accounts that are
permitted to perform specific administrative tasks.
Privileges Discrete rights on processes to perform operations. These process rights are enforced in the kernel.
Device management Device policy additionally protects devices that are already protected by UNIX
permissions. Device allocation controls access to peripheral devices, such as a microphone or CD-ROM drive.
Upon deallocation, device-clean scripts can then erase any data from the device.
Basic Audit Reporting Tool (BART) A snapshot, called a manifest, of the file attributes of files on a system. By
comparing the manifests across systems or on one system over time, changes to files can be monitored to reduce
security risks.
File permissions Attributes of a file or directory. Permissions restrict the users and groups that are permitted to
read, write, or execute a file, or search a directory.
Security enhancement scripts Through the use of scripts, many system files and parameters can be adjusted
to reduce security risks.
Using UNIX Permissions to Protect Files

Files can be secured through UNIX file permissions and through ACLs. Files with sticky bits, and files that are
executable, require special security measures.
You can protect the files in a directory and its subdirectories by setting restrictive file permissions on that
directory. Note, however, that superuser has access to all files and directories on the system.
Special File Permissions (setuid, setgid and Sticky Bit)
Three special types of permissions are available for executable files and public directories: setuid, setgid, and
sticky bit. When these permissions are set, any user who runs that executable file assumes the ID of the owner
(or group) of the executable file.
You should monitor your system for any unauthorized use of the setuid permission and the setgid permission to
gain superuser capabilities. A suspicious permission grants ownership of an administrative program to a user
rather than to root or bin.
setuid Permission
When setuid permission is set on an executable file, a process that runs this file is granted access on the basis of
the owner of the file. The access is not based on the user who is running the executable file. This special
permission allows a user to access files and directories that are normally available only to the owner.
For example, the setuid permission on the passwd command makes it possible for users to change passwords. A
passwd command with setuid permission would resemble the following:
-r-sr-sr-x 1 root sys 27220 Jan 23 2005 /usr/bin/passwd

This special permission presents a security risk. Some determined users can find a way to maintain the
permissions that are granted to them by the setuid process even after the process has finished executing.
setgid Permission
The setgid permission is similar to the setuid permission. The processs effective group ID (GID) is changed to the
group that owns the file, and a user is granted access based on the permissions that are granted to that group.
The /usr/bin/mail command has setgid permissions:
-r-x--s--x 1 root mail 67900 Jan 23 2005 /usr/bin/mail
When the setgid permission is applied to a directory, files that were created in this directory belong to the group to
which the directory belongs. The files do not belong to the group to which the creating process belongs. Any user
who has write and execute permissions in the directory can create a file there. However, the file belongs to the
group that owns the directory, not to the group that the user belongs to.
Sticky Bit
The sticky bit is a permission bit that protects the files within a directory. If the directory has the sticky bit set, a file
can be deleted only by the file owner, the directory owner, or by a privileged user. The root user and the Primary
Administrator role are examples of privileged users. The sticky bit prevents a user from deleting other users files
from public directories such as /tmp:
drwxrwxrwt 7 root sys 528 Oct 29 14:49 /tmp
Be sure to set the sticky bit manually when you set up a public directory on a TMPFS file system.
File Permission Modes
The chmod command enables you to change the permissions on a file. You must be superuser or the owner of a
file or directory to change its permissions. You can use the chmod command to set permissions in either of two
modes:
Absolute Mode Use numbers to represent file permissions. When you change permissions by using the
absolute mode, you represent permissions for each triplet by an octal mode number. Absolute mode is the
method most commonly used to set permissions.
Symbolic Mode Use combinations of letters and symbols to add permissions or remove permissions.
You must use symbolic mode to set or remove setuid permissions on a directory. In absolute mode, you set
special permissions by adding a new octal value to the left of the permission triplet. The following table lists the
octal values for setting special permissions on a file.
The following table lists the octal values for setting file permissions in absolute mode.
who Specifies whose permissions are to be changed.
operator Specifies the operation to be performed.
permissions Specifies what permissions are to be changed.
Special File Permissions in Absolute Mode
Using Access Control Lists to Protect Files

Traditional UNIX file protection provides read, write, and execute permissions for the three user classes: file
owner, file group, and other. An access control list (ACL) provides better file security by enabling you to do the
following:
Define file permissions for the file owner, the group, other, specific users and groups
Define default permissions for each of the preceding categories

For example, if you want everyone in a group to be able to read a file, you can simply grant group read
permissions on that file. Now, assume that you want only one person in the group to be able to write to that file.
Standard UNIX does not provide that level of file security. However, an ACL provides this level of file security.
ACL entries define an ACL on a file. The entries are set through the setfacl command. ACL entries consist of the
following fields separated by colons:
entry-type:[uid|gid]:perms
entry-type Is the type of ACL entry on which to set file permissions. For example, entry-type can be user (the
owner of a file) or mask (the ACL mask).
uid Is the user name or user ID (UID).
gid Is the group name or group ID (GID).
perms Represents the permissions that are set on entry-type. perms can be indicated by the symbolic characters
rwx or an octal number. These are the same numbers that are used with the chmod command.
Caution UFS file system attributes such as ACLs are supported in UFS file systems only. Thus, if you restore or
copy files with ACL entries into the /tmp directory, which is usually mounted as a TMPFS file system, the ACL
entries will be lost. Use the /var/tmp directory for temporary storage of UFS files.
ACL Entries for Files
The following table lists the valid ACL entries that you might use when setting ACLs on files. The first three ACL
entries provide the basic UNIX file protection.
ACL Entries for Directories
We can set default ACL entries on a directory. Files or directories created in a directory that has default ACL
entries will have the same ACL entries as the default ACL entries.
When you set default ACL entries for specific users and groups on a directory for the first time, you must also set
default ACL entries for the file owner, file group, others, and the ACL mask. These entries are required. They are
the first four default ACL entries in the following table.
Default ACL Entry Description
d[efault]:u[ser]::perms Default file owner permissions.
d[efault]:g[roup]::perms Default file group permissions.
d[efault]:o[ther]:perms Default permissions for users other than the file owner or members of the file group.
d[efault]:m[ask]:perms Default ACL mask.
d[efault]:u[ser]:uid:perms Default permissions for a specific user. For uid, you can specify either a user name
or a
numeric UID.
d[efault]:g[roup]:gid:perms Default permissions for a specific group. For gid, you can specify either a group
name
or a numeric GID.
Commands for Administering ACLs

The following commands administer ACLs on files or directories.
setfacl command Sets, adds, modifies, and deletes ACL entries.
getfacl command Displays ACL entries.
5.2.4. ftp, rlogin, ssh

File Transfer Protocol (FTP) Access
The Solaris OE provides an American Standard Code for Information Interchange (ASCII) file named
/etc/ftpd/ftpusers. The /etc/ftpd/ftpusers file lists the names of users who are prohibited from connecting to the
system through the FTP protocol. Each line entry in this file contains a login name for a restricted user.

The FTP server daemon in.ftpd reads the /etc/ftpd/ftpusers file when an FTP session is invoked. If the login name
of the user matches one of the listed entries, it rejects the login session and sends the Login failed error message.
The root entry is included in the ftpusers file as a security measure. The default security policy is to disallow
remote logins for the root user. The policy is also followed for the default value set as the CONSOLE entry in the
/etc/default/login file.
The /etc/hosts.equiv and $HOME/.rhosts Files
Typically, when a remote user requests login access to a local host, the first file read by the local host is its
/etc/passwd file. An entry for that particular user in this file enables that user to log in to the local host from a
remote system. If a password is associated with that account, then the remote user is required to supply this
password at log in to gain system access. If there is no entry in the local hosts /etc/passwd file for the remote
user, access is denied.
The /etc/hosts.equiv and $HOME/.rhosts files bypass this standard password-based authentication to determine if
a remote user is allowed to access the local host, with the identity of a local user. These files provide a remote
authentication procedure to make that determination.
This procedure first checks the /etc/hosts.equiv file and then checks the $HOME/.rhosts file in the home directory
of the local user who is requesting access. The information contained in these two files (if they exist) determines if
remote access is granted or denied. The information in the /etc/hosts.equiv file applies to the entire system, while
individual users can maintain their own $HOME/.rhosts files in their home directories.
Entries in the /etc/hosts.equiv and $HOME/.rhosts Files
While the /etc/hosts.equiv and $HOME/.rhosts files have the same format, the same entries in each file have
different effects. Both files are formatted as a list of one-line entries, which can contain the following types of
entries:
hostname
hostname username
+
The host names in the /etc/hosts.equiv and $HOME/.rhosts files must be the official name of the host, not one of
its alias names.
If the local hosts /etc/hosts.equiv file contains the host name of a remote host, then all regular users of that
remote host are trusted and do not need to supply a password to log in to the local host. This is provided so that
each remote user is known to the local host by having an entry in the local /etc/passwd file; otherwise, access is
denied.
This funtionality is particularly useful for sites where regular users commonly have accounts on many different
systems, eliminating the security risk of sending ASCII passwords over the network.
The /etc/hosts.equiv file does not exist by default. It must be created if trusted remote user access is required on
the local host.
The $HOME/.rhosts File Rules
While the /etc/hosts.equiv file applies system-wide access for nonroot users, the .rhosts file applies to a specific
user.
All users, including the root user, can create and maintain their own .rhosts files in their home directories. For
example, if you run an rlogin process from a remote host to gain root access to a local host, the /.rhosts file is
checked in the root home directory on the local host.
If the remote host name is listed in this file, it is a trusted host, and, in this case, root access is granted on the
local host. The CONSOLE variable in the /etc/default/login file must be commented out for remote root logins. The
$HOME/.rhosts file does not exist by default. You must create it in the users home directory.
SSH (Solaris Secure Shell) It is a secure remote login and transfer protocol that encrypts
communications over an insecure network.
In Solaris Secure Shell, authentication is provided by the use of passwords, public keys, or both. All network
traffic is encrypted. Thus, Solaris Secure Shell prevents a would-be intruder from being able to read an
intercepted communication. Solaris Secure Shell also prevents an adversary from spoofing the system.
With Solaris Secure Shell, you can perform these actions:

Log in to another host securely over an unsecured network.

Copy files securely between the two hosts.
Run commands securely on the remote host.
A Typical Solaris Secure Shell Session
The Solaris Secure Shell daemon (sshd) is normally started at boot time when network services are started. The
daemon listens for connections from clients. A Solaris Secure Shell session begins when the user runs an ssh,
scp, or sftp command. A new sshd daemon is forked for each incoming connection. The forked daemons handle
key exchange, encryption, authentication, command execution, and data exchange with the client. These session
characteristics are determined by client-side configuration files and server-side configuration files. Command-line
arguments can override the settings in the configuration files. The client and server must authenticate themselves
to each other. After successful authentication, the user can execute commands remotely and copy data between
hosts.

Chapter 6 Printers Page 79 of 198
6. Printers
The Solaris printing service provides a complete network-printing environment. This environment allows sharing
of printers across machines, management of special printing situations such as forms, and filtering output to
match special printer types such as those that use the popular PostScript page description language. This release
also supports IPP, and also expanded printer support (through the use of additional transformation software,
raster image processor (RIP), and PostScript Printer Description (PPD) files, you can print to a wider range of
printers.
6.1. Printing Terminology

Printing services on Solaris use a set of special commands, daemons, filters, and directories. Files are not directly
sent to the printer, but are spooled and then printed, freeing whatever application submitted the print request to
move on to other tasks. The term spooling refers to the temporary storage of a file for later use. It comes from the
early history of computing when files to be printed were saved temporarily on spools of magnetic tape.
Here spooling is defined as the process of placing a file in a special directory while it waits to be printed. Spooling
puts the SunOS multi-tasking capability to good use by allowing printing to occur at the same time as other
activities. An example of a printing service is illustrated
Print File
Spool directory
lpsched, output filters, etc.
Printer
Print Client Print Server
The actual work of printing is executed by a printing daemon. Daemon is the nickname given to all processes
running on a UNIX system. The main printing daemon is lpsched.
Most output bound for a printer will require filtering before it is printed. The term filter is used to describe a
program that transforms the content of one file into another format as the file passes through the program. For
instance, when an ASCII file is sent to the printer that accepts the PostScript page description language, the print
service first runs the file through a filter to transform the file from ASCII into PostScript.
The resulting PostScript file contains complete instructions in a form the printer can use to print the page, and is
somewhat larger than the original file due to the addition of this information. After filtering, the PostScript file is
sent to the printer which reads a description of the pages to be printed and prints them.
Printing can be set up as a network-wide service. There are three varieties of network printing.
1. Machines with directly connected printers that accept print requests from other machines are called
print servers.
2. Machines that submit print requests over the network to other machines are called print-clients. A
machine can be both a print server and a print client.
3. Printers directly attached to the workstation are known as local printers, whereas printers attached to
other workstations reached via the network are known as remote printers.

Finally, it is increasingly common for printers to be directly attached to the network. These network printers can
either be served from a print server or act as their own print server, depending on the facilities provided in the
printer by the manufacturer.
6.2. Printing in the Solaris Operating System

The Solaris printing software provides an environment for setting up and managing client access to printers on a
network. The Solaris printing software contains these tools:
1. Solaris Print Manager A graphical user interface (GUI) that provides the ability to manage printing
configuration on a local system or in a name service.
2. The LP print service commands A command-line interface (CLI) that is used to set up and manage
printers on a local system or in a name service. These commands also provide functionality that extend
beyond the other print management tools.
Even if you do use Solaris Print Manager to set up printing, you will have to use some of the lp print service
commands to completely manage printing on the Solaris Operating System.
Solaris Print Manager
Solaris Print Manager is a Java technology-based GUI that enables you to manage local and remote printer
configuration. This tool can be used in the following name service environments: LDAP, NIS, NIS+, and files.
Solaris Printer Manager centralizes printer information when used in conjunction with a name service. Using a
name service for storing printer configuration information is desirable because a name service makes printer
information available to all systems on the network. This method provides easier printing administration.
Solaris Print Manager recognizes existing printer information on the printer servers, print clients, and in the name
service databases. No conversion tasks are required to use Solaris Print Manager as long as the print clients are
running either the Solaris 2.6, 7, 8, 9, or 10 releases.
The Solaris Print Manager package is SUNWppm.
Printing Support in the Name Service Switch
The printers database in /etc/nsswitch.conf, the name service switch file, provides centralized printer configuration
information to print clients on the network. By including the printers database and corresponding sources of
information in the name service switch file, print clients automatically have access to printer configuration
information without having to add it to their own systems. The default printers entry in the /etc/nsswitch.conf file
for files, LDAP, NIS, and NIS+ environments are described in the following table. The nisplus keyword represents
the printers.org_dir table.
For example, if your name service is NIS, printer configuration information on print clients is searched for in the
following sources in this order:
user Represents the users $HOME/.printers file
files Represents the /etc/printers.conf file
nis Represents the printers.conf.byname table
Most printing configuration tasks can be accomplished with Solaris Print Manager. However, if you need to write
interface scripts or add your own filters, you need to use the LP print service commands. These commands
underlie Solaris Print Manager.
Managing Network Printers

A network printer is a hardware device that is connected directly to the network. A network printer transfers data
directly over the network to the output device. The printer or network connection hardware has its own system
name and IP address. Network printers often have software support provided by the printer vendor. If your printer
has printer vendor-supplied software, then use the printer vendor software. If the network printer vendor does not
provide software support, Sun supplied software is available. This software provides generic support for network-
attached printers. However, this software is not capable of providing full access to all possible printer capabilities.
6.3. Administering Printers

There are 2 sides to managing printers:
The technical aspect of connecting a printer to a system and configuring software to work with the printer
Printing policy, including who should be allowed to use a particular printer or certain forms, or whether a particular
printer should be shared among workstations on the network.
A printing service setup consists of 4 phases:
1. A connection to the printer must be made. The printer is physically connected to a machine called the
print server, or the printer must be connected to the network and configured to communicate with the
other systems on the network.
2. For the print server or network printer to be configured some additional communications software needed
should be installed.
3. Print service is configured for other machines that will share the printer to act as print clients.
4. Finally, configuration of special features such as print-wheels, forms, and printer access controls may be
required to complete the installation.
After you set up print servers and print clients, you might need to perform these administration tasks frequently:
1. Delete a printer
2. Delete remote printer access
3. Check the status of printers
4. Restart the print scheduler
You can customize the LP print service in the following ways:
1. Adjust the printer port characteristics.
2. Adjust the terminfo database.
3. Customize the printer interface program.
4. Create a print filter.
5. Define a form.
How the Print Software Locates Printers

1. A user submits a print request from a print client by using the lp or lpr command. The user can specify a
destination printer name or class in any of three styles:
Atomic style, which is the lp command and option, followed by the printer name or class, as shown in this
example:
% lp -d neptune filename
POSIX style, which is the print command and option, followed by server:printer, as shown in this
example:
% lpr -P galaxy:neptune filename
Context-based style, as shown in this example:
% lpr -d thisdept/service/printer/printer-name filename
2. The print command locates a printer and printer configuration information as follows:
The print command checks to see if the user specified a destination printer name or printer class in one
of the three valid styles.
If the user didnt specify a printer name or class in a valid style, the command checks the users
PRINTER or LPDEST environment variable for a default printer name.
If neither environment variable for the default printer is defined, the command checks the sources
configured for the printers database in the /etc/nsswitch.conf file. The name service sources might be
one of the following:

1. LDAP directory information tree in the domains ou=printers container

2. NIS printers.conf.byname map
3. NIS+ printers.conf_dir map

Definition of the LP Print Service

The LP print service is a set of software utilities that allows users to print files while users continue to work.
Originally, the print service was called the LP spooler. LP represents line printer, but the meaning now includes
many other types of printers, such as laser printers. Spool is an acronym for system peripheral operation off-line.
The print service consists of the LP print service software, any print filters you might provide, and the hardware,
such as the printer, system, and network connections.
LP Print Service Directories
The files of the LP print service are distributed among the directories that are shown in the following table.
LP Print Service Configuration Files

The lpsched daemon stores configuration information in the /etc/lp directory, as described in the following
table.

Contents of /etc/lp directory
Note You can check the contents of the configuration files, but you should not edit these files directly. Instead,
use the lpadmin command to make configuration changes. Your changes are written to the configuration files in
the /etc/lp directory. The lpsched daemon administers and updates the configuration files.
The terminfo Database
The /usr/share/lib directory contains the terminfo database directory. This directory contains definitions
for many types of terminals and printers. The LP print service uses information in the terminfo database to
perform the following tasks:
1. Initializes a printer
2. Establishes a selected page size, character pitch, line pitch, and character set
3. Communicates the sequence of codes to a printer
Each printer is identified in the terminfo database with a short name. If necessary, you can add entries to the
terminfo database, but doing so is tedious and time-consuming.
Daemons and LP Internal Files
The /usr/lib/lp directory contains daemons and files used by the LP print service, as described in the
following table.

LP Print Service Log Files

The LP print service maintains two sets of log files that are described in the following table.
Spooling Directories
Files queued for printing are stored in the /var/spool/lp directory until they are printed, which might be only
seconds.
How LP Administers Files and Schedules Local Print Requests
The LP print service has a scheduler daemon called lpsched. The scheduler daemon updates the LP system
files with information about printer setup and configuration. The lpsched daemon schedules all local print
requests on a print server, as shown in the following figure. Users can issue the requests from an application or
from the command line. Also, the scheduler tracks the status of printers and filters on the print server. When a
printer finishes a request, the scheduler schedules the next request n the queue on the print server, if a next
request exists.
Without rebooting the system, you can stop the scheduler with the svcadm disable application/print/server
command. Then, restart the scheduler with the svcadm enable application/print/server command. The scheduler
for each system manages requests that are issued to the system by the lp command.
How Remote Printing Works
The following figure shows what happens when a user on a Solaris print client submits a print request to an lpd-
based print server. The command opens a connection and handles its own communications with the print server
directly.

Printing Service Commands

lpadmin Printer setup and few management aspects.
printmgr Graphical printer setup tool.

lpusers Manages printer job priorities.
lpmove Changes the destination of print jobs in the spool area.

lpforms Manages forms and associated parameters.
lpshut Stops the entire printing service.
lpsched Starts the printing service.

lpset Defines printer configuration in /etc/printers.conf..
lp Submits print jobs.
lpstat Displays the status of the printing service and the status of individual jobs and printers.
cancel Stops individual print jobs.
enable Starts a printer printing.
disable Stops printing on a particular printer.

accept Starts print jobs accumulating in the print spool for a particular printer.
reject Stops the print service from accepting jobs to be put in the printer spool area for printing on
a particular printer.

Chapter 7 System Processes & Job Automation Page 87 of 194
7. System Processes & Job Automation

Administering Solaris systems can be a time-consuming process. Simply keeping track of system files could be a
full-time job, let alone managing security and user accounts. Lets look at few of the tools to automate ceratin
mundane system administration chores.
7.1. Updating System Files

One of the most frequent housekeeping jobs an administrator faces is keeping system files current. For example,
an administrator at a small site might manage 25 to 30 machines. Each machine has a private copy of the
/usr/lib/sendmail software installed on the local disk. How could the administrator efficiently update the sendmail
software on 30 machines?
rdist command
The /bin/rdist command is a remote file distribution utility. The rdist utility allows the administrator to set up a
central repository of files which must be updated on multiple machines within the corporate network. To update all
machines on the network, the administrator makes changes to the files in the central repository, and then uses
rdist utility to distribute these files to the other hosts on the network.
7.2. System Automation with Shell Scripts

The UNIX shell is an interactive programming language, as well as command interpreter. The shell executes
commands received directly from the user sitting at the terminal. Alternately, the shell can execute commands
received from a file. A file containing shell-programming commands is called a shell file, or shell script.
Many of the operations performed by a sys-admin are accomplished by typing commands at the terminal. Due to
file access permissions, these commands must often be issued by root. The standard shell for root is /sbin/sh, a
statically linked version of the Bourne shell. On the other hand, the program in /usr/bin/sh is a dynamically linked
version of the Bourne shell.
(A statically linked program is one that links all library functions at compile time. If changes made to a library
function due to compiler or other system software upgrades, the program must be recompiled to take advantage
of those changes. A statically linked program will usually be quite large because it includes all library functions.
A dynamically linked program loads the library functions at run-time, which allows the program to include latest
version of all library functions upon invocation. No recompilation is required to enjoy the advantages of updated
library routines. Dynamically linked programs are usually smaller than statically linked counterparts because the
library functions are not included in the on-disk binary image.)
7.3. Automating Commands with cron and at

You can set up many system tasks to execute automatically. Some of these tasks should occur at regular
intervals. Other tasks need to run only once, perhaps during off hours such as evenings or weekends.
The crontab command schedules repetitive commands. The at command schedules tasks that execute once.
The above table summarizes the commands

For Scheduling Repetitive Jobs: crontab
You can schedule routine system administration tasks to execute daily, weekly, or monthly by using the crontab
command. Daily crontab system administration tasks might include the following:

Removing files more than a few days old from temporary directories
Executing accounting summary commands
Taking snapshots of the system by using the df and ps commands
Performing daily security monitoring
Running system backups
Weekly crontab system administration tasks might include the following:
Rebuilding the catman database for use by the man -k command
Running the fsck -n command to list any disk problems
Monthly crontab system administration tasks might include the following:
Listing files not used during a specific month
Producing monthly accounting reports
Additionally, users can schedule crontab commands to execute other routine system tasks, such as sending
reminders and removing backup files.
For Scheduling a Single Job: at
The at command allows you to schedule a job for execution at a later time. The job can consist of a single
command or a script. Similar to crontab, the at command allows you to schedule the automatic execution of
routine tasks. However, unlike crontab files, at files execute their tasks once. Then, they are removed from their
directory. Therefore, the at command is most useful for running simple commands or scripts that direct output into
separate files for later examination. Submitting an at job involves typing a command and following the at
command syntax to specify options to schedule the time your job will be executed. The at command stores the
command or script you ran, along with a copy of your current environment variable, in the /var/spool/cron/atjobs
directory. Your at job file name is given a long number that specifies its location in the at queue, followed by the .a
extension, such as 793962000.a. The cron daemon checks for at jobs at startup and listens for new jobs that are
submitted. After the cron daemon executes an at job, the at jobs file is removed from the atjobs directory.
7.3.1. Scheduling a Repetitive System Task (cron)

The cron daemon schedules system tasks according to commands found within each crontab file. A crontab file
consists of commands, one command per line, that will be executed at regular intervals. The beginning of each
line contains date and time information that tells the cron daemon when to execute the command. For example, a
crontab file named root is supplied during SunOS software installation. The files contents include these command
lines:
10 3 * * * /usr/sbin/logadm (1)
15 3 * * 0 /usr/lib/fs/nfs/nfsfind (2)
1 2 * * * [ -x /usr/sbin/rtc ] && /usr/sbin/rtc -c > /dev/null 2>&1 (3)
30 3 * * * [ -x /usr/lib/gss/gsscred_clean ] && /usr/lib/gss/gsscred_clean (4)
The following describes the output for each of these command lines:
The first line runs the logadm command at 3:10 a.m. every day.
The second line executes the nfsfind script every Sunday at 3:15 a.m.
The third line runs a script that checks for daylight savings time (and make corrections, if necessary) at
2:10 a.m. daily. If there is no RTC time zone, nor an /etc/rtc_config file, this entry does nothing.
x86 only The /usr/sbin/rtc script can only be run on an x86 based system.
The fourth line checks for (and removes) duplicate entries in the Generic Security Service table,
/etc/gss/gsscred_db, at 3:30 a.m. daily.
The crontab files are stored in the /var/spool/cron/crontabs directory. Several crontab files besides root are
provided during SunOS software installation. See the following table:

Besides the default crontab files, users can create crontab files to schedule their own system tasks. Other crontab
files are named after the user accounts in which they are created, such as bob, mary, smith, or jones. To access
crontab files that belong to root or other users, superuser privileges are required. Procedures explaining how to
create, edit, display, and remove crontab files are described in subsequent sections.
How the cron Daemon Handles Scheduling
cron daemon manages automatic scheduling of crontab commands. The role of cron daemon is to check
/var/spool/cron/crontab directory for the presence of crontab files. The cron daemon performs the
following tasks at startup:
Checks for new crontab files
Reads the execution times that are listed within the files
Submits the commands for execution at the proper times
Listens for notifications from the crontab commands regarding updated crontab files.
In much the same way, the cron daemon controls the scheduling of at files. These files are stored in the
/var/spool/cron/atjobs directory. The cron daemon also listens for notifications from the crontab
commands regarding submitted at jobs.
Syntax of crontab File Entries
A crontab file consists of commands, one command per line that execute automatically at the time specified by
the first five fields of each command line. These five fields, described in the following table, are separated by
spaces.
Follow these guidelines for using special characters in crontab time fields:
Use a space to separate each field.
Use a comma to separate multiple values.
Use a hyphen to designate a range of values.
Use an asterisk as a wildcard to include all possible values.
Use a comment mark (#) at the beginning of a line to indicate a comment or a blank line.
For example, the following crontab command entry displays a reminder in the users console window at 4 p.m. on
the first and fifteenth days of every month.
0 16 1,15 * * echo Timesheets Due > /dev/console
Each command within a crontab file must consist of one line, even if that line is very long. The crontab file does
not recognize extra carriage returns.
Controlling Access to the crontab Command

You can control access to the crontab command by using two files in the /etc/cron.d directory: cron.deny and
cron.allow. These files permit only specified users to perform crontab command tasks such as creating, editing,
displaying, or removing their own crontab files. The cron.deny and cron.allow files consist of a list of user names,
one user name per line. These access control files work together as follows:
If cron.allow exists, only the users who are listed in this file can create, edit, display, or remove crontab
files.
If cron.allow does not exist, all users can submit crontab files, except for users who are listed in
cron.deny.
If neither cron.allow nor cron.deny exists, superuser privileges are required to run the crontab command.
Superuser privileges are required to edit or create the cron.deny and cron.allow files. The cron.deny file, which is
created during SunOS software installation, contains the following user names:
$ cat /etc/cron.d/cron.deny
daemon
bin
smtp
nuucp
listen
nobody
noaccess
None of the user names in the default cron.deny file can access the crontab command. You can edit this file to
add other user names that will be denied access to the crontab command. No default cron.allow file is supplied.
So, after Solaris software installation, all users (except users who are listed in the default cron.deny file) can
access the crontab command. If you create a cron.allow file, only these users can access the crontab command.
How to Verify Limited crontab Command Access

To verify if a specific user can access the crontab command, use the crontab l command while you are logged
into the user account.
$ crontab -l
If user can access crontab command, and already has created a crontab file, the file is displayed. Otherwise, if
the user can access crontab command but no crontab file exists, a message similar to following message is
displayed:
crontab: cant open your crontab file
Either this user either is listed in the cron.allow file (if the file exists), or the user is not listed in the cron.deny file. If
the user cannot access the crontab command, the following message is displayed whether or not a previous
crontab file exists:
crontab: you are not authorized to use cron. Sorry.
This message means that either the user is not listed in the cron.allow file (if the file exists), or the user is listed in
the cron.deny file.
7.3.2. Scheduling a Single System Task (at)

The following sections describe how to use the at command to perform the following tasks:
Schedule jobs (command and scripts) for execution at a later time
How to display and remove these jobs
How to control access to the at command
By default, users can create, display, and remove their own at job files. To access at files that belong to root or
other users, you must have superuser privileges. When you submit an at job, it is assigned a job identification
number along with the .a extension. This designation becomes the jobs file name, as well as its queue number.
Description of the at Command
Submitting an at job file involves these steps:
1. Invoking the at utility and specifying a command execution time

2. Typing a command or script to execute later

For example, the following at job removes core files from the user account smith near midnight on the last day of
July.
$ at 11:45pm July 31
at> rm /home/smith/*core*
at> Press Control-d
commands will be executed using /bin/csh
job 933486300.a at Tue Jul 31 23:45:00 2004
Controlling Access to the at Command
You can set up a file to control access to the at command, permitting only specified users to create, remove, or
display queue information about their at jobs. The file that controls access to the at command, /etc/cron.d/at.deny,
consists of a list of user names, one user name per line. The users who are listed in this file cannot access at
commands. The at.deny file, which is created during SunOS software installation, contains the following user
names:
daemon
bin
smtp
nuucp
listen
nobody
noaccess
With superuser privileges, you can edit the at.deny file to add other user names whose at command access you
want to restrict.
7.4. Viewing System Processes

A process is any program that is running on the system. All processes are assigned a unique process
identification (PID) number, which is used by the kernel to track and manage the process. The PID numbers are
used by the root and regular users to identify and control their processes.
Using the CDE Process Manager

The Solaris OE Common Desktop Environment (CDE) provides a Process Manager to monitor and control
processes that are running on the local system.
Using the prstat Command

The prstat command examines and displays information about active processes on the system. This command
enables you to view information by specific processes, user identification (UID) numbers, central processing unit
(CPU) IDs, or processor sets. By default, the prstat command displays information about all processes sorted by
CPU usage. To use the prstat command, perform the command:
# prstat
To quit the prstat command, type q.
Note The kernel and many applications are now multithreaded. A thread is a logical sequence of program
instructions written to accomplish a particular task. Each application thread is independently scheduled to run on
an LWP, which functions as a virtual CPU. LWPs in turn, are attached to kernel threads, which are scheduled to
run on actual CPUs.
Note Use the priocntl (1) command to assign processes to a priority class and to manage process priorities.
The nice (1) command is only supported for backward compatibility to previous Solaris OE releases. The priocntl
command provides more flexibility in managing processes.
Clearing Frozen Processes

You use the kill command or the pkill command to send a signal to one or more running processes. You would
typically use these commands to terminate or clear an unwanted process.

Using the kill and pkill Commands

You use the kill or pkill commands to terminate one or more processes. The format for the kill command is:
kill -signal PID
The format for the pkill command is:
pkill -signal Process
Before you can terminate a process, you must know its name or PID. Use either the ps or pgrep command to
locate the PID for the process. The following examples use the pgrep command to locate the PID for the mail
processes.
$ pgrep -l mail
551 sendmail
12047 dtmail
$
$ pkill dtmail
The following examples use the ps and pkill commands to locate and terminate the dtmail process.
# ps -e |grep mail
314 ? 0:00 sendmail
1197 ? 0:01 dtmail
# kill 1197
To terminate more than one process at the same time, use the following syntax:
$ kill signal PID PID PID PID
$ pkill signal process process
You use the kill command without a signal on the command line to send the default Signal 15 to the process. This
signal usually causes the process to terminate.
1 - SIGHUP A hangup signal to cause a telephone line or terminal connection to be dropped. For
certain daemons, such as inetd and in.named, a hangup signal will cause daemon to reread its
configuration file.
2 - SIGINT An interrupt signal from your keyboardusually from a Control-C key combination.
9 - SIGKILL A signal to kill a process. A process cannot ignore this signal.
15 - SIGTERM A signal to terminate a process in an orderly manner. Some processes ignore this
signal.
A complete list of signals that the kill command can send can be found by executing the command kill -l, or by
referring to the man page for signal:
# man -s3head signal
Some processes can be written to ignore Signal 15. Processes that do not respond to a Signal 15 can be
terminated by force by using Signal 9 with the kill or pkill commands. You use the following syntax:
$ kill -9 PID
$ pkill -9 process
Caution Use the kill -9 or pkill -9 command as a last resort to terminate a process. Using kill -9 on a process
that controls a database application or a program that updates files can be disastrous. The process is terminated
instantly with no opportunity to perform an orderly shutdown.
Performing a Remote Login

When a workstation is not responding to your keyboard or mouse input, CDE might be frozen. In such cases, you
may be able to remotely access your workstation by using rlogin command or by using telnet command from
another system.

Killing the Process for a Frozen Login

After you are connected remotely to your system, you can invoke the pkill command to terminate the corrupted
session on your workstation. In the following example, the rlogin command is used to log in to sys42, from which
you can issue a pkill command.
$ rlogin sys42
Password: EnterPassword
Last login: Mon Jan 14 10:11:56 from sys43
Sun Microsystems Inc. SunOS 5.9 Beta May 2002
$ pkill -9 Xsun
or
$ pkill -9 Xsun

Chapter 8 Backup and Restore Page 94 of 198
8. Backup and Restore

8.1. Fundamentals of Backups
System administrators most important task is to ensure the availability of user data. Every file, every database,
every byte of information stores on the system must be available. This requirement dictates the need for backup
copies of all data in the event there is a need to retrieve such information at a later date.
However, making a copy of the data and storing it in another office in the same building may not be a solution to
the problem. For instance, in the event of a natural calamity the corporation may need to have copies of the data
in remote locations to ensure survivability and accessibility of the backup media.
In the event of h/w failure or some other form of disaster, the system administrator should be able to reload the
bulk of user information from backup media. There will always be some loss of information. It is impossible to
backup every keystroke as it occurs. Therefore it is possible to lose information entered into the system between
backups. The goal of a backup procedure is to minimize data loss and allow the corporation to reload quickly and
continue with business.
Which Files should be Backed Up?

Backing up all files on the system at regular intervals is good practice. Some files, however rarely change. The
administrator needs to examine the content of system disks to identify the files that should be part of the file
system backups, as well as files to be eliminated from regular backups.
Some programs are part of the OS. Administrators often decide not to backup the OS binaries, opting to reload
them from the distribution media in the event of a loss. This practice requires making a backup of any OS related
files that are created or changed. A few examples might be the NIS+ database, the password file, shadow file, rc
files, and customizations that effect these files.
Another set of files that may be eliminated from regular backups are vendor-supplied binaries. If the distribution
media for commercially purchased software is available, regular backups of these files are not necessary. Again,
the administrator should ensure that any customized files or start-up scripts required for those packages are on
the backup list.
Files that should be backed up regularly include user files, corporate databases or other important data, and files
that have been changed since the time of the last backup. On large systems the amount of data to be backed up
may exceed several GBs a day. Consequently, the administrator should decide how and when to perform
backups in order to minimize impact on the system and loss of important data.
Backup Frequency

Frequency is another very important factor in successful file system backup strategies. The administrator must
determine how much can be lost before seriously affecting the organizations ability to do business. Corporations
that use computers for financial transactions, stock and commodities trading, and insurance activities would be a
few examples, which dont allow any data loss. In these cases the loss of a single transaction is not acceptable.
A reasonable backup schedule for a typical corporation would call for some form of backup to be performed
everyday. In addition, the backups must be performed every day so that the operator knows which tape to use to
reload, and to force the administrator into a schedule. The fact that backups must be maintained on a rigid
schedule lends support to the automated backup methods.
Backup Scheduling
After determining the files to backup and the frequency of backup, its time to decide about the backup schedule
and also the devices to be used for backup.
8.2. Types of Backups

Several types of backups may be performed, and the simplest type is a full dump. A full dump is also referred to
as a level 0 dump. A full dump copies every disk file to the backup media. On systems with large disk storage
capacity, it might not be possible to make full dumps very often due to the cost of the tapes, tape storage space
requirements, and the amount of time required to copy files to the tapes. Because full dumps are expensive in
terms of time and resources, most programs written to perform backups allow for some form of incremental dump.
In an incremental dump, files created or modified since the last dump are copied to the backup media. For
example, if a full dump is performed on a Sunday, the Monday incremental dump would contain only the files
created or changed since the last Sunday dump.
The type of dump to be performed will typically rely on the chosen backup strategy. The strategy includes factors
such as how long to keep copies of the dump media on hand, what type of dump to perform on which day of the
week, and how easily information can be restored from the backup media. In order to ensure successful dumps, it
is recommended that the system be shut down to the single-user init state.
Typical Backup Strategies

Full dumps allow you to establish a snapshot of the system at a given point in time. All corporate data should be
contained on a full dump. Incremental dumps allow the administrator to recover active files with a minimum of
media and time. In case of incremental dumps, a level N dump will backup all files altered or created since the
last dump at a lower level.
Backup Interval Terms and Definitions

Volume Calendar Backup

Day Date L T Let us examine 3 of the popular backup strategies:
e a
1. Volume/Calendar Backup
v p
e e 2. Grandfather/Father/Son Backup
l
3. Tower of Hanoi Backup
Sun Date 1 0 A
Volume/Calendar Backup
Mon Date 2 5 B
Tue Date 3 5 C This strategy calls for a full system backup once a month. An incremental backup
Wed Date 4 5 D is performed once a week for files that change often. Daily incremental backups
catch the files that have changed since the last daily backup.
Thu Date 5 5 E
Fri Date 6 5 F A typical schedule would be to perform the full (level 0) backup one Sunday a
Sat Date 7 5 G 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
Sun Date 8 3 H complete sets of media (one monthly tape, one weekly tape, and six daily tapes).
Mon Date 9 5 B
Recovering from complete data loss with the volume/calendar scheme requires
Tue Date 10 5 C
restoring from the most recent full backup, then restoring from the most recent
Wed Date 11 5 D weekly backup, and finally, restoring from each daily backup tape written since the
Thu Date 12 5 E weekly backup.
Fri Date 13 5 F
An advantage to this backup scheme is that it requires a minimum of media. One
Sat Date 14 5 G problem with this backup scheme is that the tapes are immediately reused. For
Sun Date 15 3 H example, every Monday overwrites last Mondays backup information. Consider
Mon Date 16 5 B what would happen if one disk drives fail during second Monday backup. It would
Tue Date 17 5 C not be possible to recover all the data, because the system was in the process of
overwriting the backup tape when the drive failed.
Wed Date 18 5 D
Thu Date 19 5 E Grandfather /Father /Son Backup
Fri Date 20 5 F
Sat Date 21 5 G This strategy is similar to the volume/calendar strategy. The major difference
between the 2 schemes is that this method incorporates a one-month archive in
Sun Date 22 3 H the backup scheme. This eliminates the problem of overwriting a tape before
Mon Date 23 5 B completing a more recent backup of the file system.
Tue Date 24 5 C
Implementing this strategy requires performing a full dump once a month to new
Wed Date 25 5 D media. Once a week, an incremental (level 3) backup must be performed which
Thu Date 26 5 E captures all files changed since the last weekly backup. This weekly backup
Fri Date 27 5 F should also be saved on new media. Each day, an incremental level 5 backup
Sat Date 28 5 G must be performed to capture files that have changed since the last daily backup.
The daily backups reuse the tapes written one week earlier.
Sun Date 29 3 H
Mon Date 30 5 B
Tue Date 31 5 C

GRANDFATHER/FATHER/SON BACKUP
Day Date L T Day Date L T Day Date L T

e a e a e a
v p v p v p
e e e e e e
l l l
Sun Date 1 0 A Wed Date 1 5 D Wed Date 1 5 D

Mon Date 2 5 B Thu Date 2 5 E Thu Date 2 5 E
Tue Date 3 5 C Fri Date 3 5 F Fri Date 3 5 F
Wed Date 4 5 D Sat Date 4 3 M Sat Date 4 3 K
Thu Date 5 5 E Sun Date 5 5 H Sun Date 5 5 H
Fri Date 6 5 F Mon Date 6 5 B Mon Date 6 5 B
Sat Date 7 3 G Tue Date 7 5 C Tue Date 7 5 C
Sun Date 8 5 H Wed Date 8 5 D Wed Date 8 5 D
Wed Date 11 5 D Sat Date 11 3 G Sat Date 11 3 M
Sat Date 14 3 I Tue Date 14 5 C Tue Date 14 5 C
Wed Date 18 5 D Sat Date 18 3 I Sat Date 18 3 G
Sat Date 21 3 J Tue Date 21 5 C Tue Date 21 5 C
Wed Date 25 5 D Sat Date 25 3 J Sat Date 25 3 I
Thu Date 26 5 E Sun Date 26 0 A Sun Date 26 0 L
Fri Date 27 5 F Mon Date 27 5 A Mon Date 27 5 B
Sat Date 28 3 K Tue Date 28 5 C Tue Date 28 5 C
Sun Date 29 0 L Wed Date 29 5 D
Mon Date 30 5 B Thu Date 30 5 E
Tue Date 31 5 C Fri Date 31 5 F

Typical Scheduling for the Tower of Hanoi Backup Strategy
Day Date L T Day Date L T

e a e a
Tower of Hanoi Backup
v p v p
el e e e The Tower of Hanoi backup strategy is a
variation of exponential backup. Both
l
strategies rely on mathematical functions of
powers of 2. For example, the use of five
backup tapes provides for a 32-day
Sun Date 1 0 E Wed Date 1 5 A schedule. The use of 6 tapes would provide
Mon Date 2 5 A Thu Date 2 0 E for a 64-day schedule.
Tue Date 3 4 B Fri Date 3 5 A The Tower of Hanoi backup schedule
Wed Date 4 5 A Sat Date 4 4 B provides outstanding data survivability and
Thu Date 5 3 C Sun Date 5 5 A a minimum of media. Unfortunately, on a 7-
Fri Date 6 5 A Mon Date 6 3 C day backup system, the scheduling of full
backups as opposed to partial backups can
Sat Date 7 4 B Tue Date 7 5 A
become a problem for the operator.
Sun Date 8 5 A Wed Date 8 4 B
Mon Date 9 1 D Thu Date 9 5 A One way to avoid operator confusion is to
perform a special level 0 backup on the first
Tue Date 10 5 A Fri Date 10 1 D
day of each month. This tape would not be
Wed Date 11 4 B Sat Date 11 5 A one of the five tapes used in the backup
Thu Date 12 5 A Sun Date 12 4 B cycle. Total media requirements in this
Fri Date 13 3 C Mon Date 13 5 A scheme would be seven sets of media.
Sat Date 14 5 A Tue Date 14 3 C To recover from complete data loss, first
Sun Date 15 4 B Wed Date 15 5 A restore from the most recent level 0
Mon Date 16 5 A Thu Date 16 4 B backup, and then restore from the level 1
Tue Date 17 0 E Fri Date 17 5 A backup if that backup was written after the
level 0 backup. Next, restore consecutively
Wed Date 18 5 A Sat Date 18 0 E from the most recent level 3 and 4 backups
Thu Date 19 4 B Sun Date 19 5 A if both were written after the level 0 backup.
Fri Date 20 5 A Mon Date 20 4 B Finally, restore each of the level 5 backups
Sat Date 21 3 C Tue Date 21 5 A that were written after the level 0 backup.
Sun Date 22 5 A Wed Date 22 3 C Finally, restore each of the level 5 backups
that were written after the level 0 backup.
Mon Date 23 4 B Thu Date 23 5 A
Tue Date 24 5 A Fri Date 24 4 B
Wed Date 25 1 D Sat Date 25 5 A
Thu Date 26 5 A Sun Date 26 1 D
Fri Date 27 4 B Mon Date 27 5 A
Sat Date 28 5 A Tue Date 28 4 B
Sun Date 29 3 C
Mon Date 30 5 A
Tue Date 31 4 B

Typical Scheduling for a reasonable backup strategy

Day Date L T
This table offers a reasonable backup schedule for most sites. Performing a full
e a
dump of the first Sunday of the month provides a monthly snapshot of the system
v p
data. Using two sets of dump media allows the operator to store information for
e e
two full months.
l
Note that in the example the Tuesday through Friday incremental backups contain
Sun Date 1 extra copies of files from Monday. This schedule ensures that any file modified
Mon Date 2 0 A during the week can be recovered from the previous days incremental dump.
Tue Date 3 5 B To recover from complete data loss, restore the most recent full (level 0) backup
Wed Date 4 5 C tape. Next, restore from the most recent of the weekly (level 3) backups. Once the
Thu Date 5 5 D weekly backups are restored, restore from each of the daily (level 5) backups.
Fri Date 6 3 E
Sat Date 7 8.3. Types of Backup Devices
Sun Date 8 Once a backup strategy has been chosen, it is time to devote some attention to
Mon Date 9 5 F backup devices. Principal backup device requirements follow:
Tue Date 10 5 B
User ability to write data to the device
Wed Date 11 5 C
Media capable of storing the data for long periods
Thu Date 12 5 D
Supports standard system interconnects
Fri Date 13 3 E
Supports reasonable I/O throughput
Sat Date 14
Sun Date 15 Most devices used for system backups consist of magnetic media (tape or disk)
and the drive mechanism. The drive mechanism provides the electronics and
Mon Date 16 5 F
transport functions to allow the device to store digital signals on the magnetic
Tue Date 17 5 B media. Lets take a look at few of the backup devices.
Wed Date 18 5 D
Thu Date 19 5 D Tape Backup Devices:
Fri Date 20 3 E Tape backup devices are probably the most common backup media in use. The
Sat Date 21 media is relatively inexpensive, the performance is reasonable, the data formats
Sun Date 22 are standardized, and tape drives are easy to use. These factors combined make
Mon Date 23 5 F magnetic tape backups an attractive option. One complication of tape backups is
deciding which type of tape system to use. Several of the more popular options
Tue Date 24 5 B
are explored in the following sections.
Wed Date 25 5 D
Thu Date 26 5 D -inch 9-Track Tape Drive
Fri Date 27 3 E Half-inch tape drives were once the mainstay of backup media. The early -inch
Sat Date 28 tape drives allowed the operator to write information on the tape at 800 bits per
Sun Date 29 inch of tape. Later drives allowed 1600 bits per inch, and the most recent drives
allow 6250 bits per inch. At 6250 bits per inch, a inch tape can hold up to 100
Mon Date 30 5 F Mb of information.
Tue Date 31 5 B
A typical 1/2 inch tape consists of 2400 feet of -inch-wide tape on a 10-inch
plastic reel. The -inch tape drives are typically large and expensive, but the tape itself is relatively inexpensive.
The -inch format is still a standard media for many industrial operations.
Older -inch tape drives required special bus interfaces to connect them to a system, whereas the SCSI interface
is common today. Due to the vast quantity of information stored on -inch tape, the -inch tape drive will be
required for many years to come simply to access the stored information. However, with systems containing
literally hundreds of gigabytes of disk storage, -inch tape becomes impractical for data backup.
Cartridge Tape Drive
Cartridge tape drives store between 10 Mb and several GB of data on a small tape cartridge. Cartridge tape
drives are usually smaller and less expensive than -inch tape drives. Tape cartridges are typically more
expensive than a reel of -inch tape. Because the data cartridge stores more information, a cartridge tape must
be manufactured to tighter tolerances than -inch tapes.
Because the media is smaller and the drives less expensive, cartridge tape systems have become standard
distribution media for many software companies. Moreover, cartridge tapes are particularly attractive for disaster
recovery situations because many systems still include boot PROM code to boot cartridge distribution tapes.

A cartridge tape distribution of the OS is easily stored in a remote location. In the event of a failure or disaster at
the primary computer location, these distribution tapes could be used to rebuild a system to replace the damaged
host.
Most cartridge tape systems use SCSI interconnections to the host system. These devices support data transfer
rate up to 5 Mb per second. This transfer rate may be a little misleading, however, as the information is typically
buffered in memory of the tape drive. 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 40 GB of data. Because of high-density storage, 8-mm drives have become a standard backup
device on many systems. Several companies also use 8-mm tape as distribution media for software.
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. These units transfer data to the tape at a rate of 250 Kb per second. High-density 8-mm
drives can store between 5 and 40 GB of information on tape.
At the low end, the 8-mm drives dont use data compression techniques to store the information on tape. At the
high end, the drives incorporate data compression hardware used to increase the amount of information that can
be stored on the tape. Regardless of the use of data compression, high-density 8-mm drives transfer data to tape
at a rate of 500 Kb per second. High-density drives also allow the user to read and write data at the lower
densities supported by the low-density drives. When using the high-density drives in low-density mode, storage
capacities and throughput numbers are identical to low-density drives.
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. The DAT media is a relative newcomer to the digital data backup market. The
tape drive electronics and media are basically the same as the DAT tapes used in home audio systems.
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, manufacturers have produced drives that can
store between 2 and 40 GB of data on tape. DAT drives use SCSI bus interconnections to the host system.
Because DAT technology is relatively new, it offers performance and features not available with other tape system
technologies. For instance, the DAT drive offers superior file search capabilities as compared to the 8-mm helical
scan drives on the market.
Digital Linear Tape (DLT)
Digital linear tape backup devices are among the newest devices 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 70 GB of data on a single tape cartridge. Transfer rates of 5 Mb/second are possible on
high-end DLT drives, making them very attractive at sites with large on-line storage systems.
Where 8-mm and DAT tape cost (roughly) $15 per tape, the DLT tapes can run as much as $60 each. However,
when the tape capacity is factored into the equation, the costs of DLT tapes become much more reasonable.
(Consider an 8-mm tape that holds 14 GB on average versus a DLT cartridge, which can hold 70 Gb of data.)
Many operators elect not to enable the compression hardware on tape systems, opting instead for software
compression before the data are sent to the tape drive. In the event of a hardware failure in the tape drives
compression circuitry, it is possible that the data written to tape would be scrambled. By using the software
compression techniques, the operator can bypass such potential problems.
Jukebox System
Jukebox systems combine a jukebox mechanism with one or more tape drives to provide a tape system capable
of storing several hundred Gb of data. The tape drives in the 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. Many commercially
available backup software packages allow the use of jukebox systems to permit backup automation.
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 backup up several gigabytes or terabytes of data daily it would not take long to realize that tape drives are
not the best backup method.
One popular method of backing up large-scale systems is to make backup copies of the data on several disk
drives. Disk drives are orders of magnitude faster than tape devices, and therefore offer a solution to one of the
backup problems on large-scale systems. However, disk drives are much more expensive than tapes. Disk
backups also consume large amounts of system resources. For example, you would need 100 2-Gb disks to back
up a hundred 2-Gb disks. Fortunately, there are software applications and hardware systems available to
transparently perform this function.
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 re-create the data from the failed drive.
Problems with Disks as Backup Devices
Although backing up to disk devices is much faster than backing up to other devices, it should be noted that disk
devices present a potentially serious problem. One of the important considerations of backup planning is the
availability of the data to users. In the event of a natural disaster, it may be necessary to keep a copy of the
corporate data off-site.
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 another disk. However, both disks are housed in a single box. This makes
the task of moving one drive off-site much more complicated.
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.
In applications and businesses where data accessibility is of the utmost importance, the use of RAID disk arrays
and fiber channel interconnections could solve most of the problems.
Differences between Different types of Backups

Using Dump Levels to Create Incremental Backups

The dump level you specify in the ufsdump command (09) determines which files are backed up. Dump level 0
creates a full backup. Levels 19 are used to schedule incremental backups, but have no defined meanings.
Levels 19 are just a range of numbers that are used to schedule cumulative or discrete backups. The only
meaning levels 19 have is in relationship to each other, as a higher or lower number. A lower dump number
always restarts a full or a cumulative backup. The following examples show the flexibility of the incremental dump
procedure using levels 19.
Dump Levels for Daily, Incremental Backups
Daily Cumulative, Weekly Cumulative Backup Schedule and Tape Contents
Daily Cumulative, Weekly Incremental Backup Schedule and Tape Contents
Daily Incremental, Weekly Cumulative Backup Schedule and Tape Contents

8.4. Commands for Copying File Systems

When you need to back up and restore complete file systems, use the ufsdump and ufsrestore commands. When
you want to copy or move individual files, portions of file systems, or complete file systems, you can use the
procedures described in this chapter instead of the ufsdump and ufsrestore commands. The following table
describes when to use the various backup commands.
Differences between the various backup commands

Frequently used commands for copying File Systems
Making a Literal File System Copy

The dd command makes a literal (block-level) copy of a complete UFS file system to another file system or to a
tape. By default, the dd command copies standard input to standard output.
Note Do not use the dd command with variable-length tape drives without first specifying an appropriate block
size.
You can specify a device name in place of standard input or standard output, or both. In this example, the
contents of the diskette are copied to a file in the /tmp directory:
$ dd < /floppy/floppy0 > /tmp/output.file
2400+0 records in
2400+0 records out
The dd command reports on the number of blocks it reads and writes. The number after the + is a count of the
partial blocks that were copied. The default block size is 512 bytes. The dd command syntax is different from
most other commands. Options are specified as keyword=value pairs, where keyword is the option you want to
set and value is the argument for that option. For example, you can replace standard input and standard output
with this syntax:
$ dd if=input-file of=output-file

To use the keyword=value pairs instead of the redirect symbols, you would type the following:
$ dd if=/floppy/floppy0 of=/tmp/output.file
How to Copy a Disk (dd)

Keep the following key points in mind when you consider copying a disk:
1. Do not use this procedure to copy a disk that is under the control of a volume manager.
2. The primary methods for copying UFS file system data from one disk or system to another disk or system
is by using the ufsdump and ufsrestore commands.
3. You can clone systems by creating a flash archive and copying it to destination systems.
4. If you are still considering copying a disk with the dd command keep the following cautions in mind:
5. Make sure that the source disk and destination disk have the same disk geometry.
6. Check the UFS file systems on the disk to be copied with the fsck utility.
7. Make sure the system is in single-user mode when copying a disk with the dd command.
Copying Files and File Systems to Tape

You can use the tar, pax, and cpio commands to copy files and file systems to tape. The command that you
choose depends on how much flexibility and precision you require for the copy. Because all three commands use
the raw device, you do not need to format or make a file system on tapes before you use them. The tape drive
and device name that you use depend on the hardware configuration for each system.
Copying Files to Tape (tar Command)
Here is information that you should know before you copy files to tape with the tar command:
Copying files to a tape with the -c option to the tar command destroys any files already on the tape at or
beyond the current tape position.
You can use file name substitution wildcards (? and *) as part of the file names that you specify when
copying files. For example, to copy all documents with a .doc suffix, type *.doc as the file name
argument.
You cannot use file name substitution wildcards when you extract files from a tar archive.
Copying Files to a Tape With the pax Command

How to Copy Files to a Tape (pax)
1. Change to the directory that contains the files you want to copy.
2. Insert a write-enabled tape into the tape drive.
3. Copy the files to tape.
$ pax -w -f /dev/rmt/n filenames
-w Enables the write mode.
-f /dev/rmt/n Identifies the tape drive.
filenames Indicates the files and directories that you want to copy.
Separate multiple files with spaces.
4. Verify that the files have been copied to tape.
$ pax -f /dev/rmt/n
5. Remove the tape from the drive. Write the names of the files on the tape label.
Copying Files to Tape With the cpio Command

How to Copy All Files in a Directory to a Tape (cpio)
1. Change to the directory that contains the files you want to copy.
2. Insert a write-enabled tape into the tape drive.
3. Copy the files to tape.
$ ls | cpio -oc > /dev/rmt/n

ls Provides the cpio command with a list of file names.

cpio -oc Specifies that the cpio command should operate in copy-out mode (-o) and write header
information in ASCII character format (-c). These options ensure portability to other vendors systems.
> /dev/rmt/n Specifies the output file.
All files in the directory are copied to the tape in the drive you specify, overwriting any existing files on the
tape. The total number of blocks that are copied is shown.
4. Verify that the files have been copied to tape.
$ cpio -civt < /dev/rmt/n
-c Specifies that the cpio command should read files in ASCII character format.
-i Specifies that the cpio command should operate in copy-in mode, even though the command is
only listing files at this point.
-v Displays the output in a format that is similar to the output from the ls -l command.
-t Lists the table of contents for the files on the tape in the tape drive that you specify.
< /dev/rmt/n Specifies the input file of an existing cpio archive.
How to Retrieve All Files from a Tape (cpio)

If the archive was created using relative path names, the input files are built as a directory within the current
directory when you retrieve the files. If, however, the archive was created with absolute path names, the same
absolute paths are used to re-create the file on your system.
1. Change to the directory where you want to put the files.
2. Insert the tape into the tape drive.
3. Extract all files from the tape.
$ cpio -icvd < /dev/rmt/n
-i Extracts files from standard input.
-c Specifies that the cpio command should read files in ASCII character format.
-v Displays the files as they are retrieved in a format that is similar to the output from the ls command.
-d Creates directories as needed.
< /dev/rmt/n Specifies the output file.
4. Verify that the files were copied.
$ ls -l
Retrieving All Files from a Tape (cpio)

The following example shows how to retrieve all files from the tape in drive 0.
$ cd /var/tmp
cpio -icvd < /dev/rmt/0
answers
sc.directives
tests
8 blocks
$ ls -l
How to Retrieve Specific Files From a Tape (cpio)

3. Retrieve a subset of files from the tape.
$ cpio -icv "*file" < /dev/rmt/n
-i Extracts files from standard input.

-c Specifies that the cpio command should read headers in ASCII character format.
-v Displays the files as they are retrieved in a format that is similar to the output from the ls command.
"*file" Specifies that all files that match the pattern are copied to the current directory. You can specify multiple
patterns, but each pattern must be enclosed in double quotation marks.
< /dev/rmt/n Specifies the input file.
Verify that the files were copied.
$ ls -l
Retrieving Specific Files from a Tape (cpio)
The following example shows how to retrieve all files with the chapter suffix from the tape in drive 0.
$ cd /home/smith/Book
$ cpio -icv "*chapter" < /dev/rmt/0
Boot.chapter
Directory.chapter
Install.chapter
Intro.chapter
31 blocks
$ ls -l
Copying Files to a Remote Tape Device

How to Copy Files to a Remote Tape Device (tar and dd)
1. The following prerequisites must be met to use a remote tape drive:
a. The local host name and optionally, the user name of the user doing the copy, must
appear in the remote systems /etc/hosts.equiv file. Or, the user doing the copy
must have his or her home directory accessible on the remote machine, and have the
local machine name in $HOME/.rhosts.
b. An entry for the remote system must be in the local systems /etc/inet/hosts file
or in the name service hosts file.
2. To test whether you have the appropriate permission to execute a remote command, try the following:
$ rsh remotehost echo test
If test is echoed back to you, you have permission to execute remote commands. If Permission denied is
echoed back to you, check your setup as described in Step 1.
5. Copy the files to a remote tape drive.
$ tar cvf - filenames | rsh remote-host dd of=/dev/rmt/n obs=block-size
tar cf Creates a tape archive, lists the files as they are archived, and specifies the tape device.
v Provides additional information about the tar file entries.
- (Hyphen) Represents a placeholder for the tape device.
filenames Identifies the files to be copied. Separate multiple files with spaces.
rsh | remote-host Pipes the tar commands output to a remote shell.
dd of= /dev/rmt/n Represents the output device.
obs=block-size Represents the blocking factor.
6. Remove the tape from the drive. Write the names of the files on the tape label.
Copying Files to a Remote Tape Drive (tar and dd)

# tar cvf - * | rsh mercury dd of=/dev/rmt/0 obs=126b

a answers/ 0 tape blocks

a answers/test129 1 tape blocks
a sc.directives/ 0 tape blocks
a sc.directives/sc.190089 1 tape blocks
a tests/ 0 tape blocks
a tests/test131 1 tape blocks
6+9 records in
0+1 records out
How to Extract Files from a Remote Tape Device
2. Change to a temporary directory.
$ cd /var/tmp
3. Extract the files from a remote tape device.
$ rsh remote-host dd if=/dev/rmt/n | tar xvBpf -
rsh remote-host Indicates a remote shell that is started to extract the files from the tape device by using
the dd command.
dd if=/dev/rmt/n Indicates the input device.
| tar xvBpf - Pipes the output of the dd command to the tar command, which is used to restore
the files.
4. Verify that the files have been extracted.
$ ls -l
Extracting Files from a Remote Tape Drive
$ cd /var/tmp
$ rsh mercury dd if=/dev/rmt/0 | tar xvBpf -
x answers/, 0 bytes, 0 tape blocks
x answers/test129, 48 bytes, 1 tape blocks
20+0 records in
20+0 records out
x sc.directives/, 0 bytes, 0 tape blocks
x sc.directives/sc.190089, 77 bytes, 1 tape blocks
x tests/, 0 bytes, 0 tape blocks
x tests/test131, 84 bytes, 1 tape blocks
$ ls -l
8.5. Backup Device Names

You specify a tape or diskette to use for backup by supplying a logical device name. This name points to the
subdirectory that contains the raw device file and includes the logical unit number of the drive. Tape drive
naming conventions use a logical, not a physical, device name. In general, you specify a tape device as shown in
the following figure.

If you dont specify the density, a tape drive typically writes at its preferred density. The preferred density usually
means the highest density the tape drive supports. Most SCSI drives can automatically detect the density or
format on the tape and read it accordingly. To determine the different densities that are supported for a drive, look
at the /dev/rmt subdirectory. This subdirectory includes the set of tape device files that support different output
densities for each tape. Also, a SCSI controller can have a maximum of seven SCSI tape drives.
Specifying the Rewind Option for a Tape Drive

Normally, you specify a tape drive by its logical unit number, which can run from 0 to n. The following table
describes how to specify tape device names with a rewind or a no-rewind option.
Specifying Different Densities for a Tape Drive

By default, the drive writes at its preferred density, which is usually the highest density the tape drive supports. If
you do not specify a tape device, the command writes to drive number 0 at the default density the device
supports. To transport a tape to a system whose tape drive supports only a certain density, specify a device name
that writes at the desired density. The following table describes how to specify different densities for a tape drive.
Displaying Tape Drive Status

You can use the status option with the mt command to get status information about tape drives. The mt
command reports information about any tape drives that are described in the /kernel/drv/st.conf file.
How to Display Tape Drive Status
1. Load a tape into the drive you want information about.
2. Display the tape drive status.
# mt -f /dev/rmt/n status
3. Repeat steps 12, substituting tape drive numbers 0, 1, 2, 3, and so on to display information about all
available tape drives.
The following example shows the status for a QIC-150 tape drive (/dev/rmt/0):
$ mt -f /dev/rmt/0 status
Archive QIC-150 tape drive:
sense key(0x0)= No Additional Sense residual= 0 retries= 0
file no= 0 block no= 0

The following example shows the status for an Exabyte tape drive (/dev/rmt/1):
$ mt -f /dev/rmt/1 status
Exabyte EXB-8200 8mm tape drive:
sense key(0x0)= NO Additional Sense residual= 0 retries= 0
The following example shows a quick way to poll a system and locate all of its tape drives:
$ for drive in 0 1 2 3 4 5 6 7
> do
> mt -f /dev/rmt/$drive status
> done
Archive QIC-150 tape drive:
sense key(0x0)= No Additional Sense residual= 0 retries= 0
/dev/rmt/1: No such file or directory
$
Handling Magnetic Tape Cartridges
If errors occur when a tape is being read, you can retension the tape, clean the tape drive, and then try again.
Retensioning a Magnetic Tape Cartridge

Retension a magnetic tape cartridge with the mt command. For example:
$ mt -f /dev/rmt/1 retension
$
Rewinding a Magnetic Tape Cartridge
To rewind a magnetic tape cartridge, use the mt command. For example:
$ mt -f /dev/rmt/1 rewind
$
Guidelines for Drive Maintenance and Media Handling

A backup tape that cannot be read is useless. So, periodically clean and check your tape drives to ensure correct
operation. See your hardware manuals for instructions on procedures for cleaning a tape drive. You can check
your tape hardware by doing either of the following:
1. Copying some files to the tape, reading the files back, and then comparing the original files with the
copied files.
2. Using the -v option of the ufsdump command to verify the contents of the media with the source file
system. The file system must be unmounted or completely idle for the -v option to be effective. Be
aware that hardware can fail in ways that the system does not report. Always label your tapes after a
backup. This label should never change. Every time you do a backup, make another tape label that
contains the following information:
The backup date
The name of the machine and file system that is backed up
The backup level
The tape number (1 of n, if the backup spans multiple volumes)
Any information specific to your site

3. Store your tapes in a dust-free safe location, away from magnetic equipment. Some sites store archived
tapes in fireproof cabinets at remote locations. You should create and maintain a log that tracks which
media (tape volume) stores each job (backup) and the location of each backed-up file.

Chapter 9 Network Basics Page 112 of 198
9. Network Basics
We have seen how to manage peripherals and resources directly connected to local systems. Let us study in
detail about the network and also see how computer networks allow the utilization of resources indirectly
connected to the network.
Overview of the Internet
The Internet consists of many dissimilar network technologies around the world that are interconnected. It
originated in the mid-1970s as the ARPANET. Primarily funded by the Defense Advanced Research Projects
Agency (DARPA), ARPANET pioneered the use of packet-switched networks using Ethernet, and a network
protocol called Transmission Control Protocol/Internet Protocol (TCP/IP). The beauty of TCP/IP is that it hides
network hardware issues from end users, making it appear as though all connected computers are using the
same network hardware.
The Internet currently consists of thousands of interconnected computer networks and millions of host computers.
Connecting to the Internet
If hosts on a network want to communicate, they need an addressing system that identifies the location of each
host on the network. In the case of hosts on the Internet, the governing body that grants Internet addresses is the
Network Information Center (NIC).
Technically, sites that do not want to connect to the Internet need not apply to the NIC for a network address. The
network/system administrator may assign network addresses at will. However, if the site decides to connect to the
Internet at some point in the future, it will need to re-address all hosts to a network address assigned by the NIC.
Although reassigning network addresses is not difficult, it is tedious and time consuming, especially on networks
of more than a few dozen hosts. It is therefore recommended that networked sites apply for an Internet address
as part of the initial system setup.
Beginning in 1995, management of the Internet became a commercial operation. The commercialization of
Internet management led to several changes in the way addresses are assigned. Prior to 1995, sites had to
contact the NIC to obtain an address. The new management determined that sites should contact respective

network service providers (NSPs) to obtain IP addresses. Alternatively, sites may contact the appropriate network
registry.
9.1. TCP/IP
TCP/IP is the networking protocol suite most commonly used with UNIX, MacOS, Windows, Windows NT, and
most other operating systems. It is also the native language of the Internet.
TCP/IP defines a uniform programming interface to different types of network hardware, guaranteeing that
systems can exchange data (interoperate) despite their many differences. IP, the suites underlying delivery
protocol, is the workhorse of the Internet. TCP and UDP (the User Datagram Protocol) are transport protocols that
are built on top of IP to deliver packets to specific applications.
TCP is a connection-oriented protocol that facilitates a conversation between the two programs. It works like a
phone call: the words you speak are delivered to the person you called, and vice versa. The connection persists
even when neither party is speaking. TCP provides reliable delivery, flow-control, and congestion control.
UDP is a packet-oriented service. Its analogous to sending a letter through the post office. It doesnt provide two-
way connections and doesnt have any form of congestion control.
TCP/IP is a protocol suite, a set of network protocols designed to work smoothly together. It includes several
components:
Internet Protocol (IP) --- this routes data packets from one machine to another.
Internet Control Message Protocol (ICMP) --- this provides several kinds of low-level support for IP,
including error messages, routing assistance, and debugging help.
Address Resolution Protocol (ARP) --- this translates IP addresses to hardware addresses
User Datagram Protocol (UDP) --- this delivers data to specific applications on the destination machine.
UNIX can support a variety of physical networks, including Ethernet, FDDI, token ring, ATM (Asynchronous
Transfer Mode), wireless Ethernet and serial-line-based systems.
Internet Protocol
The process of connecting two computer networks is called inter-networking. The network may or may not be
using the same network technology, such as Ethernet or token ring. For an internetwork connection to function, a
transfer device that forwards datagrams from one network to another is required. This transfer device is called a
router or, in some cases, a gateway.
In order for internetworked computers to communicate, they must speak the same language. The language
supported by most computers is the Transmission Control Protocol/Internet Protocol (TCP/IP). The TCP/IP
protocols are actually a collection of many protocols. This suite of protocols defines every aspect of network
communications, including the language spoken by the systems, the way the systems address each other, how
data are routed through the network, and how the data will be delivered. The Internet is currently using version 4
of the Internet protocol (IPv4).
Network Addresses
For internetworked computers to communicate there must be some way to uniquely identify the address of the
computer where data are to be delivered. This identification scheme must be much like postal mail address. It
should provide enough information so that the systems can send information long distances through the network,

yet have assurance that it will be delivered to the desired destination. As with postal addresses, there must be
some sanctioned authority to assign addresses and administer the network.
The TCP/IP protocol defines one portion of the addressing scheme used in most computer networks. The Internet
protocol defines the Internet protocol address (also known as an IP address, or Internet address) scheme. The IP
address is a unique number assigned to each host on the network.
The vendors of network hardware also provide a portion of the addressing information used on the network. Each
network technology defines a hardware (media) layer addressing scheme unique to that network technology.
These hardware-level addresses are referred to as media access controller (MAC) addresses.
Internet Protocol Addresses
Hosts connected to the Internet have a unique Internet Protocol (IP) address. IP addresses consist of 32-bit
hexadecimal number, but they are typically represented as a set of four integers separated by periods. An
example of an Internet address is 192.168.3.1. Each integer in the address must be in the range from 0 to 255.
There are five classes of Internet addresses: Class A, Class B, Class C, Class D, Class E. Class A, B, and C
addresses are used for host addressing. Class D addresses are called multi-cast addresses, and Class E
addresses are experimental addresses.
Class A Addresses
If the number in the first field of a hosts IP address is in the range 1 to 127, the host is on a Class A network.
There are 127 Class A networks. Each Class A network can have up to 16 million hosts. With Class A networks,
the number in the first field identifies the network number, and the remaining three fields identify the host address
on that network.
NOTE: 127.0.0.1 is a reserve IP address called the loopback address. All hosts on the Internet use this address
for their own internal network testing and interprocess communications. Dont make address assignments of the
form 127.x.x.x; nor should you remove the loopback address unless instructed otherwise.
Class B addresses
If the integer in the first field of a hosts IP address is in the range 128 to 191, the host is on a Class B network.
There are 16,384 Class B networks with upto 65,000 hosts each. With Class B networks, the integers in the first
two fields identify the network number, and the remaining two fields identify the host address on that network. An
internet protocol address space is shown:
st
Class 1 Byte Format # Nets # Hosts per net
Class A 0-127 N.H.H.H 127 15,777,214
Class B 128-191 N.N.H.H 64 65,534
Class C 192-223 N.N.N.H 32 254
*** Network Portion denoted by N and host portion denoted by H

Class C Addresses
If the integer in the first field of a hosts IP address is in the range 192 to 223, the host is on a Class C network.
There are 2,097,152 Class C networks with up to 254 hosts each. With Class C networks, the integers in the first
three fields identify the network address, and the remaining field identifies the host address on that network.
NOTE: The numbers 0 and 255 are reserved for special use in an IP address. The number 0 refers to this
network. Number 255, the broadcast address, refers to all hosts on a network. For example, the address
192.168.0.0. refers to the class C network 192.168. The address 192.168.255.255 is the broadcast address for
the 192.168.0.0 network and refers to all hosts on the network.
Public versus Private IP Addresses
There are some address ranges that could be used by sites that dont connect to the Internet, or by sites that
employed a firewall to isolate themselves from the Internet.

Private IP Address Ranges

Class Starting Ending Address CIDR Notation
Address
A 10.0.0.0 10.255.255.255 10.0.0.0/8

B 172.16.0.0 172.31.255.255 172.16.0.0./12
C 192.168.0.0 192.168.255.255 192.168.0.0/16
Address Translation
Address translation is a technique that allows a router to transfer private addresses into public addresses. This
allows sites to assign private addresses internally, yet communicate with other hosts on the Internet using an
assigned public IP address.
Some typical applications where address translation is required include connections to cable-modems, DSL, and
other high-speed Internet Service Provider networks. The ISP assigns a single IP address to a customer that
signs up for cable-modem service. The customer has several computer systems that need to communicate over
the Internet. The customer installs Address Translation Software on their router. When an internal host wants to
communicate with an external host, the translation software goes to work.
The translation software traps the outbound packet, and records the destination IP address and service
requested in a memory-resident table. It then changes the packets source address to the address of the local
router and sends the packet out on the network. When the remote host replies, the packet is sent to the local
router.
The address translation software intercepts the reply packet, determines where it came from, and looks this
address up in the memory-resident table. When it finds a match, the software determines which internal host was
communicating with this external host, and modifies the packet destination address accordingly. The packet is
sent along to the internal host using the private address assigned to that host.
Media Access Controller (MAC) Addresses
In addition to IP addresses assigned by the NIC, most networks also employ another form of addressing known
as the hardware or media access controller (MAC) address. Each network interface board is assigned a unique
MAC address by the manufacturer. In the case of Ethernet interface boards, the MAC address is a 48-bit value.
The address is typically written as a series of six 2-byte hexadecimal values separated by colons.
Each network interface manufacturer is assigned a range of addresses it may assign to interface cards. For
example, 08:00:20:3f:oi:ee might be the address of a Sun Microsystems Ethernet interface. This address would
become a permanent part of the hardware for a workstation manufactured by the Sun Microsystems. (In a MAC
address, the first 3 bytes are IEEE assigned values and the next 3 bytes are vendor specific values).
Ethernet interfaces know nothing of IP addresses. The IP address is used by a higher level of the
communications software. Instead, when two computers connected to an Ethernet communicate, they do so via
MAC addresses. Data transport over the network media is handled by one systems network hardware. If the
datagram is bound for a foreign network it is sent to the MAC address of the router, which will handle forwarding
to the remote network.
Before the datagram is sent to the network interface for delivery, the communications software embeds the IP
address within the datagram. The routers along the path to the final destination use the IP address to determine
the next hop along the path to the final destination. When the datagram arrives at the destination, the
communications software extracts the IP address to determine what to do with the data.
Internet Protocol Version 6 (IPv6)
IPv4 is running out of address space as a result of the enormous expansion of the Internet in recent years. In
order to ensure that address space is available in the future, the Internet Engineering Task Force is readying IPv6
for deployment. Beginning with Solaris 8, the Solaris OE supports IPv6, and Dual-stack (IPv4/IPv6) protocols.
Major differences between IPv4 and IPv6 follow:

IPv6 addresses are 128 bits long (as opposed to the IPv4 32-bit addresses). A typical IPv6 address consists of a
series of colon-separated hexadecimal digits. For example, 0xFEDC:BA98:7654:3210:0123:4567:89AB: CDEF
might be a valid IPv6 host address. Provisions have been made to allow IPv4 addresses on an IPv6 network.
These addresses will have hexadecimal numbers separated by colons, followed by decimal numbers separated
by periods. Such an address might look like the following:
0000:0000:0000:0000:0000: FFFF: 192.168.33.44
IPv6 implements multicasting to replace the IPv4 broadcast-address scheme. The IPv6 multicast scheme allows
for several types of broadcast addresses (organizational, Internet-wide, domain-wide, and so forth).
IPv6 doesnt contain address classes. Some IPv6 address ranges will be reserved for specific services, but
otherwise the idea of address classes will vanish.
IPv6 uses classless Internet domain routing (CIDR) algorithms. This new routing algorithm allows for more
efficient router operation in large network environments. Addresses will be assigned regionally to minimize routing
tables, and to simplify packet routing. IPv6 can encrypt data on the transport media. IPv4 has no facility that
allows network data to be encrypted.
Ports
IP addresses identify machines, or more precisely, network interfaces on a machine. They are not specific
enough to address particular processes or services. TCP and UDP extend IP addresses with a concept known as
a port. A port is a 16-bit number that supplements an IP address to specify a particular communication channel.
Standard UNIX services such as e-mail, FTP, and the remote login server all associate themselves with well-
known ports defined in the /etc/services. (UNIX systems restrict access to port numbers under 1024 to root.)
Address Types
Unicast: addresses that refer to a single host.
Multicast: addresses that identify a group of hosts.
Broadcast: addresses that include all hosts on the local network.
9.2. Network Services

Computers are generally networked to take advantage of the information stored on the networks individual
systems. By networking many systems, each of which manages a small portion of the data, the corporation has
access to all of the data. This is one of the underlying foundations of distributed computing.
For the systems on the network to take advantage of distributed computing, the network must provide network
services. A few of these services might be IP address to MAC address resolution, host-name-to-IP-address
resolution, network file services, and World Wide Web (WWW) services.
Name Services
Computers are very adept at dealing with numbers. In general, people are not capable of remembering so many
numbers associated with computer networking. People prefer to work with alphabetic names. The IP provides a
means of associating a host name with an IP address. The naming of computers makes it simple for humans to
initiate contact with a remote computer simply by referring to the computer by name.
The Name Server:
Unlike humans, computers refer to remote systems by IP addresses. Name services provide mapping between
the hostname humans prefer to use, and the IP addresses computers prefer to use. These name services require
a host (or hosts) connected to the local network to run special name resolution software. These name server
hosts have a database containing mappings between hostnames and IP addresses.
Several name services are available under Solaris. Suns Network Information Service (NIS) and the Domain
Name Service (DNS) are the two name services used most frequently in the Solaris environment. The NIS is
designed to provide local name service within an organization. The DNS name service is designed to provide
Internet-wide name services.
Address Resolution Protocol

Systems connected to an Ethernet prefer to use MAC-level addresses for communications. But how do the hosts
determine the MAC address of other computers on the network once they know the IP address? The address

resolution protocol (ARP) provides a method for hosts to exchange MAC addresses, thereby facilitating
communications.
The ARP software runs on every host on the network. This software examines every packet received by the host
and extracts the MAC address and IP address from each packet. This information is stored in a memory-resident
cache, commonly referred to as the ARP cache.
But if the MAC addresses are not cached then, a host (lets say A) machine sends a broadcast ARP packet to the
network. Every machine on the network receives the broadcast packet and examines its content. The packet
contains a query Does anyone know the MAC address for the host C machine at IP address p.q.r.s?
Every machine on the network (including host C) examines the broadcast ARP packet it just received. If the host
C machine is functioning, it should reply with an ARP reply datagram saying that I am host C, my IP address is
p.q.r.s, and my MAC address is so 8.0.20.0.11.8c. When the machine A receives this datagram, it adds the MAC
address to its ARP cache, and then sends the pending datagram to host C.
Network Design Considerations
Very few system administrators have the opportunity to design a corporate network. This function is typically
managed by a network administrator. Many corporations require the sys-admin to perform both functions for the
company.
However, the sys-admin doesnt know how to design a network, or how to go about managing the network that
gets implemented. The following sections outline some of the topics the network or system administrator must be
concerned with when designing a corporate network.
Computer networks may be classified by many methods, but geographic, technological, and infrastructural
references are three of the most common classifications.
Network geography refers to the physical span of the network. And this dictates the technologies used
when the network is implemented.
Network technology refers to the type of hardware used to implement the network. The network
hardware will dictate the infrastructure required to implement the network.
Network infrastructure refers to the details of the corporate network wiring/interconnection scheme.
Network Geography
Based on physical extent of a network, we have:
LAN (Local Area Network)
MAN (Metropolitan Area Network)
WAN (Wide Area Network)
NOTE: Network throughput measurements are generally listed in terms of bits per second instead of bytes per
second, as is customary with disk subsystems. The difference is attributed to the fact that many network
technologies are serial communications channels, whereas disk subsystems are parallel communications
channels. The abbreviations Kbps, Mbps, and Gbps refer to kilobits per second, megabits per second, and
gigabits per second.
LANS
These are confined to a single building, the underlying cable plant is often owned by the corporation instead of by
a public communications carrier.
MANS
These connect geographically dispersed office within a city or state. And they involve a single communications
carrier, which makes them much simpler to implement than WAN networks.
WANS
These are used to interconnect MANs and LANs. Many corporations use WANs to connect worldwide offices into
a single corporate network.
Differences between different types of networks:
Type Speed Coverage
LAN 4 622 Mbps Single office building or university campus

MAN 9.6 Kbps 45 Mbps Area the size of a city
WAN 56 Kbps 155 Mbps Span vast geographic areas, like continents
Network Technologies:
We have to study the advantages and disadvantages of all the available technologies (because we have a wide
variety of them available) before implementing the physical network.
Ethernet
It is one of the dominant LAN technologies in use today. Ethernet has no pre-arranged order in which hosts
transfer data. Any host can transmit onto the network whenever the network is idle. Ethernet is said to be multiple
access (MA). If two hosts transmit simultaneously, however, a data collision occurs. Both hosts will detect the
collision (CD) and stop transmitting. The hosts will then wait a random period before attempting to transmit again.
It is important to note that Ethernet is a best-effort delivery LAN. In other words, it doesnt perform error-correction
or retransmission of lost data when network errors occur due to events such as collisions. Any datagrams that
result in a collision or arrive at the destination with errors must be retransmitted. On a highly loaded network,
retranmission could result in a bottle-neck. It is best suited for LANs whose traffic patterns are data bursts. NFS
and NIS are examples of network applications that tend to generate bursty network traffic.
Integrated Services Digital Network (ISDN)
ISDN is a multiplexed digital networking scheme for existing telephone facilities (which are mostly analog). The
major advantage of ISDN is that it can be operated over most existing telephone lines.
Digital Subscriber Loop (DSL)
DSL is a relatively new form of long-haul, high-speed networking. DSL is available in many flavors. Each version
of DSL requires special DSL modem. These modems typically have an Ethernet connection on the local side, and
a telephone line interface on the remote side.
Token Ring
Token Ring networks are another widely used local area network technology. A token ring network utilizes a
special data-structure called a token, which circulates around the ring of connected hosts. Unlike the MA access
scheme of Ethernet, a host on a token ring can transmit data only when it possesses the token. Token ring
networks operate in receive and transmit modes.
In transmit mode, the interface breaks the ring open. The host sends its data on the output side of the ring, and
then wait until it receives the information back on its input. Once the system receives information it just tranmitted,
the token is placed back on the ring to allow other systems permission to transmit information, and the ring is
again closed.
In receive mode, a system copies the data from the input side of the ring to the output side of the ring. If the host
is down and unable to forward the information to the next host on the ring, the network is down. For this reason,
many token ring interfaces employ a drop-out mechanism that, when enabled, connects the ring input to the ring
output. This dropout mechanism is disabled by the network driver software when the system is up and running.
However, if the system is not running, the dropout engages and data can get through the interface to the next
system on the ring.
Fiber Distributed Data Interconnect
FDDI is a token ring LAN based on fiber optics. FDDI networks are well suited for LANs whose traffic patterns
include sustained high loads, such as relational database transfers and network tape backups. The FDDI
standards define 2 types of topologies: single attachment stations (SAS) and dual attachment stations (DAS).
Asynchronous Transfer Mode
ATM networks are rapidly becoming a popular networking technology. Because ATM networks are based on
public telephone carrier standards, the technology may be used for LANs, MANs, and WANs.
ATM, like todays telephone network, is a hierarchal standard that employs a connection-oriented protocol. For
two hosts to communicate, one must place a call to the other. When the conversation is over, the connection is
broken. Most ATM networks are implemented over fiber optic media, although recent standards also define
connections over twisted-pair copper cable plants.
Network Ethernet ISDN DSL FDDI ATM

Technology
Speed 100Mbps 128Kbps 45Mbps 100Mbps 1 Gbps
**The maximum speeds which they are supporting is listed.

Network Infrastructures
The infrastructure of a network includes the cable plant required to tie the hosts together, the physical topology of
the wire within the buildings, the type of electronics employed in the network, and the bandwidth requirements of
the hosts connected to the network.
Bandwidth Requirements
(These are generic guidelines; configurations may vary depending on requirements)
A good rule of thumb for network design is to provide a hierarchal network structure. At the top (root) of the
hierarchy is the corporate backbone. Systems connected to this network typically provide corporation-wide
services such as routing, name service, and firewall protection. These services are typically in high demand, and
therefore require the most network bandwidth. Connections at this level of the network should be the fastest
available, typically 100 Mbits/second or faster.
One layer down from the root of the network is the portion of the network that provides connectivity to the other
hosts on the network services. A few examples of the services at this level include network file system servers, e-
mail servers, application servers, and license servers. These services, although still in high demand, are typically
less bandwidth intensive than the top-level network services. Connections at this level are typically moderate
speed connections (100 Mbits/second). At the bottom layer of the network are individual workstations. These
machines typically require the least bandwidth, and therefore get the slowest links to the network, typically 10
Mbits/second.
Network Electronics
The next step in the network design is to determine the type of electronics required to implement the network. For
example, should the low-speed connections be implemented via network hubs, network switches, or routers?
Should the high-speed connections be implemented via FDDI, ATM, or Fast Ethernet? Should hosts be used as
routers, or should dedicated routers be used to handle the routing of network traffic?
Network Implementation Issues
After deciding about the physical implementation of the network the other issues which crop up are:
Determining if the network media is overloaded.
Minimizing media overload conditions.
Decide routes for the packets.
NETMASKS
These provide a method for segmenting large networks into smaller networks. For example, a Class A network
could be segmented into several Class B and Class C networks. The boundaries of each network can be
defined by providing a mask value, which is logically ANDed with the IP address for a host.
Each bit in the netmask with a value of 1 represents a bit of the network address. Netmask bits with zero (0)
values represent bits used for the host address. For example, a netmask of 255.255.255.224 provides for 27 bits
of network address and 5 bits of host address. Such a netmask would provide a network of 30 hosts.
A Class B network number uses 16-bits for the network address, and 16 bits for the host address on the network.
What would happen if a Class B network was treated as a group of Class C networks instead? This would allow
the site to have 254 individual networks instead of a single network. The implications of this segmentation are
summarized in the following:
External routers still route packets to the host listed as the gateway for the Class B network. This means that the
gateway machine will be required to forward all incoming traffic to other hosts on the internal network.
Internal routers will be required to keep track of how to forward packets to internal network segments. This implies
the existence of a name server, and the use of an internal routing protocol within the internal network. This also
suggests that the assignment of IP addresses should be handled geographically such that the routing tables
would be minimized within the network.
Subnets

All IP address classes allow more than 250 hosts to be connected to a network. In the real world, this is a
problem. Ethernet is the dominant network technology in use in private sector and campus networks. Due to the
shared bandwidth design of Ethernet, more hosts on a network means less bandwidth is available to each host.
How can this bandwidth problem be overcome?
One method of partitioning the network traffic is through a process called subnetting the network. Some
organizations place each department on a separate subnet. Others use the geographic location of a host (such as
the floor of an office building) as the subnet boundary. By segmenting the network media into logical entities, the
network traffic is also segmented over many networks, an example of which is shown:

Corporate backbone network

192.168.4.0
192.168.1.0 IP ROUTER 192.168.2.0

nd
1st floor subnet 2 floor subnet
192.168.3.0
rd
3 floor subnet
rd nd
For example, the machines on the 3 floor no longer have to contend with the machines on the 2 floor for a
network access. Because the floor subnets are tied together by a router (or gateway), the machines may still
communicate when required, but otherwise the third floor machines dont see traffic bound for the second floor
machines. But should the sub-nets be incorporated into a network, and how are subnets implemented?
When to Subnet?
There are no absolute formulas for determining when or how to subnet a network. The network topology, the LAN
technology being implemented, network bandwidth, and host applications all affect a networks performance.
However subnetting should be considered if one or more of the following conditions exist.
There are more than 20 hosts on the network.
Network applications slow down as users begin accessing the network.
A high percentage of packets on the network are involved in collisions.
Obtaining accurate network load statistics requires sophisticated (and expensive) network analysis equipment.
However, network load can be estimated by calculating the network interface collision rate on each host. This can
be done using the netstat i n command.
Using the information from the netstat commands output, divide the total collisions by the output packets, and
then multiply the result by 100. To obtain a rough idea of the network collision rate, collect netstat i statistics
for all hosts on the network and average them. Collision rates under 2% are generally considered acceptable.
Rates of 2% to 8% indicate a loaded network. Rates over 8% indicate a heavily loaded network that should be
considered for subnettting.
From a troubleshooting perspective, subnetting allows administrators to isolate (disconnect) pieces (subnets) of a
network when trying to resolve network problems. By isolating a subnet, it is often easier to determine the source
of a network problem. Most routers, gateways, hubs, and multi-port transceivers have a switch allowing them to
operate in standalone mode. If the switch is set to local mode, the subnet is disconnected from the rest of the
network. With the switch set to remote mode, the subnet is connected to the rest of the network.
Routing Concerns
All networks require some form of packet routing to ensure that packets get from one host to another. On a simple
(single wire) network, the routing is also simple: a source host sends a packet out onto the media, and the
destination host picks it up. On a multi-tiered or subnetted network, routing becomes much more difficult. On the
internet, routing can become a nightmare.
Routing Overview
Network routing is an iterative process. Consider the problem a visitor to a large city would have trying to locate
an office in a building in a city that she is unfamiliar with. Generally this problem is broken down into a sequence
of smaller problems, as summarized in the following:
Determine how to get to the destination city.
Determine which quadrant of the city contains the desired street.

Determine where the desired building is located on the street.

Determine where the office is located in the building.
The first 2 steps in this process are roughly equivalent to external routing. The last two steps are roughly
equivalent to internal routing.
In general, an organization should advertise a single routing address. Generally, this address is the network
portion of the IP address registered to the organization. Routers on the Internet search the network potion of the
IP address, and then forward packets toward the destination based on this information. This process is known as
external routing.
Once the packet gets to the corporation, the internal router search the host portion of the address (and any
applicable network mask) to determine how to deliver the packet to its final destination. This portion of the routing
process is known as internal routing.
The following discussion of routing is organized into three areas. First, internal routing refers to the routing
algorithm used within a corporations network. External routing refers to the routing algorithm used to allow the
corporate network hosts to communicate with the outside world (e.g., other hosts on the Internet). Finally
supernets, or classless inter-domain routing (CIDR) blocks are discussed.
External Routing
This allows packets from the outside world to be delivered to the LAN, and vice-versa. Several external routing
protocols are available for use on the Internet.
External routing typically involves determining the next hop along the path to the final destination. A distant router
that wants to deliver a datagram to a host on the LAN doesnt need to know the exact set of gateways required to
get the packet to the final destination. Instead, the external router just needs to know the address of another
router which is one step closer to the final destination.
External routers periodically exchange routing information with their peers. Each router knows the specifics of
packet delivery within their local network. By exchanging information with other routers they build a rouitng table
which contains information about how to get datagrams to other networks. When the routers exchange routing
information they are advertising routes to destinations. In other words, the information exchanged between
routers includes an implied promise that the router knows how to get datagrams delivered to specific destinations.
Internal Routing
One host or router on the LAN must be configured to run one of the external routing protocols. This router/host
will receive all (externally sourced) datagrams bound for hosts on the LAN. The router/host will have to make
internal routing decisions in order to facilitate the delivery of the data to the local destination host. Likewise,
internal network traffic must be routed to destinations on the LAN. Therefore, the router which provides external
routing must also know how to perform internal routing.
Internal routing may be handled in two ways. First, the network manager may tell each host to send all packets to
a central router (or host) for delivery (static routing). Alternatively, the individual hosts may be allowed to
determine how to get packet from point A to point B (dynamic routing). Each routing algorithm has strengths and
weaknesses.
Supernets
The opposite of subnetting is referred to as supernetting. Because the number of available network addresses is
dwindling under IPv4, some entities end up with multiple Class C network numbers when they really need a Class
B network number. The process of supernetting allows the organization to maintain a single gateway to the
outside world by combining the Class C network addresses into single addressable supernetwork. These
supernetworks are also known as classless inter-domain routing (CIDR) blocks.
Assume that an organization with 400 hosts wanted to connect to the Internet, and applied for an IP address. The
Internet service provider may not have a free block of contiguous addresses to assign to the organization. The
ISP could assign two Class C network numbers to the organization, and offer to provide the external routing for
the organization by advertising a single supernet address to the rest of the network.
For example, suppose the organization was assigned the network number 192.168.4.0 and 192.168.5.0.
Expressing these two addresses as binary numbers shows that they share a common 22-bit prefix. The ISP could
advertise a route to the network 192.168.4/22. This tells the rest of the world that the first 22 bits of the address
are used as the network address, with the remaining 10 bits used as the host address.

The external routers know to forward all datagrams bound for hosts on the corporations two networks to the ISPs
router based on this information. The ISPs router forwards the datagrams to the corporate router for final delivery.
An example of supernet routing is shown in the following illustration:
192.168.7.0 = 11000000 10101000 00000111 00000000
192.168.6.0 = 11000000 10101000 00000110 00000000
First 23 bits of both networks are the same
Netmask = 11111111 11111111 11111100 00000000
Advertise = 11000000 10101000 00000110 00000000
192 168 6 /23
Network Monitoring and Troubleshooting

One method of troubleshooting is to use monitoring tools that determine how the network is being used. Another
method is to watch the console error messages generated by the machines connected to the network.
Console Error Messages
Error messages that Solaris sends to the system console may provide a lot of information about the health of the
system and the network.
Simple Network Management Protocol (SNMP)
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.
Network Troubleshooting Commands

snoop Utility
The common uses of snoop are:
Monitoring traffic between two hosts
Monitoring traffic using a particular protocol
Monitoring traffic containing specific data
Monitoring a network to determine which host is creating the most network traffic
ping Utility
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. If there is no reply then, there can be other causes like:
Faulty physical connection.
Faulty host interface
Corrupted /etc/inet/hosts file
Missing or corrupted /etc/hostname.hme0 file
Interface is turned off
Host is down.
Rebooting the non-responsive host solves most of the problems most of the times.
traceroute Utility
This utility traces the route from point A to point B. It is useful when trying to determine why two hosts cannot
communicate. It basically 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.

Chapter 10 Swap, Core & Crash Files Page 124 of 194
10. Swap, Core & Crash Files

10.1. Virtual Memory Concepts
The virtual memory system can be considered the core of a Solaris system and the implementation of Solaris
virtual memory affects just about every other sub-system in the operating system.
The need of Virtual memory
It presents a simple memory programming model to applications so that application developers need not know
how the underlying memory hardware is arranged. It gives us a programming model with a larger memory size
than available physical storage (e.g., RAM) and enables us to use slower but larger secondary storage (e.g., disk)
as a backing store to hold the pieces of memory that dont fit in physical memory.
The VM system transparently manages the virtual storage between RAM and secondary storage. Because RAM
is significantly faster than disk, (100 ns versus 10 ms), the job of the VM system is to keep the most frequently
referenced portions of memory in the faster primary storage. In the event of RAM shortage, the VM system is
required to free RAM by transferring infrequently used memory to the secondary storage. By doing so, the VM
system optimizes performance and removes the need for users to manage the allocation of their own memory.
Physical memory (RAM) is divided into fixed-size pieces called pages. The size of a page can vary across
different platforms. The process of migrating the physical page contents to the backing store is known as a
page-out. Reading back the contents from the backing store i.e. migrating in is called a page-in.
We have more virtual address space than physical address space because the operating system can overflow
memory onto a slower medium, like a disk. The slower medium in UNIX is called swap space. If there is a
shortage of memory, then all of the pages in memory of the least-active process are swapped out to the swap
device, freeing memory for other processes. This is how swapping of memory between primary and secondary
storage helps in optimizing performance.
Swap Space
The Solaris OS uses some disk slices for temporary storage rather than for file systems. These slices are called
swap slices, or swap space. Swap space is used for virtual memory storage areas when the system does not
have enough physical memory to handle current processes. Since many applications rely on swap space, you
should know how to plan for, monitor, and add more swap space, when needed.
Swap Space and Virtual Memory
The virtual memory system maps physical copies of files on disk to virtual addresses in memory. Physical
memory pages that contain the data for these mappings can be backed by regular files in the file system, or by
swap space. If the memory is backed by swap space it is referred to as anonymous memory because no identity
is assigned to the disk space that is backing the memory.
The Solaris OS uses the concept of virtual swap space, a layer between anonymous memory pages and the
physical storage (or disk-backed swap space) that actually back these pages. A systems virtual swap space is
equal to the sum of all its physical (disk-backed) swap space plus a portion of the currently available physical
memory.
Virtual swap space has these advantages:

The need for large amounts of physical swap space is reduced because virtual swap space does not necessarily
correspond to physical (disk) storage.
A pseudo file system called SWAPFS provides addresses for anonymous memory pages. Because SWAPFS
controls the allocation of memory pages, it has greater flexibility in deciding what happens to a page. For
example, SWAPFS might change the pages requirements for disk-backed swap storage.
Swap Space and the TMPFS File System
The TMPFS file system is activated automatically in the Solaris environment by an entry in the /etc/vfstab file.
The TMPFS file system stores files and their associated information in memory (in the /tmp directory) rather than
on disk, which speeds access to those files. This feature results in a major performance enhancement for
applications such as compilers and DBMS products that use /tmp heavily.
The TMPFS file system allocates space in the /tmp directory from the systems swap resources. This feature
means that as you use up space in the /tmp directory, you are also using up swap space. So, if your applications

use the /tmp directory heavily and you do not monitor swap space usage, your system could run out of swap
space.
Do use the following if you want to use TMPFS, but your swap resources are limited:
1. Mount the TMPFS file system with the size option (-o size) to control how much swap resources
TMPFS can use.
2. Use your compilers TMPDIR environment variable to point to another larger directory.
Swap Space as a Dump Device

A dump device is usually disk space that is reserved to store system crash dump information. By default, a
systems dump device is configured to be a swap slice. If possible, you should configure an alternate disk partition
as a dedicated dump device instead to provide increased reliability for crash dumps and faster reboot time after a
system failure. You can configure a dedicated dump device by using the dumpadm command.
10.2. Configuring Swap

How Do I Know If I Need More Swap Space?
Use the swap -l command to determine if your system needs more swap space. When a systems swap space
is at 100% allocation, an applications memory pages become temporarily locked. Application errors might not
occur, but system performance will likely suffer.
Planning for Swap Space
The most important factors in determining swap space size are the requirements of the systems software
applications. For example, large applications such as computer-aided design simulators, database management
products, transaction monitors, and geologic analysis systems can consume as much as 2001000 Mbytes of
swap space. Consult your application vendors for swap space requirements for their applications.
Adding More Swap Space

As system configurations change and new software packages are installed, you might need to add more swap
space. The easiest way to add more swap space is to use the mkfile and swap commands to designate a part of
an existing UFS or NFS file system as a supplementary swap area.
10.3. Core Files and Crash Dumps

10.3.1. Core Files
Core files are generated when a process or application terminates abnormally. Core files are managed with the
coreadm command. When a process terminates abnormally, it produces a core file in the current directory by
default. If the global core file path is enabled, each abnormally terminating process might produce two files, one in
the current working directory, and one in the global core file location. By default, a setuid process does not
produce core files using either the global or per-process path.
Configurable Core File Paths:

Two new configurable core file paths that can be enabled or disabled independently of each other are:
1. A per-process core file path, which defaults to core and is enabled by default. If enabled, the per-process
core file path causes a core file to be produced when the process terminates abnormally. The per-

process path is inherited by a new process from its parent process. When generated, a per-process core
file is owned by the owner of process with read/write permissions for the owner. Only the owning user can
view this file.
2. A global core file path, which defaults to core and is disabled by default. If enabled, an additional
core file with the same content as the per-process core file is produced by using the global core file path.
When generated, a global core file is owned by superuser with read/write permissions for superuser only.
Non-privileged users cannot view this file.
Specify Core File Content with coreadm

The coreadm command lets you specify which parts of a process are present in the core file during a crash. You
can see the systems configuration by running coreadm with no arguments. You can specify the global core file
content and the default per-process core file content by using the -G and -I options respectively. Each option
requires a set of content specifier tokens. You can also set the core file content for individual processes by using
the -P option. Core dumps that correspond to the global settings no longer honor the per-process, core file-size
resource control. The -i and -I options to the coreadm command now apply to all processes whose core file
settings are using the system-wide default. Use the -p and -P options to override the default.
gcore Core File Content
The gcore utility creates core files from a running process without damaging that process. The gcore utility now
supports variable core file content. Use the -c option to specify the content or the -p or -g options to force
gcore to use the coreadm settings.
mdb Supports Text and Symbol Tables in Core Files
Text is now in core files by default. Also, symbol tables can now be in core files by default. The mdb utility has
been updated to support this new core file data. This support means you can now debug your old core file without
needing the original binary or the libraries that are linked to that file.
Displaying the Current Core Dump Configuration
$ coreadm
Setting a Core File Name Pattern
Set a per-process file name pattern.
$ coreadm -p $HOME/corefiles/%f.%p $$
Set a global file name pattern.
# coreadm -g /var/corefiles/%f.%p
Enabling a Per-Process Core File Path
# coreadm -e process
Display the current process core file path to verify the configuration.
$ coreadm $$
1180: /home/kryten/corefiles/%f.%p
Enabling a Global Core File Path
# coreadm -e global -g /var/core/core.%f.%p
Display the current process core file path to verify the configuration.
# coreadm
Examining Core Files

Some of the proc tools have been enhanced to examine process core files as well as live processes. The proc
tools are utilities that can manipulate features of the /proc file system. The /usr/proc/bin/pstack, pmap,
pldd, pflags, and pcred tools can now be applied to core files by specifying the name of the core file on the
command line, similar to the way you specify a process ID to these commands.
$ ./a.out
Segmentation Fault(coredump)

$ /usr/proc/bin/pstack ./core
core ./core of 19305: ./a.out
000108c4 main (1, ffbef5cc, ffbef5d4, 20800, 0, 0) + 1c
00010880 _start (0, 0, 0, 0, 0, 0) + b8
10.3.2. Crash Dumps

System Crashes
System crashes can occur due to hardware malfunctions, I/O problems, and software errors. If the system
crashes, it will display an error message on the console, and then write a copy of its physical memory to the dump
device. The system will then reboot automatically. When the system reboots, the savecore command is
executed to retrieve the data from the dump device and write the saved crash dump to your savecore directory.
The saved crash dump files provide invaluable information to your support provider to aid in diagnosing the
problem.
System Crash Dump Files
The savecore command runs automatically after a system crash to retrieve the crash dump information from the
dump device and writes a pair of files called unix.X and vmcore.X, where X identifies the dump sequence
number. Together, these files represent the saved system crash dump information. Crash dump files are
sometimes confused with core files, which are images of user applications that are written when the application
terminates abnormally. Crash dump files are saved in a predetermined directory, which by default, is
/var/crash/hostname. System crash information is managed with the dumpadm command.
Additionally, crash dumps saved by savecore can be useful to send to a customer service representative for
analysis of why the system is crashing.
The dumpadm Command
Use the dumpadm command to manage system crash dump information in the Solaris Operating System.
1. The dumpadm command enables you to configure crash dumps of the operating system. The dumpadm
configuration parameters include the dump content, dump device, and the directory in which crash dump
files are saved.
2. Dump data is stored in compressed format on the dump device. Kernel crash dump images can be as big
as 4 Gbytes or more. Compressing the data means faster dumping and less disk space needed for the
dump device.
3. Saving crash dump files is run in the background when a dedicated dump device, not the swap area, is
part of the dump configuration. This means a booting system does not wait for the savecore command
to complete before going to the next step. On large memory systems, the system can be available before
savecore completes.
4. System crash dump files, generated by the savecore command, are saved by default.
5. The savecore -L command is a new feature, which enables you to get a crash dump of the live running
Solaris OS. This command is intended for troubleshooting a running system by taking a snapshot of
memory during some bad state, such as a transient performance problem or service outage. If the system
is up and you can still run some commands, you can execute the savecore L command to save a
snapshot of the system to the dump device, and then immediately write out the crash dump files to your
savecore directory. Because the system is still running, you can only use the savecore -L command if
you have configured a dedicated dump device.
How the dumpadm Command Works

During system startup, the dumpadm command is invoked by the svc:/system/dumpadm:default service to
configure crash dumps parameters based on information in the /etc/dumpadm.conf file. Specifically, dumpadm
initializes the dump device and the dump content through the /dev/dump interface. After the dump configuration
is complete, the savecore script looks for the location of the crash dump file directory by parsing the content of
/etc/dumpadm.conf file. Then, savecore is invoked to check for crash dumps and check the content of the
minfree file in the crash dump directory.
Displaying the Current Crash Dump Configuration
# dumpadm

Dump content: kernel pages

Dump device: /dev/dsk/c0t3d0s1 (swap)
Savecore directory: /var/crash/venus
Savecore enabled: yes
The preceding example output means:
The dump content is kernel memory pages.
1. Kernel memory will be dumped on a swap device, /dev/dsk/c0t3d0s1. You can identify all your swap
areas with the swap -l command.
2. System crash dump files will be written in the /var/crash/venus directory.
3. Saving crash dump files is enabled.
Modifying a Crash Dump Configuration

In this example, all of memory is dumped to the dedicated dump device, /dev/dsk/c0t1d0s1, and the
minimum free space that must be available after the crash dump files are saved is 10% of the file system space.
# dumpadm
Dump content: kernel pages
Dump device: /dev/dsk/c0t3d0s1 (swap)
Savecore directory: /var/crash/pluto
# dumpadm -c all -d /dev/dsk/c0t1d0s1 -m 10%
Dump content: all pages
Dump device: /dev/dsk/c0t1d0s1 (dedicated)
Savecore directory: /var/crash/pluto (minfree = 77071KB)
Examining a Crash Dump
The following example shows sample output from the mdb utility, which includes system information and
identifies the tunables that are set in this systems /etc/system file.
# /usr/bin/mdb -k unix.0
Loading modules: [ unix krtld genunix ip nfs ipc ptm ]
> ::status
debugging crash dump /dev/mem (64-bit) from ozlo
operating system: 5.10 Generic (sun4u)
> ::system
set ufs_ninode=0x9c40 [0t40000]
set ncsize=0x4e20 [0t20000]
set pt_cnt=0x400 [0t1024]
Disabling or Enabling Saving Crash Dumps
This example illustrates how to disable the saving of crash dumps on your system.
# dumpadm -n
Savecore enabled: no
Enabling the Saving of Crash Dumps
This example illustrates how to enable the saving of crash dump on your system.
# dumpadm -y


Chapter 11 Network File Systems Page 130 of 198
11. Network File Systems

We studied the different types of filesystems supported by the Solaris OE. In that flow, we studied about the
Network File System (NFS). It was developed by Sun Microsystems in the mid-1980s. It is a standard feature on
most UNIX operating systems, including VMS, MS-DOS/Windows, and Macintosh (MacOS). It is a published
standard that allows file sharing among hosts over a network.
NOTE: In the Solaris 10 release, NFS version 4 is the default. NFS service is managed by the Service
Management Facility.
The objects that can be shared with the NFS service include any whole or partial directory tree or a file
hierarchyincluding a single file. A computer cannot share a file hierarchy that overlaps a file hierarchy that is
already shared. Peripheral devices such as modems and printers cannot be shared. The NFS service has the
following benefits:
Enables multiple computers to use the same files so that everyone on the network can access the same
data
Reduces storage costs by having computers share applications instead of needing local disk space for
each user application
Provides data consistency and reliability because all users can read the same set of files
Makes mounting of file systems transparent to users
Makes accessing of remote files transparent to users
Supports heterogeneous environments
Reduces system administration overhead
11.1. NFS terminology

A host that shares file systems via NFS is called a NFS server. A host that mounts file systems from other hosts is
called a client. A host can be both client and server. Networks on which there are servers and clients are called
client-server networks. Networks where hosts are both client and server to each other are often called peer-to-
peer networks. Most large networks have a mix of clients, servers and peers.
A file system, which is often offered for mounting by a server via NFS, is said to be shared. This term comes from
the share command used to offer file systems for mounting. Similar to other file system types, a remote file
system is mounted on a client using the mount command. The shared portion of the servers file systems can be
mounted in the same location, or in a different location in the UNIX file tree, on the client.
11.2. Remote Procedure Call (RPC)

A key to NFS operation is its use of a protocol called remote procedure call (RPC). The RPC protocol was
developed by Sun Microsystems in the mid-1980s along with NFS. A procedure call is a method by which a
program makes use of a sub-routine. The RPC mechanism extends the procedure call to span the network,
allowing the procedure call to be performed on a remote machine. In NFS, this is used to access files on remote
machines by extending basic file operations such as read and write across the network.
How RPC Works
To understand the purpose of RPC, first consider how the computer system interacts with the files stored on its
local disk. When Solaris program is read into memory from disk, or a file is read or written, system calls are made
to the read or write procedures in the SunOS kernel. As a result, data is read from or written to the file system.
When a file is read from or written to an NFS file system on a network, the read or write calls are made over the
network via RPC. The RPC mechanism performs the read or writes operation needed on the servers file system
on behalf of the client. If the NFS client or server is a different type of host or operating system, such as VMS or a
PC running Windows, the RPC mechanism also handles data conversion.
The result is that the information returned by the read or write call appears to be the same as if the read or write
had occurred on a local disk. Although this appears complex, it all occurs at the filesystem level and requires no
changes to normal operations on files or internal programs. As far as the programs that need to read and write the
files are concerned, NFS is just another file system. The transparent nature of NFS is one of its best features.

NFS FILES
11.3. NFS Commands

automount
This command installs autofs mount points and associates the information in the automaster files with each mount
point. The syntax of the command is as follows:
automount [ -t duration ] [ -v ]
-t duration sets the time, in seconds, that a file system is to remain mounted, and v selects the verbose mode.
Running this command in the verbose mode allows for easier troubleshooting.
clear_locks
This command enables you to remove all file, record, and share locks for an NFS client. You must be root to run
this command. From an NFS server, you can clear the locks for a specific client. From an NFS client, you can
clear locks for that client on a specific server. The following example would clear the locks for the NFS client that
is named tulip on the current system.
# clear_locks tulip
Using the -s option enables you to specify which NFS host to clear the locks from. You must run this option from
the NFS client, which created the locks. In this situation, the locks from the client would be removed from the NFS
server that is named bee.

# clear_locks -s bee
Caution This command should only be run when a client crashes and cannot clear its locks. To avoid data
corruption problems, do not clear locks for an active client.
mount
With this command, you can attach a named file system, either local or remote, to a specified mount point. Used
without arguments, mount displays a list of file systems that are currently mounted on your computer.
mountall
Use this command to mount all file systems or a specific group of file systems that are listed in a file-system table.
The command provides a way of doing the following:
1. Selecting the file-system type to be accessed with the -F FSType option
2. Selecting all the remote file systems that are listed in a file-system table with the r option
3. Selecting all the local file systems with the -l option
setmnt
This command creates an /etc/mnttab table. The mount and umount commands consult the table. Generally,
you do not have to run this command manually, as this command runs automatically when a system is booted.
share
With this command, you can make a local file system on an NFS server available for mounting. You can also use
the share command to display a list of the file systems on your system that are currently shared. The NFS server
must be running for the share command to work. The NFS server software is started automatically during boot if
an entry is in /etc/dfs/dfstab. The command does not report an error if the NFS server software is not
running, so you must verify that the software is running.
shareall
This command allows for multiple file systems to be shared. When used with no options, the command shares all
entries in /etc/dfs/dfstab. You can include a file name to specify the name of a file that lists share command
lines. If you do not include a file name, /etc/dfs/dfstab is checked. If you use a - to replace the file name,
you can type share commands from standard input.
showmount
This command displays one of the following:
All clients that have remotely mounted file systems that are shared from an NFS server
Only the file systems that are mounted by clients
The shared file systems with the client access information
Note The showmount command only shows NFS version 2 and version 3 exports. This command does not
show NFS version 4 exports.
umount
This command enables you to remove a remote file system that is currently mounted. The umount command
supports the -V option to allow for testing. You might also use the -a option to umount several file systems at one
time. If mount_points are included with the -a option, those file systems are unmounted. If no mount points are
included, an attempt is made to unmount all file systems that are listed in /etc/mnttab except for the required
file systems, such as /, /usr, /var, /proc, /dev/fd, and /tmp. Because the file system is already
mounted and should have an entry in /etc/mnttab, you do not need to include a flag for the file-system type.
The -f option forces a busy file system to be unmounted. You can use this option to unhang a client that is hung
while trying to mount an unmountable file system.
Caution By forcing an unmount of a file system; you can cause data loss if files are being written to.
umountall
Use this command to unmount a group of file systems. The -k option runs the fuser -k mount_point
command to kill any processes that are associated with the mount_point. The -s option indicates that unmount is
not to be performed in parallel. -l specifies that only local file systems are to be used, and -r specifies that only

remote file systems are to be used. The -h host option indicates that all file systems from the named host should
be unmounted. You cannot combine the -h option with -l or -r.
unshare
This command allows you to make a previously available file system unavailable for mounting by clients. You can
use the unshare command to unshare any file systemwhether the file system was shared explicitly with the
share command or automatically through /etc/dfs/dfstab. If you use the unshare command to unshare a file
system that you shared through the dfstab file, be careful. Remember that the file system is shared again when
you exit and reenter run level 3. You must remove the entry for this file system from the dfstab file if the change is
to continue. When you unshare an NFS file system, access from clients with existing mounts is inhibited. The file
system might still be mounted on the client, but the files are not accessible.
unshareall
This command makes all currently shared resources unavailable. The -F FSType option selects a list of file-
system types that are defined in /etc/dfs/fstypes. This flag enables you to choose only certain types of file
systems to be unshared. The default file-system type is defined in /etc/dfs/fstypes. To choose specific file
systems, use the unshare command.
11.4. NFS Daemons

To support NFS activities, several daemons are started when a system goes into run level 3 or multiuser mode.
The mountd and nfsd daemons are run on systems that are servers. The automatic startup of the server daemons
depends on the existence of entries that are labeled with the NFS file-system type in /etc/dfs/sharetab. To support
NFS file locking, the lockd and statd daemons are run on NFS clients and servers. However, unlike previous
versions of NFS, in NFS version 4, the daemons lockd, statd, mountd, and nfslogd are not used.
automountd
This daemon handles the mounting and unmounting requests from the autofs service. The syntax of the
command is as follows:
automountd [ -Tnv ] [ -D name=value ]
The command behaves in the following ways:
-T enables tracing.
-n disables browsing on all autofs nodes.
-v selects to log all status messages to the console.
-D name=value substitutes value for the automount map variable that is indicated by name.
The default value for the automount map is /etc/auto_master. Use the -T option for troubleshooting.
lockd
This daemon supports record-locking operations on NFS files. The lockd daemon manages RPC connections
between the client and the server for the Network Lock Manager (NLM) protocol. The daemon is normally started
without any options. You can use three options with this command. See the lockd(1M) man page. These options
can either be used from the command line or by editing the appropriate string in /etc/default/nfs.
mountd
This daemon handles file-system mount requests from remote systems and provides access control. The mountd
daemon checks /etc/dfs/sharetab to determine which file systems are available for remote mounting and which
systems are allowed to do the remote mounting. You can use the -v option and the -r option with this command.
See the mountd (1M) man page.
The -v option runs the command in verbose mode. Every time an NFS server determines the access that a client
should be granted, a message is printed on the console. The information that is generated can be useful when
trying to determine why a client cannot access a file system. The -r option rejects all future mount requests from
clients. This option does not affect clients that already have a file system mounted.
Note NFS version 4 does not use this daemon.
nfs4cbd

nfs4cbd, which is for the exclusive use of the NFS version 4 client, manages the communication endpoints for the
NFS version 4 callback program. The daemon has no user-accessible interface.
nfsd
This daemon handles other client file-system requests. You can use several options with this command. See the
nfsd(1M) man page for a complete listing. These options can either be used from the command line or by editing
the appropriate string in /etc/default/nfs.
The NFSD_LISTEN_BACKLOG=length parameter in /etc/default/nfs sets the length of the connection queue over
connection-oriented transports for NFS and TCP. The default value is 32 entries. The same selection can be
made from the command line by starting nfsd with the -l option.
The NFSD_MAX_CONNECTIONS=#_conn parameter in /etc/default/nfs selects the maximum number of
connections per connection-oriented transport. The default value for #_conn is unlimited. The same parameter
can be used from the command line by starting the daemon with the -c #_conn option.
The NFSD_SERVER=nservers parameter in /etc/default/nfs selects the maximum number of concurrent requests
that a server can handle. The default value for nservers is 16. The same selection can be made from the
command line by starting nfsd with the nservers option. Unlike older versions of this daemon, nfsd does not
spawn multiple copies to handle concurrent requests. Checking the process table with ps only shows one copy of
the daemon running.
nfslogd
This daemon provides operational logging. NFS operations that are logged against a server are based on the
configuration options that are defined in /etc/default/nfslogd. When NFS server logging is enabled, records of all
RPC operations on a selected file system are written to a buffer file by the kernel. Then nfslogd postprocesses
these requests. The name service switch is used to help map UIDs to logins and IP addresses to host names.
The number is recorded if no match can be found through the identified name services. Mapping of file handles to
path names is also handled by nfslogd. The daemon tracks these mappings in a file-handle-to-path mapping
table. One mapping table exists for each tag that is identified in /etc/nfs/nfslogd. After post-processing, the
records are written to ASCII log files.
nfsmapid
In NFS version 4, the nfsmapid(1M) daemon provides a mapping from a numeric user identification (UID) or a
numeric group identification (GID) to a string representation, as well as the reverse. The string representation is
used by the NFS version 4 protocol to represent owner or owner_group. For example, the UID 123456 for the
user, known_user, that is operating on a client that is named system.anydomain.com, would be mapped to
known_user@anydomain.com. The NFS client sends the string representation, known_user@anydomain.com, to
the NFS server. The NFS server maps the string representation, known_user@anydomain.com, to the unique
UID 123456.
Note If the server does not recognize the given user name or group name (even if the domain is correct), the
server cannot map the user or group to its integer ID. More specifically, the server maps unrecognized strings
from the client to nobody. Administrators should avoid making special accounts that exist only on a client.
Although the server and the client do perform both integer-to-string conversions and string-to-integer conversions,
a difference does exist. The server and the client respond differently to unrecognized strings. If the user does not
exist on the server, the server rejects the remote procedure call (RPC). Under these circumstances, the user is
unable to perform any operations on the client or on the server. However, if the user exists on both the client and
the server, but the domain names are mismatched, the server rejects only a subset of the RPC. This behavior
enables the client to perform many operations on both the client and the server, even though the server is
mapping the user to nobody. If the NFS client does not recognize the string, the NFS client maps the string to
nobody.
statd
This daemon works with lockd to provide crash and recovery functions for the lock manager. The statd daemon
tracks the clients that hold locks on an NFS server. If a server crashes, on rebooting statd on the server contacts
statd on the client. The client statd can then attempt to reclaim any locks on the server. The client statd also
informs the server statd when a client has crashed so that the clients locks on the server can be cleared. You
have no options to select with this daemon. For more information, see the statd (1M) man page.

In the Solaris 7 release, the way that statd tracks the clients has been improved. In all earlier Solaris releases,
statd created files in /var/statmon/sm for each client by using the clients unqualified host name. This file naming
caused problems if you had two clients in different domains that shared a host name, or if clients were not
resident in the same domain as the NFS server. Because the unqualified host name only lists the host name,
without any domain or IP-address information, the older version of statd had no way to differentiate between
these types of clients. To fix this problem, the Solaris 7 statd creates a symbolic link in /var/statmon/sm to
the unqualified host name by using the IP address of the client.
11.5. Commands for Troubleshooting NFS Problems

To determine where the NFS service has failed, you need to follow several procedures to isolate the failure.
Check for the following items:
1. Can the client reach the server?
2. Can the client contact the NFS services on the server?
3. Are the NFS services running on the server?
In the process of checking these items, you might notice that other portions of the network are not functioning. For
example, the name service or the physical network hardware might not be functioning. Also, during the process
you might see that the problem is not at the client end. An example is if you get at least one trouble call from
every subnet in your work area. In this situation, you should assume that the problem is the server or the network
hardware near the server. So, you should start the debugging process at the server, not at the client.
nfsstat
You can use this command to gather statistical information about NFS and RPC connections. The syntax of the
command is as follows:
nfsstat [ -cmnrsz ]
-c Displays client-side information
-m Displays statistics for each NFS-mounted file system
-n Specifies that NFS information is to be displayed on both the client side and the server side
-r Displays RPC statistics
-s Displays the server-side information
-z Specifies that the statistics should be set to zero
pstack
This command displays a stack trace for each process. The pstack command must be run by the owner of the
process or by root. You can use pstack to determine where a process is hung. The only option that is allowed with
this command is the PID of the process that you want to check.
rpcinfo
This command generates information about the RPC service that is running on a system. You can also use this
command to change the RPC service. Many options are available with this command. The data that is generated
by this command can include the following:
The RPC program number
The version number for a specific program
The transport protocol that is being used
The name of the RPC service
The owner of the RPC service
snoop
This command is often used to watch for packets on the network. The snoop command must be run as root. The
use of this command is a good way to ensure that the network hardware is functioning on both the client and the
server. When troubleshooting, make sure that packets are going to and from the proper host. Also, look for error
messages. Saving the packets to a file can simplify the review of the data.

truss
You can use this command to check if a process is hung. The truss command must be run by the owner of the
process or by root. You can use many options with this command. A shortened syntax of the command follows.
truss [ -t syscall ] -p pid
-t syscall Selects system calls to trace
-p pid Indicates the PID of the process to be traced
The syscall can be a comma-separated list of system calls to be traced. Also, starting syscall with an ! selects to
exclude the listed system calls from the trace. This example shows that the process is waiting for another
connection request from a new client.
# /usr/bin/truss -p 243
poll(0x00024D50, 2, -1) (sleeping...)
The previous example shows a normal response. If the response does not change after a new connection request
has been made, the process could be hung.
Example Commands from Client:
% /usr/sbin/ping bee
% nfsstat -m
% /usr/lib/nis/nisping -u
% /usr/bin/getent hosts bee
Checking server from a remotely:
% rpcinfo -s bee|egrep nfs|mountd
% /usr/bin/rpcinfo -u bee nfs
% /usr/bin/rpcinfo -u bee mountd
Commands on Server:
# /usr/bin/rpcinfo -u localhost rpcbind
# rpcinfo -u localhost nfs
# ps -ef | grep nfsd
# /usr/bin/rpcinfo -u localhost mountd
# ps -ef | grep mountd
11.6. Autofs
File systems that are shared through the NFS service can be mounted by using automatic mounting. Autofs, a
client-side service, is a file-system structure that provides automatic mounting. The autofs file system is initialized
by automount, which is run automatically when a system is booted. The automount daemon, automountd, runs
continuously, mounting and unmounting remote directories as necessary.
Whenever a client computer that is running automountd tries to access a remote file or remote directory, the
daemon mounts the remote file system. This remote file system remains mounted for as long as needed. If the
remote file system is not accessed for a certain period of time, the file system is automatically unmounted.
Mounting need not be done at boot time, and the user no longer has to know the superuser password to mount a
directory. Users do not need to use the mount and umount commands. The autofs service mounts and unmounts
file systems as required without any intervention by the user. Mounting some file hierarchies with automountd
does not exclude the possibility of mounting other hierarchies with mount. A diskless computer must mount /
(root), /usr, and /usr/kvm through the mount command and the /etc/vfstab file.
11.6.1. Autofs Features

Autofs works with file systems that are specified in the local namespace. This information can be maintained in
NIS, NIS+, or local files. A fully multithreaded version of automountd was included in the Solaris 2.6 release. This
enhancement makes autofs more reliable and enables concurrent servicing of multiple mounts, which prevents
the service from hanging if a server is unavailable.

The new automountd also provides better on-demand mounting. Previous releases would mount an entire set of
file systems if the file systems were hierarchically related. Now, only the top file system is mounted. Other file
systems that are related to this mount point are mounted when needed.
The autofs service supports browsability of indirect maps. This support enables a user to see which directories
could be mounted, without having to actually mount each file system. A -nobrowse option has been added to the
autofs maps so that large file systems, such as /net and /home, are not automatically browsable. Also, you can
turn off autofs browsability on each client by using the -n option with automount.
11.6.2. Autofs Maps

Autofs uses three types of maps:
1. Master map
2. Direct maps
3. Indirect maps
Master Autofs Map

The auto_master map associates a directory with a map. The map is a master list that specifies all the maps
that autofs should check. The following example shows what an auto_master file could contain.
Sample /etc/auto_master File
# Master map for automounter
#
+auto_master
/net -hosts -nosuid,nobrowse
/home auto_home -nobrowse
/- auto_direct -ro
This example shows the generic auto_master file with one addition for the auto_direct map. Each line in the
master map /etc/auto_master has the following syntax:
mount-point map-name [ mount-options ]
mount-point mount-point is the full (absolute) path name of a directory. If the directory does not exist, autofs
creates the directory if possible. If the directory exists and is not empty, mounting on the directory hides its
contents. In this situation, autofs issues a warning.
The notation /- as a mount point indicates that this particular map is a direct map. The notation also means that
no particular mount point is associated with the map.
map-name map-name is the map autofs uses to find directions to locations, or mount information. If the name is
preceded by a slash (/), autofs interprets the name as a local file. Otherwise, autofs searches for the mount
information by using the search that is specified in the name-service switch configuration file
(/etc/nsswitch.conf).
mount-options mount-options is an optional, comma-separated list of options that apply to the mounting of the
entries that are specified in map-name, unless the entries in map-name list other options. Options for each
specific type of file system are listed in the mount man page for that file system.
For NFS-specific mount points, the bg (background) and fg (foreground) options do not apply. A line that begins
with # is a comment. All the text that follows until the end of the line is ignored. To split long lines into shorter
ones, put a backslash (\) at the end of the line. The maximum number of characters of an entry is 1024.
Note If the same mount point is used in two entries, the first entry is used by the automount command. The
second entry is ignored.
Mount Point /home
The mount point /home is the directory under which the entries that are listed in /etc/auto_home (an indirect
map) are to be mounted.

Note Autofs runs on all computers and supports /net and /home (automounted home directories) by default.
These defaults can be overridden by entries in the NIS auto.master map or NIS+ auto_master table, or by local
editing of the /etc/auto_master file.
Mount Point /net
Autofs mounts under the directory /net all the entries in the special map -hosts. The map is a built-in map that
uses only the hosts database. Suppose that the computer gumbo is in the hosts database and it exports any of
its file systems. The following command changes the current directory to the root directory of the computer
gumbo.
% cd /net/gumbo
Autofs can mount only the exported file systems of host gumbo, that is, those file systems on a server that are
available to network users instead of those file systems on a local disk. Therefore, all the files and directories on
gumbo might not be available through /net/gumbo.
With the /net method of access, the server name is in the path and is location dependent. If you want to move
an exported file system from one server to another, the path might no longer work. Instead, you should set up an
entry in a map specifically for the file system you want rather than use /net.
Note Autofs checks the servers export list only at mount time. After a servers file systems are mounted, autofs
does not check with the server again until the servers file systems are automatically unmounted. Therefore,
newly exported file systems are not seen until the file systems on the client are unmounted and then remounted.
Direct Autofs Maps
A direct map is an automount point. With a direct map, a direct association exists between a mount point on the
client and a directory on the server. Direct maps have a full path name and indicate the relationship explicitly. The
following is a typical
/etc/auto_direct map:
/usr/local -ro \
/bin ivy:/export/local/sun4 \
/share ivy:/export/local/share \
/src ivy:/export/local/src
/usr/man -ro oak:/usr/man \
rose:/usr/man \
willow:/usr/man
/usr/games -ro peach:/usr/games
/usr/spool/news -ro pine:/usr/spool/news \
willow:/var/spool/news
Lines in direct maps have the following syntax:
key [ mount-options ] location
key key is the path name of the mount point in a direct map.
mount-options mount-options is the options that you want to apply to this particular mount. These options are
required only if the options differ from the map default. Options for each specific type of file system are listed in
the mount man page for that file system.
location location is the location of the file system. One or more file systems are specified as server:pathname for
NFS file systems or :devicename for High Sierra file systems (HSFS).
Note The pathname should not include an automounted mount point. The pathname should be the actual
absolute path to the file system. For instance, the location of a home directory should be listed as
server:/export/home/username, not as server:/home/username.
As in the master map, a line that begins with # is a comment. All the text that follows until the end of the line is
ignored. Put a backslash at the end of the line to split long lines into shorter ones. Of all the maps, the entries in a
direct map most closely resemble the corresponding entries in /etc/vfstab. An entry might appear in
/etc/vfstab as follows:
dancer:/usr/local - /usr/local/tmp nfs - yes ro

The equivalent entry appears in a direct map as follows:

/usr/local/tmp -ro dancer:/usr/local
Note No concatenation of options occurs between the automounter maps. Any options that are added to an
automounter map override all options that are listed in maps that are searched earlier. For instance, options that
are included in the auto_master map would be overridden by corresponding entries in any other map.
Mount Point /
The mount point /- tells autofs not to associate the entries in auto_direct with any specific mount point.
Indirect maps use mount points that are defined in the auto_master file. Direct maps use mount points that are
specified in the named map. Remember, in a direct map the key, or mount point, is a full path name. An NIS or
NIS+ auto_master file can have only one direct map entry because the mount point must be a unique value in
the namespace. An auto_master file that is a local file can have any number of direct map entries if entries are
not duplicated.
Indirect Autofs Maps
An indirect map uses a substitution value of a key to establish the association between a mount point on the client
and a directory on the server. Indirect maps are useful for accessing specific file systems, such as home
directories. The auto_home map is an example of an indirect map. Lines in indirect maps have the following
general syntax:
key [ mount-options ] location
key key is a simple name without slashes in an indirect map.
mount-options mount-options is the options that you want to apply to this particular mount. These options are
required only if the options differ from the map default. Options for each specific type of file system are listed in
the mount man page for that file system.
location location is the location of the file system. One or more file systems are specified as server:pathname.
Note The pathname should not include an automounted mount point. The pathname should be the actual
absolute path to the file system. For instance, the location of a directory should be listed as
server:/usr/local, not as server:/net/server/usr/local. As in the master map, a line that begins
with # is a comment. All the text that follows until the end of the line is ignored. Put a backslash (\) at the end of
the line to split long lines into shorter ones. An example auto_master map that contains the following entry:
/home auto_home -nobrowse
auto_home is the name of the indirect map that contains the entries to be mounted under /home. A typical
auto_home map might contain the following:
david willow:/export/home/david
rob cypress:/export/home/rob
gordon poplar:/export/home/gordon
rajan pine:/export/home/rajan
tammy apple:/export/home/tammy
jim ivy:/export/home/jim
linda -rw,nosuid peach:/export/home/linda
As an example, assume that the previous map is on host oak. Suppose that the user linda has an entry in the
password database that specifies her home directory as /home/linda. Whenever linda logs in to computer oak,
autofs mounts the directory /export/home/linda that resides on the computer peach. Her home directory is
mounted read-write, nosuid.
Assume the following conditions occur: User lindas home directory is listed in the password database as
/home/linda. Anybody, including Linda, has access to this path from any computer that is set up with the
master map referring to the map in the previous example. Under these conditions, user linda can run login or
rlogin on any of these computers and have her home directory mounted in place for her. Furthermore, now Linda
can also type the following command:
% cd ~david
autofs mounts Davids home directory for her (if all permissions allow).

Note No concatenation of options occurs between the automounter maps. Any options that are added to an
automounter map override all options that are listed in maps that are searched earlier. For instance, options that
are included in the auto_master map are overridden by corresponding entries in any other map. On a network
without a name service, you have to change all the relevant files (such as /etc/passwd) on all systems on the
network to allow Linda access to her files. With NIS, make the changes on the NIS master server and propagate
the relevant databases to the slave servers. On a network that is running NIS+, propagating the relevant
databases to the slave servers is done automatically after the changes are made.
11.6.3. How Autofs Works

Autofs is a client-side service that automatically mounts the appropriate file system. The following is a simplified
overview of how autofs works. The automount daemon automountd is started at boot time by the service
svc:/system/filesystem/autofs. This service also runs the automount command, which reads the master
map and installs autofs mount points.
Autofs is a kernel file system that supports automatic mounting and unmounting. When a request is made to
access a file system at an autofs mount point, the following occurs:
1. Autofs intercepts the request.
2. Autofs sends a message to the automountd for the requested file system to be mounted.
3. automountd locates the file system information in a map, creates the trigger nodes, and performs the
mount.
4. Autofs allows the intercepted request to proceed.
5. Autofs unmounts the file system after a period of inactivity.
Note Mounts that are managed through the autofs service should not be manually mounted or unmounted.
Even if the operation is successful, the autofs service does not check that the object has been unmounted,
resulting in possible inconsistencies. A reboot clears all the autofs mount points.
Default Autofs Behavior with Name Services
At boot time autofs is invoked by the service svc:/system/filesystem/autofs and autofs checks for the
master auto_master map. Autofs is subject to the rules that are discussed subsequently. Autofs uses the name
service that is specified in the automount entry of the /etc/nsswitch.conf file. If NIS+ is specified, as
opposed to local files or NIS, all map names are used as is. If NIS is selected and autofs cannot find a map that
autofs needs, but finds a map name that contains one or more underscores, the underscores are changed to
dots. This change allows the old NIS file names to work. Then autofs checks the map again, as shown below.

The screen activity for this session would resemble the following example.
$ grep /home /etc/auto_master
/home auto_home
$ ypmatch brent auto_home
Cant match key brent in map auto_home. Reason: no such map in servers domain.
$ ypmatch brent auto.home
diskus:/export/home/diskus1/&
If files is selected as the name service, all maps are assumed to be local files in the /etc directory. Autofs
interprets a map name that begins with a slash (/) as local regardless of which name service autofs uses.

Chapter 12 Solaris Volume Manager Page 142 of 198
12. Solaris Volume Manager

12.1. Introduction to Storage Management
In this chapter we will learn how to set up and maintain systems using Solaris Volume Manager to manage
storage for high availability, flexibility, and reliability. However, you should always maintain backups of your data,
particularly before you modify an active Solaris Volume Manager configuration.
How you choose to manage your storage determines how you control the devices that store the active data on
your system. To be useful, active data must be available and remain persistent even after unexpected events,
such as a hardware or software failure.
RAID Levels
RAID is an acronym for Redundant Array of Inexpensive (or Independent) Disks. RAID refers to a set of disks,
called an array or a volume that appears to the user as a single large disk drive. Depending on the configuration,
this array provides improved reliability, response time, or storage capacity. Technically, there are six RAID levels,
0-5. Each level refers to a method of distributing data while ensuring data redundancy. Very few storage
environments support RAID Levels 2, 3, and 4, so those environments are not described here.
Solaris Volume Manager supports the following RAID levels:
RAID LEVEL 0 Although stripes and concatenations do not provide redundancy, these volumes are often
referred to as RAID-0. Basically, data are spread across relatively small, equally-sized fragments that are
allocated alternately and evenly across multiple physical disks. Any single drive failure can cause data loss.
RAID-0 offers a high data transfer rate and high I/O throughput, but suffers lower reliability and lower availability
than a single disk.
RAID Level 1 Mirroring uses equal amounts of disk capacity to store data and a copy (mirror) of the data. Data
is duplicated, or mirrored, over two or more physical disks. Data can be read from both drives simultaneously,
meaning that either drive can service any request, which provides improved performance. If one physical disk
fails, you can continue to use the mirror with no loss in performance or loss of data. Solaris Volume Manager
supports RAID-0+1 and (transparently) RAID-1+0 mirroring, depending on the underlying volumes
RAID Level 5 RAID-5 uses striping to spread the data over the disks in an array. RAID-5 also records parity
information to provide some data redundancy. A RAID-5 volume can withstand the failure of an underlying device
without failing. If a RAID-5 volume is used in conjunction with hot spares, the volume can withstand multiple
failures without failing. A RAID-5 volume will have substantial performance degradation when operating with a
failed device.
In the RAID-5 model, every device has one area that contains a parity stripe and other areas that contain data.
The parity is spread over all of the disks in the array, which reduces the write time. Write time is reduced because
writes do not have to wait until a dedicated parity disk can accept the data.
For any given configuration, there are trade-offs in performance, availability, and hardware costs. You might need
to experiment with the different variables to determine what works best for your configuration.
Write and Read Optimizations:
Differences between the various storage mechanisms:

12.2. Introduction to Solaris Volume Manager

Solaris Volume Manager is a software product that lets you manage large numbers of disks and the data on those
disks. Although there are many ways to use Solaris Volume Manager, most tasks include the following:
1. Increasing storage capacity
2. Increasing data availability
3. Easing administration of large storage devices
4. In some instances, Solaris Volume Manager can also improve I/O performance.
How Solaris Volume Manager Manages Storage

Solaris Volume Manager uses virtual disks to manage physical disks and their associated data. In Solaris Volume
Manager, a virtual disk is called a volume. For historical reasons, some command-line utilities also refer to a
volume as a metadevice.
From the perspective of an application or a file system, a volume is functionally identical to a physical disk. Solaris
Volume Manager converts I/O requests directed at a volume into I/O requests to the underlying member disks.
Solaris Volume Manager volumes are built from disk slices or from other Solaris Volume Manager volumes.
For example, if you need more storage capacity as a single volume, you could use Solaris Volume Manager to
make the system treat a collection of slices as one larger volume. After you create a volume from these slices,
you can immediately begin using the volume just as you would use any real slice or device.
Solaris Volume Manager can increase the reliability and availability of data by using RAID-1 (mirror) volumes and
RAID-5 volumes. Solaris Volume Manager hot spares can provide another level of data availability for mirrors and
RAID-5 volumes.
12.3. Solaris Volume Manager Requirements

Solaris Volume Manager requirements include the following:
1. You must be superuser
2. Before you can create volumes with Solaris Volume Manager, state database replicas must exist on the
Solaris Volume Manager system. A state database replica contains configuration and status information
for all volumes, hot spares, and disk sets. At least three replicas should exist, and the replicas should be
placed on different controllers and different disks for maximum reliability.
Solaris Volume Manager Components
The five basic types of components that you create with Solaris Volume Manager are volumes, soft partitions,
disk sets, state database replicas, and hot spare pools.
Volumes

A volume is a group of physical slices that appears to the system as a single, logical device. Volumes are
actually pseudo, or virtual, devices in standard UNIX terms. Historically, the Solstice DiskSuite product referred to
these logical devices as metadevices. For standardization, these devices are referred to as volumes.
Classes of Volumes
Volumes behave the same way as slices. Because volumes look like slices, the volumes are transparent to end
users, applications, and file systems. As with physical devices, volumes are accessed through block or raw device
names. Solaris Volume Manager enables you to expand a volume by adding additional slices and also expand
(using growfs) a UFS filesystem on-line.
Note After a file system has been expanded, the file system cannot be reduced in size. The inability to reduce
the size of a file system is a UFS limitation. Similarly, after a Solaris Volume Manager partition has been
increased in size, it cannot be reduced.
Volume Name Requirements
Volume names must begin with the letter d followed by a number (for example, d0). Solaris Volume Manager
has 128 default volume names from 0127. The following shows some example volume names.
/dev/md/dsk/d0 Block volume d0
/dev/md/dsk/d1 Block volume d1
/dev/md/rdsk/d126 Raw volume d126
/dev/md/rdsk/d127 Raw volume d127
State Database and State Database Replicas
The state database is a database that stores information about the state of your Solaris Volume Manager
configuration. The state database records and tracks changes made to your configuration. Solaris Volume
Manager automatically updates the state database when a configuration or state change occurs. Creating a new
volume is an example of a configuration change. A submirror failure is an example of a state change.
The state database is actually a collection of multiple, replicated database copies. Each copy, referred to as a
state database replica, and ensures that the data in the database is always valid. Multiple copies of the state
database protect against data loss from single points-of-failure. The state database tracks the location and status
of all known state database replicas. Solaris Volume Manager cannot operate until you have created the state
database and its state database replicas. A Solaris Volume Manager configuration must have an operating state
database.
When you set up your configuration, you can locate the state database replicas on either of the following:
On dedicated slices
On slices that will later become part of volumes
Solaris Volume Manager recognizes when a slice contains a state database replica, and automatically skips over
the replica if the slice is used in a volume. The part of a slice reserved for the state database replica should not be
used for any other purpose. You can keep more than one copy of a state database on one slice. However, you
might make the system more vulnerable to a single point-of-failure by doing so. The Solaris operating system

continues to function correctly if all state database replicas are deleted. However, the system loses all Solaris
Volume Manager configuration data if a reboot occurs with no existing state database replicas on disk.
Hot Spare Pools
A hot spare pool is a collection of slices (hot spares) reserved by Solaris Volume Manager to be automatically
substituted for failed components. These hot spares can be used in either a submirror or RAID-5 volume. Hot
spares provide increased data availability for RAID-1 and RAID-5 volumes.
When component errors occur, Solaris Volume Manager checks for the first available hot spare whose size is
equal to or greater than the size of the failed component. If found, Solaris Volume Manager automatically replaces
the component and resynchronizes the data. If a slice of adequate size is not found in the list of hot spares, the
submirror or RAID-5 volume is considered to have failed.
Disk Sets
A disk set is a set of physical storage volumes that contain logical volumes and hot spares. Volumes and hot
spare pools must be built on drives from within that disk set. Once you have created a volume within the disk set,
you can use the volume just as you would a physical slice. A disk set provides data availability in a clustered
environment. If one host fails, another host can take over the failed hosts disk set. (This type of configuration is
known as a failover configuration.) Additionally, disk sets can be used to help manage the Solaris Volume
Manager namespace, and to provide ready access to network-attached storage devices.
12.4. SVM Configuration

General Guidelines
Disk and controllers Place drives in a volume on separate drive paths, or for SCSI drives, separate host
adapters. An I/O load distributed over several controllers improves volume performance and availability.
System files Never edit or remove the /etc/lvm/mddb.cf or /etc/lvm/md.cf files. Make sure these files are
backed up regularly.
Volume Integrity If a slice is defined as a volume, do not use the underlying slice for any other purpose,
including using the slice as a dump device.
Information about disks and partitions Keep a copy of output from the prtvtoc and metastat -p commands in
case you need to reformat a bad disk or recreate your Solaris Volume Manager configuration.
File System Guidelines
Do not mount file systems on a volumes underlying slice. If a slice is used for a volume of any kind, you must not
mount that slice as a file system. If possible, unmount any physical device that you intend to use as a volume
before you activate the volume.
When you create a Solaris Volume Manager component, you assign physical slices to a logical Solaris Volume
Manager name, such as d0. The Solaris Volume Manager components that you can create include the following:
State database replicas
Volumes (RAID-0 (stripes, concatenations), RAID-1 (mirrors), RAID-5, and soft partitions)
Hot spare pools
Disk sets
Prerequisites for Creating Solaris Volume Manager Components
The prerequisites for creating Solaris Volume Manager components are as follows:
Create initial state database replicas
Identify slices that are available for use by Solaris Volume Manager.
Make sure you have root privilege.
1. Have a current backup of all data.
2. If you are using the GUI, start the Solaris Management Console and navigate to the Solaris Volume
Manager feature.
Starting with the Solaris 9 4/03 release, Solaris Volume Manager supports storage devices and logical volumes
greater than 1 terabyte (Tbyte) on systems running a 64-bit kernel.

Note Use isainfo -v to determine if your system is running a 64-bit kernel. If the string 64-bit appears, you are
running a 64-bit kernel.
Solaris Volume Manager allows you to do the following:
Create, modify, and delete logical volumes built on or from logical storage units (LUNs) greater than 1
Tbyte in size.
Create, modify, and delete logical volumes that exceed 1 Tbyte in size. Support for large volumes is
automatic. If a device greater than 1 Tbyte is created, Solaris Volume Manager configures it
appropriately and without user intervention.
Note Do not create large volumes if you expect to run the Solaris software with a 32-bit kernel or if you expect
to use a version of the Solaris OS prior to the Solaris 9 4/03 release.
Volume Manager State Database and Replicas
The Solaris Volume Manager state database contains configuration and status information for all volumes, hot
spares, and disk sets. Solaris Volume Manager maintains multiple copies (replicas) of the state database to
provide redundancy and to prevent the database from being corrupted during a system crash (at most, only one
database copy will be corrupted). The state database replicas ensure that the data in the state database is always
valid. When the state database is updated, each state database replica is also updated. The updates occur one at
a time (to protect against corrupting all updates if the system crashes). If your system loses a state database
replica, Solaris Volume Manager must figure out which state database replicas still contain valid data. Solaris
Volume Manager determines this information by using a majority consensus algorithm. This algorithm requires
that a majority (half + 1) of the state database replicas be available and in agreement before any of them are
considered valid. Because of the requirements of the majority consensus algorithm, you must create at least three
state database replicas when you set up your disk configuration. A consensus can be reached as long as at least
two of the three state database replicas are available. During booting, Solaris Volume Manager ignores corrupted
state database replicas. In some cases, Solaris Volume Manager tries to rewrite state database replicas that are
corrupted. Otherwise, they are ignored until you repair them. If a state database replica becomes corrupted
because its underlying slice encountered an error, you need to repair or replace the slice and then enable the
replica.
If all state database replicas are lost, you could, in theory, lose all data that is stored on your Solaris Volume
Manager volumes. For this reason, it is good practice to create enough state database replicas on separate drives
and across controllers to prevent catastrophic failure. It is also wise to save your initial Solaris Volume Manager
configuration information, as well as your disk partition information.
State database replicas are also used for RAID-1 volume resynchronization regions. Too few state database
replicas relative to the number of mirrors might cause replica I/O to impact RAID-1 volume performance. That is, if
you have a large number of mirrors, make sure that you have at least two state database replicas per RAID-1
volume, up to the maximum of 50 replicas per disk set. By default each state database replica occupies 4 Mbytes
(8192 disk sectors) of disk storage. Replicas can be stored on the following devices:
A dedicated local disk partition
A local partition that will be part of a volume
A local partition that will be part of a UFS logging device
Note Replicas cannot be stored on the root (/), swap, or /usr slices. Nor can replicas be stored on slices that
contain existing file systems or data. After the replicas have been stored, volumes or file systems can be placed
on the same slice.
Understanding the Majority Consensus Algorithm
An inherent problem with replicated databases is that it can be difficult to determine which database has valid and
correct data. To solve this problem, Solaris Volume Manager uses a majority consensus algorithm. This algorithm
requires that a majority of the database replicas agree with each other before any of them are declared valid. This
algorithm requires the presence of at least three initial replicas, which you create. A consensus can then be
reached as long as at least two of the three replicas are available. If only one replica exists and the system
crashes, it is possible that all volume configuration data will be lost.
To protect data, Solaris Volume Manager does not function unless half of all state database replicas are available.
The algorithm, therefore, ensures against corrupt data. The majority consensus algorithm provides the following:
1. The system continues to run if at least half of the state database replicas are available.
2. The system panics if fewer than half of the state database replicas are available.

3. The system cannot reboot into multiuser mode unless a majority (half + 1) of the total number of state
database replicas is available.
4. If insufficient state database replicas are available, you must boot into single-user mode and delete
enough of the corrupted or missing replicas to achieve a quorum.
Note When the total number of state database replicas is an odd number, Solaris Volume Manager computes
the majority by dividing the number in half, rounding down to the nearest integer, then adding 1 (one). For
example, on a system with seven replicas, the majority would be four (seven divided by two is three and one-half,
rounded down is three, plus one is four).
Administering State Database Replicas
1. By default, the size of a state database replica is 4 Mbytes or 8192 blocks. You should create state
database replicas on a dedicated slice with at least 4 Mbytes per replica. Because your disk slices might
not be that small, you might want to resize a slice to hold the state database replica. To avoid single
points-of-failure, distribute state database replicas across slices, drives, and controllers. You want a
majority of replicas to survive a single component failure. If you lose a replica (for example, due to a
device failure), problems might occur with running Solaris Volume Manager or when rebooting the
system. Solaris Volume Manager requires at least half of the replicas to be available to run, but a majority
(half + 1) to reboot into multiuser mode. A minimum of 3 state database replicas are recommended, up to
a maximum of 50 replicas per Solaris Volume Manager disk set. The following guidelines are
recommended:
a. For a system with only a single drive: put all three replicas on one slice.
b. For a system with two to four drives: put two replicas on each drive.
c. For a system with five or more drives: put one replica on each drive.
2. If multiple controllers exist, replicas should be distributed as evenly as possible across all controllers. This
strategy provides redundancy in case a controller fails and also helps balance the load. If multiple disks
exist on a controller, at least two of the disks on each controller should store a replica.
3. If necessary, you could create state database replicas on a slice that will be used as part of a RAID-0,
RAID-1, or RAID-5 volume, or soft partitions. You must create the replicas before you add the slice to the
volume. Solaris Volume Manager reserves the beginning of the slice for the state database replica. When
a state database replica is placed on a slice that becomes part of a volume, the capacity of the volume is
reduced by the space that is occupied by the replica. The space used by a replica is rounded up to the
next cylinder boundary. This space is skipped by the volume.
4. RAID-1 volumes are used for small-sized random I/O (as in for a database). For best performance, have
at least two extra replicas per RAID-1 volume on slices (and preferably on separate disks and controllers)
that are unconnected to the RAID-1 volume.
5. You cannot create state database replicas on existing file systems, or the root (/), /usr, and swap file
systems. If necessary, you can create a new slice (provided a slice name is available) by allocating space
from swap. Then, put the state database replicas on that new slice.
6. You can create state database replicas on slices that are not in use.
7. You can add additional state database replicas to the system at any time. The additional state database
replicas help ensure Solaris Volume Manager availability.
Handling State Database Replica Errors

If a state database replica fails, the system continues to run if at least half of the remaining replicas are available.
The system panics when fewer than half of the replicas are available. The system can reboot into multiuser mode
when at least one more than half of the replicas are available. If fewer than a majority of replicas are available,
you must reboot into single-user mode and delete the unavailable replicas (by using the metadb command). For
example, assume you have four replicas. The system continues to run as long as two replicas (half the total
number) are available. However, to reboot the system, three replicas (half the total + 1) must be available. In a
two-disk configuration, you should always create at least two replicas on each disk. For example, assume you
have a configuration with two disks, and you only create three replicas (two replicas on the first disk and one
replica on the second disk). If the disk with two replicas fails, the system panics because the remaining disk only
has one replica. This is less than half the total number of replicas.
Note If you create two replicas on each disk in a two-disk configuration, Solaris Volume Manager still functions
if one disk fails. But because you must have one more than half of the total replicas available for the system to
reboot, you cannot reboot. If a slice that contains a state database replica fails, the rest of your configuration
should remain in operation. Solaris Volume Manager finds a valid state database during boot (as long as at least

half +1 valid state database replicas are available). When you manually repair or enable state database replicas,
Solaris Volume Manager updates them with valid data.
# metadb -a -c number -l length-of replica -f ctds-of-slice
-a Specifies to add or create a state database replica.
-f Specifies to force the operation, even if no replicas exist. Use the -f to force the creation of the initial replicas.
-c number Specifies the number of replicas to add to the specified slice.
-l length-of-replica Specifies the size of the new replicas, in blocks. The default size is 8192. This size should be
appropriate for virtually all configurations, including those configurations with thousands of logical volumes.
ctds-of-slice Specifies the name of the component that will hold the replica.
Note The metadb command entered on the command line without options reports the status of all state
database replicas.
Creating the First State Database Replica
# metadb -a -f c0t0d0s7
# metadb
flags first blk block count
...
a u 16 8192 /dev/dsk/c0t0d0s7
You must use the -f option along with the -a option to create the first state database replica. The -a option
adds state database replicas to the system.The -f option forces the creation of the first replica (and may be
omitted when you add supplemental replicas to the system).
Adding Two State Database Replicas to the Same Slice
# metadb -a -c 2 c1t3d0s1
# metadb
...
a u 8208 8192 /dev/dsk/c1t3d0s1
The -a option adds state database replicas to the system. The -c 2 option places two replicas on the specified
slice. The metadb command checks that the replicas are active, as indicated by the a flag in the metadb
command output.
Adding State Database Replicas of a Specific Size
If you are replacing existing state database replicas, you might need to specify a replica size. Particularly if you
have existing state database replicas (on a system upgraded from the Solstice DiskSuite product, perhaps) that
share a slice with a file system, you must replace existing replicas with other replicas of the same size or add new
replicas in a different location.
# metadb -a -c 3 -l 1034 c0t0d0s7
# metadb
...
a u 1050 1034 /dev/dsk/c0t0d0s7
a u 2084 1034 /dev/dsk/c0t0d0s7
The -a option adds state database replicas to the system. The -l option specifies the length in blocks of the
replica to add.
Maintaining State Database Replicas
How to Check the Status of State Database Replicas
1. Become superuser.

2. To check the status of state database replicas, use one of the following methods:
From the Enhanced Storage tool within the Solaris Management Console, open the State Database Replicas
node to view all existing state database replicas.
Use the metadb command to view the status of state database replicas. Add the -i option to display an
explanation of the status flags, as shown in the following example
Checking the Status of All State Database Replicas
# metadb -i
a m p luo 16 8192 /dev/dsk/c0t0d0s7
a p luo 8208 8192 /dev/dsk/c0t0d0s7
W p l 16 8192 /dev/dsk/c2t3d0s1
r - replica does not have device relocation information
o - replica active prior to last mddb configuration change
u - replica is up to date
l - locator for this replica was read successfully
c - replicas location was in /etc/lvm/mddb.cf
p - replicas location was patched in kernel
m - replica is master, this is replica selected as input
W - replica has device write errors
a - replica is active, commits are occurring to this replica
M - replica had problem with master blocks
D - replica had problem with data blocks
F - replica had format problems
S - replica is too small to hold current data base
R - replica had device read errors
A legend of all the flags follows the status. The characters in front of the device name represent the status.
Uppercase letters indicate a problem status. Lowercase letters indicate an Okay status.
How to Delete State Database Replicas
You might need to delete state database replicas to maintain your Solaris Volume Manager configuration. For
example, if you will be replacing disk drives, you want to delete the state database replicas before you remove the
drives. Otherwise Solaris Volume Manager will report them as having errors.
1. Become superuser.
2. To remove state database replicas, use one of the following methods:
From the Enhanced Storage tool within the Solaris Management Console, open the State Database Replicas
node to view all existing state database replicas. Select replicas to delete, then choose EditDelete to remove
them. Use the following form of the metadb command:
# metadb -d -f ctds-of-slice
-d Specifies to delete a state database replica.
-f Specifies to force the operation, even if no replicas exist.

ctds-of-slice Specifies the name of the component that contains the replica. Note that you need to specify each
slice from which you want to remove the state database replica.
Deleting State Database Replicas
# metadb -d -f c0t0d0s7
This example shows the last replica being deleted from a slice. You must add the -f option to force the deletion
of the last replica on the system.
12.5. Overview of RAID-0 Volumes

RAID-0 volumes are composed of slices or soft partitions. These volumes enable you to expand disk storage
capacity. They can be used either directly or as the building blocks for RAID-1 (mirror) volumes, and soft
partitions. There are three kinds of RAID-0 volumes:
1. Stripe volumes
2. Concatenation volumes
3. Concatenated stripe volumes
Note A component refers to any devices, from slices to soft partitions, used in another logical volume.
A stripe volume spreads data equally across all components in the volume, while a concatenation volume writes
data to the first available component until it is full, then moves to the next available component. A concatenated
stripe volume is simply a stripe volume that has been expanded from its original configuration by adding additional
components. For sequential I/O operations on a stripe volume, Solaris Volume Manager reads all the blocks in a
segment of blocks (called an interlace) on the first component, then all the blocks in a segment of blocks on the
second component, and so forth. For sequential I/O operations on a concatenation volume, Solaris Volume
Manager reads all the blocks on the first component, then all the blocks of the second component, and so forth.
On both a concatenation volume and a stripe volume, all I/O operations occur in parallel.
Fig: RAID 0 Stripe Volume Example

Fig: RAID 0 - Concatenation Volume Example
Fig: RAID 0 Concatenated Stripe Example
12.6. Overview of RAID-1 (Mirror) Volumes

A RAID-1 volume, or mirror, is a volume that maintains identical copies of the data in RAID-0 (stripe or
concatenation) volumes. The RAID-0 volumes that are mirrored are called submirrors. Mirroring requires an
investment in disks. You need at least twice as much disk space as the amount of data you have to mirror.
Because Solaris Volume Manager must write to all submirrors, mirroring can also increase the amount of time it

takes for write requests to be written to disk. After you configure a mirror, the mirror can be used just like a
physical slice. You can mirror any file system, including existing file systems. These file systems root (/), swap,
and /usr. You can also use a mirror for any application, such as a database.
Tip Use Solaris Volume Managers hot spare feature with mirrors to keep data safe and available.
Overview of Submirrors
A mirror is composed of one or more RAID-0 volumes (stripes or concatenations) called submirrors. A mirror can
consist of up to four submirrors. However, two-way mirrors usually provide sufficient data redundancy for most
applications and are less expensive in terms of disk drive costs. A third submirror enables you to make online
backups without losing data redundancy while one submirror is offline for the backup. If you take a submirror
offline, the mirror stops reading and writing to the submirror. At this point, you could access the submirror itself,
for example, to perform a backup. However, the submirror is in a read-only state. While a submirror is offline,
Solaris Volume Manager keeps track of all writes to the mirror. When the submirror is brought back online, only
the portions of the mirror that were written while the submirror was offline (the resynchronization regions) are
resynchronized. Submirrors can also be taken offline to troubleshoot or repair physical devices that have errors.
Submirrors can be attached or be detached from a mirror at any time, though at least one submirror must remain
attached at all times. Normally, you create a mirror with only a single submirror. Then, you attach a second
submirror after you create the mirror.
Fig: RAID 1 Mirror Example

Overview of Soft Partitions
As the storage capacity of disks has increased, disk arrays present larger logical devices to Solaris systems. In
order to create more manageable file systems or partition sizes, users might need to subdivide disks or logical
volumes into more than eight partitions. Solaris Volume Managers soft partition feature addresses this need.
Solaris Volume Manager can support up to 8192 logical volumes per disk set. This number includes the local, or
unspecified, disk set. However, by default Solaris Volume Manager is configured for 128 logical volumes per disk
set. This default configuration provides d0 through d127 as the namespace available for use by volumes.
Solaris Volume Manager configures volumes dynamically as they are needed.
You can use soft partitions to divide a disk slice or logical volume into as many partitions as needed. You must
provide a name for each division, or soft partition, just like you do for other storage volumes, such as stripes or
mirrors. A soft partition, once named, can be accessed by applications, including file systems, as long as the soft
partition is not included in another volume. Once included in a volume, the soft partition should no longer be
directly accessed.
12.7. Overview of RAID-5 Volumes

RAID level 5 is similar to striping, but with parity data distributed across all components (disk or logical volume). If
a component fails, the data on the failed component can be rebuilt from the distributed data and parity information
on the other components. In Solaris Volume Manager, a RAID-5 volume is a volume that supports RAID level 5. A
RAID-5 volume uses storage capacity equivalent to one component in the volume to store redundant information
(parity). This parity information contains information about user data stored on the remainder of the RAID-5
volumes components. That is, if you have three components, the equivalent of one component is used for the

parity information. If you have five components, then the equivalent of one component is used for parity
information. The parity information is distributed across all components in the volume. Similar to a mirror, a RAID-
5 volume increases data availability, but with a minimum of cost in terms of hardware and only a moderate
penalty for write operations. However, you cannot use a RAID-5 volume for the root (/), /usr, and swap file
systems, or for other existing file systems. Solaris Volume Manager automatically resynchronizes a RAID-5
volume when you replace an existing component. Solaris Volume Manager also resynchronizes RAID-5 volumes
during rebooting if a system failure or panic took place.
Fig: RAID 5 Volume Example
12.8. Overview of Hot Spares and Hot Spare Pools

A hot spare pool is collection of slices (hot spares) that Solaris Volume Manager uses to provide increased data
availability for RAID-1 (mirror) and RAID-5 volumes. In a slice failure occurs, in either a submirror or a RAID-5
volume, Solaris Volume Manager automatically substitutes the hot spare for the failed slice.
Note Hot spares do not apply to RAID-0 volumes or one-way mirrors. For automatic substitution to work,
redundant data must be available.
A hot spare cannot be used to hold data or state database replicas while it is idle. A hot spare must remain ready
for immediate use a slice failure occurs in the volume with which it is associated. To use hot spares, you must
invest in additional disks beyond those disks that the system actually requires to function. Solaris Volume
Manager enables you to dynamically add, delete, replace, and enable hot spares within hot spare pools.
How Hot Spares Work

When I/O errors occur, Solaris Volume Manager searches the hot spare pool for a hot spare based on the order
in which hot spares were added to the hot spare pool. Solaris Volume Manager checks the hot spare pool for the
first available hot spare whose size is equal to or greater than the size of the slice that is being replaced. The first
hot spare found by Solaris Volume Manager that is large enough is used as a replacement. Solaris Volume
Manager changes the hot spares status to In-Use and automatically resynchronizes the data if necessary. The
order of hot spares in the hot spare pool is not changed when a replacement occurs. In the case of a mirror, the

hot spare is resynchronized with data from a functional submirror. In the case of a RAID-5 volume, the hot spare
is resynchronized with the other slices in the volume. If a slice of adequate size is not found in the list of hot
spares, the submirror or RAID-5 volume that failed goes into a failed state and the hot spares remain unused. In
the case of the submirror, the submirror no longer replicates the data completely. In the case of the RAID-5
volume, data redundancy is no longer available.
Tip When you add hot spares to a hot spare pool, add them from smallest to largest in size. This strategy avoids
potentially wasting large hot spares as replacements for small slices.
Hot Spare Pools
A hot spare pool is an ordered list (collection) of hot spares. You can place hot spares into one or more hot spare
pools to get the most flexibility and protection from the fewest slices. You could put a single slice designated for
use as a hot spare into multiple hot spare pools, with each hot spare pool having different slices and
characteristics. Then, you could assign a hot spare pool to any number of submirror volumes or RAID-5 volumes.
Fig: Hot-Spare Pool Example
12.9. Introduction to Disk Sets

A disk set is a set of physical storage volumes that contain logical volumes and hot spares. Volumes and hot
spare pools must be built on drives from within that disk set. Once you have created a volume within the disk set,
you can use the volume just as you would use a physical slice. You can use the volume to create and to mount a
file system and to store data.
Note Disk sets are supported on both SPARC and x86 based platforms.
Solaris Volume Manager Disk Set Administration
Unlike local disk set administration, you do not need to manually create or delete disk set state databases. Solaris
Volume Manager places one state database replica (on slice 7) on each disk across all disks in the disk set, up to
a maximum of 50 total replicas in the disk set. When you add disks to a disk set, Solaris Volume Manager
automatically creates the state database replicas on the disk set. When a disk is accepted into a disk set, Solaris
Volume Manager might repartition the disk so that the state database replica for the disk set can be placed on the
disk. A file system that resides on a volume in a disk set normally is not mounted automatically at boot time with
the /etc/vfstab file. The necessary Solaris Volume Manager RPC daemons (rpc.metad and

rpc.metamhd) do not start early enough in the boot process to permit this. Additionally, the ownership of a disk
set is lost during a reboot. Do not disable the Solaris Volume Manager RPC daemons in the /etc/inetd.conf
file. They are configured to start by default. These daemons must remain enabled to allow Solaris Volume
Manager to use its full functionality. When the autotake feature is enabled using the -A option of the metaset
command, the disk set is automatically taken at boot time. Under these circumstances, a file system that resides
on a volume in a disk set can be automatically mounted with the /etc/vfstab file. To enable an automatic take
during the boot process, the disk set must be associated with only a single host, and must have the autotake
feature enabled. A disk set can be enabled either during or after disk set creation.
Fig: Disk Sets Example

Chapter 13 RBAC & Syslog Page 156 of 198
13. RBAC and Syslog

13.1. RBAC
Role-based access control (RBAC) is a security feature for controlling user access to tasks that would normally be
restricted to superuser. By applying security attributes to users, RBAC can divide up superuser capabilities
among several administrators. User rights management is implemented through RBAC.
RBAC COMPONENTS
Roles Authorizations
Rights
Profiles
In conventional UNIX systems, the root user, also referred to as superuser, is all-powerful. Programs that run as
root, or setuid programs, are all-powerful. The root user has the ability to read and write to any file, run all
programs, and send kill signals to any process. Effectively, anyone who can become superuser can modify a
sites firewall, alter the audit trail, read confidential records, and shut down the entire network. A setuid program
that is hijacked can do anything on the system.
Role-based access control (RBAC) provides a more secure alternative to the all-or-nothing superuser model. With
RBAC, you can enforce security policy at a more fine-grained level. RBAC uses the security principle of least
privilege. Least privilege means that a user has precisely the amount of privilege that is necessary to perform a
job. Ordinary users have enough privilege to use their applications, check the status of their jobs, print files,
create new files, and so on. Capabilities beyond ordinary user capabilities are grouped into rights profiles. Users
who are expected to do jobs that require some of the capabilities of superuser assume a role that includes the
appropriate rights profile. Few of the superuser capabilities grouped together is called a rights profile. These rights
profiles are assigned to special user accounts that are called roles. A user to whom some work is to be delegated
is assigned that role. Predefined rights profiles are supplied with Solaris software. You create the roles and assign
the profiles.
Examples of rights profiles:
Primary Administrator rights profile is equivalent to superuser is a broad capability profile.
Cron Management rights profile manages at and cron jobs is a narrow capability profile.
There is no hard and fast rule about roles and also no default roles are shipped with Solaris OE, but three
recommended roles are:
Primary Administrator A powerful role that is equivalent to the root user, or superuser.
System Administrator A less powerful role for administration that is not related to security. This role can
manage file systems, mail, and software installation. However, this role cannot set passwords.
Operator A junior administrator role for operations such as backups and printer management.
These are just recommended roles. According to the needs of your organization you can prepare your own roles.
The root user can also be converted into a role so as minimize security risk.
Solaris RBAC Elements and Basic Concepts

Roles: A role is a special type of user account from which you can run privileged applications. Roles are created
in the same general manner as user accounts. Roles have a home directory, a group assignment, a password,
and so on. Rights profiles and authorizations give the role administrative capabilities. Roles cannot inherit
capabilities from other roles or other users. Discrete roles parcel out superuser capabilities, and thus enable more
secure administrative practices. When a user assumes a role, the roles attributes replace all user attributes. Role
information is stored in the passwd, shadow, and user_attr databases. A role can be assigned to more than one
user. All users who can assume the same role have the same role home directory, operate in the same
environment, and have access to the same files.

Rights Profiles: A right, also known as a profile or a rights profile, is a collection of privileges that can be assigned
to a role or user. A rights profile can consist of authorizations, commands with setuid or setgid permissions
(referred to as security attributes), and other rights profiles.
Authorizations: An authorization is a discrete right that can be granted to a role or to a user. Authorizations
enforce policy at the user application level. Authorizations can be assigned directly to a role or to a user.
Typically, authorizations are included in a rights profile.
Applications That Check Authorizations

The Solaris OS additionally provides commands that check authorizations. By definition, the root user has all
authorizations. Therefore, the root user can run any application. Applications that check for authorizations include
the following:
1. The entire Solaris Management Console suite of tools
2. Audit administration commands, such as auditconfig and auditreduce
3. Printer administration commands, such as lpadmin and lpfilter
4. The batch job-related commands, such as at, atq, batch, and crontab
5. Device-oriented commands, such as allocate, deallocate, list_devices, and cdrw.
Profile Shell in RBAC
Roles can run privileged applications from the Solaris Management Console launcher or from a profile shell. A
profile shell is a special shell that recognizes the security attributes that are included in a rights profile. Profile
shells are launched when the user runs the su command to assume a role. The profile shells are pfsh, pfcsh,
and pfksh. The shells correspond to Bourne shell (sh), C shell (csh), and Korn shell (ksh), respectively.
The above figure illustrates the relationship between the various RBAC elements
RBAC can be configured with the following utilities:

Solaris Management Console GUI The preferred method for performing RBAC-related tasks is through the
GUI. The console tools for managing the RBAC elements are contained in the Users Tool collection.
Solaris Management Console commands With the Solaris Management Console command-line interfaces,
such as smrole, you can operate on any name service. The Solaris Management Console commands require
authentication to connect to the server. As a result, these commands are not practical for use in scripts.
Local commands With the user* and role* set of command-line interfaces, such as useradd, you can operate
on local files only. The commands that operate on local files must be run by superuser or by a role with the
appropriate privileges.

Databases That Support RBAC

/etc
user_attr security
prof_attr auth_attr exec_attr

The above tree shows the location of the databases that support RBAC.
Extended user attributes database (user_attr) Associates users and roles with authorizations and rights
Rights profile attributes database (prof_attr) Defines rights profiles, lists the profiles assigned authorizations,
and identifies the associated help file
Authorization attributes database (auth_attr) Defines authorizations and their attributes, and identifies the
associated help file
Execution attributes database (exec_attr) Identifies the commands with security attributes that are assigned
to specific rights profiles
Creating Role From the Command Line:

# roleadd -c comment -g group -m homedir -u UID -s shell -P profile rolename
-c comment Is a comment that describes rolename.
-g group Is the group assignment for rolename.
-m homedir Is the path to the home directory for rolename.
-u UID Is the UID for rolename.
-s shell Is the login shell for rolename. This shell must be a profile shell.
-P profile Is one or more rights profiles for rolename.
rolename Is the name of the new local role.
Assigning Role to a Local User:
# usermod -u UID -R rolename
-u UID Is the UID of the user.
-R rolename Is the role that is being assigned to the user.
To put the changes into effect, restart the name service cache daemon.
# svcadm restart system/name-service-cache
Changing the Properties of a Role:
$ rolemod -c comment -P profile-list rolename
-c comment Is the new comment that describes the capabilities of the role.
-P profile-list Is the list of the profiles that are included in the role. This list replaces the current list of profiles.
rolename Is the name of an existing, local role that you want to modify.
Changing the RBAC Properties of a User:
$ usermod -R rolename username
-R rolename Is the name of an existing local role.
username Is the name of an existing, local user that you want to modify.

NOTE:
Commands that are designated with euid run with the supplied UID, which is similar to setting the setuid
bit on an executable file. Commands that are designated with uid run with both the real UID and the
effective UID.
Commands that are designated with egid run with the supplied GID, which is similar to setting the setgid
bit on an executable file. Commands that are designated with gid run with both the real GID and the
effective GID.
13.2. System Messaging

13.2.1. Syslog Function Fundamentals
System messages display on the console device. The text of most system messages look like this:
[ID msgid facility.priority]
For example:
[ID 672855 kern.notice] syncing file systems...
The error logging daemon, syslogd, automatically records various system warnings and errors in message files.
By default, many of these system messages are displayed on the system console and are stored in the /var/adm
directory. You can direct where these messages are stored by setting up system message logging. These
messages can alert you to system problems, such as a device that is about to fail. The /var/adm directory
contains several message files. the /var/adm directory stores large files containing messages, crash dumps, and
other data, this directory can consume lots of disk space. To keep the /var/adm directory from growing too large,
and to ensure that future crash dumps can be saved, you should remove unneeded files periodically. You can
automate this task by using the crontab file.
Messages generated by a system crash or reboot can be viewed using the dmesg command.
$ dmesg
System Log Rotation

System log files are rotated by the logadm command from an entry in the root crontab file. The
/usr/lib/newsyslog script is no longer used. The system log rotation is defined in the /etc/logadm.conf
file. This file includes log rotation entries for processes such as syslogd. For example, one entry in the
/etc/logadm.conf file specifies that the /var/log/syslog file is rotated weekly unless the file is empty. The
most recent syslog file becomes syslog.0, the next most recent becomes syslog.1, and so on. Eight
previous syslog log files are kept. The /etc/logadm.conf file also contains time stamps of when the last log
rotation occurred. You can use the logadm command to customize system logging and to add additional logging
in the /etc/logadm.conf file as needed.
13.2.2. Customizing System Message Logging

You can capture additional error messages that are generated by various system processes by modifying the
/etc/syslog.conf file. The /etc/syslog.conf file has two columns separated by tabs:
The following example shows sample lines from a default /etc/syslog.conf file.
user.err /dev/sysmsg
user.err /var/adm/messages
user.alert root, operator
user.emerg *
This means the following user messages are automatically logged:
User errors are printed to the console and also are logged to the /var/adm/messages file.
User messages requiring immediate action (alert) are sent to the root and operator users.
User emergency messages are sent to individual users.

Priority Levels:
Source Facilities:
Customizing System Message Logging:

Edit the /etc/syslog.conf file according to your requirements and save and exit.

Chapter 14 Naming Services Page 161 of 198
14. Naming Services

14.1. Name Service concept
Naming services store information in a central place, which enables users, machines, and applications to
communicate across the network. This information can include the following.
1. Machine (host) names and addresses
2. User names
3. Passwords
4. Access permissions
5. Group membership, printers, and so on
Without a central naming service, each machine would have to maintain its own copy of this information. Naming
service information can be stored in files, maps, or database tables. If you centralize all data, administration
becomes easier. A network information service enables machines to be identified by common names instead of
numerical addresses. This makes communication simpler because users do not have to remember and try to
enter cumbersome numerical addresses like 192.168.0.0. A network information service stores network
information on a server, which can be queried by any machine. The machines are known as clients of the server.
Whenever information about the network changes, instead of updating each clients local file, an administrator
updates only the information stored by the network information service. Doing so reduces errors, inconsistencies
between clients, and the sheer size of the task. This arrangement, of a server providing centralized services to
clients across a network, is known as client-server computing
14.2. Solaris Naming Services

The Solaris platform provides the following naming services.
1. DNS
2. /etc files, the original UNIX naming system
3. NIS, the Network Information Service
4. NIS+, the Network Information Service Plus
5. LDAP, the Lightweight Directory Access Protocol
Most modern networks use two or more of these services in combination. When more than one service is used,
the services are coordinated by the nsswitch.conf file.
Description of the DNS Naming Service
DNS is the naming service provided by the Internet for TCP/IP networks. DNS was developed so that machines
on the network could be identified with common names instead of Internet addresses. DNS performs naming
between hosts within your local administrative domain and across domain boundaries. The collection of
networked machines that use DNS are referred to as the DNS namespace. The DNS namespace can be divided
into a hierarchy of domains. A DNS domain is a group of machines. Each domain is supported by two or more
name servers, a principal server and one or more secondary servers. Each server implements DNS by running
the in.named daemon. On the clients side, DNS is implemented through the resolver. The resolvers function is
to resolve users queries. The resolver queries a name server, which then returns either the requested information
or a referral to another server.
/etc Files Naming Service
The original host-based UNIX naming system was developed for standalone UNIX machines and then adapted
for network use. Many old UNIX operating systems and machines still use this system, but the system is not well
suited for large complex networks.
NIS Naming Service
The Network Information Service (NIS) was developed independently of DNS. DNS makes communication
simpler by using machine names instead of numerical IP addresses. NIS focuses on making network
administration more manageable by providing centralized control over a variety of network information. NIS stores
information about the network, machine names and addresses, users, and network services. This collection of
network information is referred to as the NIS namespace. NIS namespace information is stored in NIS maps. NIS

maps were designed to replace UNIX /etc files, as well as other configuration files. NIS maps store much more
than names and addresses.
NIS uses a client-server arrangement which is similar to DNS. Replicated NIS servers provide services to NIS
clients. The principal servers are called master servers, and for reliability, the servers have backup, or slave
servers. Both master and slave servers use the NIS retrieval software and both store NIS maps
NIS+ Naming Service
The Network Information Service Plus (NIS+) is similar to NIS but with more features. However, NIS+ is not an
extension of NIS. The NIS+ naming service is designed to conform to the shape of the organization. Unlike NIS,
the NIS+ namespace is dynamic because updates can occur and be put into effect at any time by any authorized
user. NIS+ enables you to store information about machine addresses, security information, mail information,
Ethernet interfaces, and network services in one central location. This configuration of network information is
referred to as the NIS+ namespace. The NIS+ namespace is hierarchical. The NIS+ namespace is similar in
structure to the UNIX directory file system. The hierarchical structure allows an NIS+ namespace to be configured
to conform to the logical hierarchy of an organization. The namespaces layout of information is unrelated to its
physical arrangement. Thus, an NIS+ namespace can be divided into multiple domains that can be administered
autonomously. Clients might have access to information in domains other than their own if the clients have the
appropriate permissions.
NIS+ uses a client-server model to store and have access to the information contained in an NIS+ namespace.
Each domain is supported by a set of servers. The principal server is called the primary server. The backup
servers are called secondary servers. The network information is stored in 16 standard NIS+ tables in an internal
NIS+ database. Both primary and secondary servers run NIS+ server software and both maintain copies of NIS+
tables. Changes made to the NIS+ data on the master server are incrementally propagated automatically to the
secondary servers.
NIS+ includes a sophisticated security system to protect the structure of the namespace and its information. NIS+
uses authentication and authorization to verify whether a clients request for information should be fulfilled.
Authentication determines whether the information requester is a valid user on the network.
Authorization determines whether a particular user is allowed to have or modify the information requested.
LDAP Naming Services
Solaris 10 supports LDAP (Lightweight Directory Access Protocol) in conjunction with the Sun Java System
Directory Server (formerly Sun ONE Directory Server), as well as other LDAP directory servers.
The table above gives a comparative study of the various name services.

14.3. The Name Service Switch

The name service switch is a file which is named, nsswitch.conf. The name service switch controls how a client
machine or application obtains network information. Each machine has a switch file in its /etc directory. Each
line of that file identifies a particular type of network information, such as host, password, and group, followed by
one or more locations of that information. The Solaris system automatically loads an nsswitch.conf file into every
machines /etc directory as part of the installation process. Four alternate (template) versions of the switch file
are also loaded into /etc for LDAP, NIS, NIS+, or files. No default file is provided for DNS, but you can edit any of
these files to use DNS.
Format of the nsswitch.conf File
The nsswitch.conf file is essentially a list of 16 types of information
Default Search Criteria
The combination of nsswitch.conf file status message and action option determines what the routine does at each
step. The combination of status and action make up the search criteria.
The switchs default search criteria are the same for every source. As described in terms of the status messages
listed above, see the following.
SUCCESS=return. Stop looking for the information. Proceed using the information that has been found.
UNAVAIL=continue. Go to the next nsswitch.conf file source and continue searching. If this source is the last or
only source, return with a NOTFOUND status.
NOTFOUND=continue. Go to the next nsswitch.conf file source and continue searching. If this source is the last
or only source, return with a NOTFOUND status.
TRYAGAIN=continue. Go to the next nsswitch.conf file source and continue searching. If this source is the last or
only source, return with a NOTFOUND status. Nondefault criteria are delimited by square brackets.
For example,
The networks: nis [NOTFOUND=return] files line specifies a nondefault criterion for the NOTFOUND status.
Nondefault criteria are delimited by square brackets.
In this example, the search routine behaves as follows:
1. If the networks map is available, and contains the needed information, the routine returns with a
SUCCESS status message.
2. If the networks map is not available, the routine returns with an UNAVAIL status message. By default, the
routine continues to search the appropriate /etc file.
3. If the networks map is available and found, but the map does not contain the needed information, the
routine returns with a NOTFOUND message. But, instead of continuing on to search the appropriate
/etc file, which would be the default behavior, the routine stops searching.
4. If the networks map is busy, the routine returns with a TRYAGAIN status message and by default
continues on to search the appropriate /etc file.
The nscd daemon caches switch information.
Some library routines do not periodically check the nsswitch.conf file to see whether the file has been changed.
You must reboot the machine to make sure that the daemon and those routines have the latest information in the
file.
Maintaining multiple repositories for the same user is not recommended. By maintaining centralized password
management in a single repository for each user, you reduce the possibilities of confusion and error. If you
choose to maintain multiple repositories per user, update password information by using the passwd r
command.
passwd -r repository
If no repository is specified with the -r option, passwd updates the repositories listed in nsswitch.conf in reverse
order.

14.4. Domain Name Service

DNS is the name service used on the Internet. Lets understand the jargon of DNS.
Domains
DNS allows hierarchal domains. It uses the domainname to describe a generic ownership of the hosts.
Root Domain
In DNS the domain name space is very similar to the UNIX file system. One domain at the root of the name space
contains all other domains. Known as the root domain, this domain is usually written as a single dot (.) at the end
of the domain name.
(Root Level)
us arpa com edu gov mil net org in (Top Level )
Top Level Domains

DNS defines several top level domains. These domains are global in nature. For example, some common top
level domains are edu, com, net, org, gov and mil. The names of these top level domains make an attempt to
describe the type of organizations they contain.
Under each top-level domain there may be any number of sub-domains. Under each of these second-level
domains there may be other sub-domains.
(When the Internet was first put into operation, it only served hosts and organizations within the United States.
Over time the Internet expanded to locations outside the United States. The International Standards Organization
(ISO) developed a series of standard two-letter country codes. These two letter domains were inserted under the
root domain, with special provisions that the existing US top-level domains could remain unchanged.
Locations outside the US sub-divide their top-level domain in a manner similar to the US top-level domains.)
Traversing the domain tree
Domain names read from left to right, where the left-most component of the name is the furthest point from the
root of the name space. For example, the consider a fictious name alice.wonderland.carroll.org might describe a
host located in wonderland in the carroll domain under the org top-level domain. To be precise, there should be a
dot at the end of any domain/host name (e.g., alice.wonderland.carroll.org.). The dot signifies that the domain is
fully qualified all the way to the root domain. When the trailing dot is left off the name, the name is said to be
partially qualified.
DNS Servers
Under DNS, name servers are programs that store information about domain namespace. A name server
maintains database files that contain the master information for a domain. The client machines within the domain
are configured in such a way that they will query the local name server when name to address mapping is
required.
External hosts take a slightly different approach to resolution of name to address mappings. The remote host will
query its local name server to get the name to address mapping. The local name server may not have the
information required, so it queries another name server in an attempt to resolve the query. This (often recursive)
process will continue until the local name server gets a valid mapping (query is resolved), or until appropriate
name servers have been queried and failed to return the requested information (host not found).
Primary Name Servers
The primary name server obtains information about the domain from disk files contained on the name server host.
The domain may actually have several primary name servers in an attempt to spread the work load around and
provide better service.
Secondary Name Servers

Each domain can also define a number of secondary name servers. The secondary name servers obtain their
databases from the primary name servers through a process called zone transfer. These secondary name
servers are queried in the event the primary name server(s) do not respond to a query.
Caching Name Server
Caching name servers have no direct access to any authoritative information about the domain. These name
servers query primary and secondary name servers with DNS requests, and store the results away in a memory
cache for future reference. When these servers spot a DNS look-up request on the network, they reply with the
information they have stored in their respective caches. Caching name servers usually contain valid data, but
because they dont load information directly from primary name servers, the data can become stale. Caching
name servers are not considered authoritative name servers.
Root Name Servers
In order to provide a master list of name servers available on the Internet, the Network Information Center (NIC)
maintains a group of root name servers. These name servers provide authoritative information about specific top
level domains. When a local name server cannot resolve an address, it queries the root name server for the
appropriate domain for information which may allow the local name server to resolve the address.
DNS Clients
DNS clients comprise a series of library calls, which issue RPC requests to a DNS server. These library routines
are referred to as resolver code. Whenever a system requires a name to IP address mapping, the system
software executes a gethostbyname () library call. The resolver code contacts the appropriate name service
daemon to resolve the query.
/etc/resolv.conf File
In order to make DNS operate, the administrator must configure the /etc/resolv.conf file on each host. This
file tells the name service resolution routines where to find DNS information. The format of the entries in the
/etc/resolv.conf file is keyword value.
nameserver: Valid values for name servers are IP addresses in standard dot notation.
domain: The domain value will be appended to any hostname which doesnt end in a dot. If a user types telnet
alice, the resolver will automatically append .wonderland.carroll.org to the request such that the telnet session will
actually be issued as telnet alice.wonderland.carroll.org.
DNS Database Files
The DNS service consults a series of database files in order to resolve name service queries. Such database files
are often called as db files. In order to provide scalability and modularity, the database information is split into
several files as described below:
1. named.hosts This provides the hostname to IP address mapping for the hosts within the domain name.
2. named.rev This database provides the IP address to hostname mapping (reverse mapping) for the
hosts on network address.
Name Service Resource Records

The information stored in the database files is organised into resource records, and the format of these records is
determined by the DNS design specifications.
The different types of records are:

Comment Records
SOA (Start of Authority) Records
NS (Name Server) Records
A (Address) Records
PTR (Pointer) Records
MX (Mail Exchanger) Records
CNAME (Canonical name) Records
TXT (Text) Records
RP (Responsible Person) Records
Comment Records

DNS provides a method for embedding comments in the db files. It begins with a semicolon (;). Comments are
needed in an attempt to explain the local site setup.
SOA Records
This provides information about management of data within the domain. The SOA record must start in column 1.
The format is shown below:
domain class SOA primary_server rp (
serial_number
refresh_value
retry_value
expiration_value
TTL)
The domain field is the domain name.
The class field allows the administrator to define the class of data. Currently, only one class is used. The IN class
defines Internet data.
SOA field tells the resolver that this is a start of authority record for domain.
The primary server field is the fully qualified host name of the primary name server for this domain.
The rp field gives the fully qualified email address of the person responsible for this domain
The serial number field is used by the secondary name servers. This field is a counter which gives the version
number for the file. This number should be incremented every time the file is altered. When the information stored
on the secondary name servers expires, the servers contact the primary name server to obtain new information. If
the serial number of the information obtained from the primary server is larger than the serial number of the
current information, a full zone transfer is performed. If the serial number from the primary name server is smaller
than the current information, the secondary name server discards the information from the primary name server.
The refresh_value field is used by the secondary name servers. The value in this field tells the secondary servers
how long (in seconds) to keep the data before they obtain a new copy from the primary name server. If the value
is too small, the name server may overload the network with zone transfers. If the value is too large, information
may become stagnant and changes may not propagate efficiently from the primary to the secondary name
servers.
The retry_value field is used by the secondary name servers. The value in this field tells the secondary servers
how long (in seconds) to wait before attempting to contact a non-responsive primary name server.
The expiration_value field is used by the secondary name servers. The value in this field tells the secondary
servers to expire their information after value seconds. Once the secondary server expires its data, it stops
responding to name service requests.
The TTL field tells name servers how long they can cache the response from the name server before they purge
(discard) the information obtained in response to a query. Example:
wonder.com. IN SOA alice.wonder.com. root.alice.wonder.com. (
2005111401 ; serial format YYYYMMDD##
10800 ; Refresh every 3 hours
3600 ; Retry after an hour
604800 ; Expire data after 1 week
86400 ) ; TTL for cached data is 1 day
NS Records
The NS records define the name servers within a domain. The NS record starts in column 1 of the file. The format
of an NS record follows: domain class NS fully_qualified_hostname. An example appears below.
wonder.com. IN NS alice.wonder.com.
A Records

The A (Address) records provide the information used to map host names to IP addresses. The A record must
begin in column 1 of the file. The format of an A record is fully_qualified_hostname class A address. Example:
alice.wonder.com. IN A 200.200.0.1
PTR Records
The pointer records provide the information for reverse mapping (looking up a host name from an IP address).
The PTR record must begin in column1 of the file. The format of the PTR record is address class PTR
fully_qualified_hostname. The PTR record does have one quirk: the address portion appears to be written
backwards, and contains information the user typically doesnt see. The information is presented in this format in
order to simplify the look-up procedure, and to maintain the premise that the information at the left of the record is
furthest from the root of the domain.
Ex: 1.0.200.200.in-addr.arpa. IN PTR alice.wonder.com.
MX Records
The mail exchanger records provide a way for remote hosts to determine where e-mail should be delivered for a
domain. The MX records must begin in column 1 of the db files. The format of MX records is
fully_qualified_hostname class MX preference fully_qualified_mail_hostname.
There should be an MX record for each host within a domain. The preference field tells the remote host the
preferred place to deliver the mail for the domain. This allows e-mail to be delivered in the event that the primary
mail server is down. The remote host will try to deliver e-mail to the host with the lowest preference value first. If
that fails, the remote host will attempt to deliver the e-mail to the host with the next lowest preference value.
Examples appear below:
alice.wonder.com. IN MX mail.wonder.com.
CNAME Records
The CNAME records provide a way to alias host names.
TXT Records
The TXT records allow the administrator to add text information to the db files giving more information about the
domain. The TXT records must start in column 1 of the db file, and the format of TXT records is hostname class
TXT Random text about hostname in this domain.
alice IN TXT Machine Alice is in Wonderland
RP Records
These records define the person responsible for the domain. The RP records must start in column 1 of the db
files. The format of an RP record is hostname class RP fully_qualified_email_address fully_qualified_hostname.
alice IN user1.alice.wonder.com. queen.wonder.com.
queen IN TXT The Responsible Person
Configuring DNS
The Solaris 10 operating system ships with the BIND 9.x DNS name server. The DNS/BIND named service can
be managed by using the Sevice Management Facility (SMF).
Tip Temporarily disabling a service by using the -t option provides some protection for the service configuration.
If the service is disabled with the t option, the original settings would be restored for the service after a reboot. If
the service is disabled without -t, the service will remain disabled after reboot.
The Fault Managed Resource Identifiers (FMRIs) for the DNS service are
svc:/network/dns/server:<instance> and
svc:/network/dns/client:<instance>.
If you need to start the DNS service with different options (for example with a configuration file other than
/etc/named.conf), change the start method property of the DNS server manifest by using the svccfg command.
Multiple SMF service instances are only needed if you want to run multiple copies of BIND 9 name service. Each
additional instance can be specified in the DNS server manifest with a different start method. While it is
recommended that you use svcadm to administer the server, you can use rndc as well. SMF is aware of the state
change of the BIND 9 named service, whether administered by using svcadm or rndc.

Note SMF will not be aware of the BIND 9 named service if the service is manually executed from the command
line.
DNS Server Configuration

# vi /etc/defaultdomain
wil.com
Save and exit
# domainname wil.com
# mkdir /var/named
# cd /var/named
# vi named.hosts
wil.com. IN SOA wstsun1.wil.com. root.wstsun1.wil.com. (
2005111401
10800
3600
604800
86400 )
wil.com. IN NS wstsun1.wil.com.
wstsun1 IN A 200.200.0.1
wstsun2 IN A 200.200.0.2
wstsun3 IN A 200.200.0.3
And save and exit
# vi named.rev
0.200.200.in-addr.arpa. IN SOA wstsun1.wil.com. root.wstsun1.wil.com. (
2005111401
10800
3600
604800
86400 )
0.200.200.in-addr.arpa. IN NS wstsun1.wil.com.
1 IN PTR wstsun1
2 IN PTR wstsun2
3 IN PTR wstsun3
# cd /etc
# vi named.conf
options {
directory /var/named ;
};
zone wil.com {
type master;
file named.hosts ;
};
zone 0.200.200.in-addr.arpa {
type master;
file named.rev;
}
};
# svcadm enable \*dns\*
DNS Client Configuration

# vi /etc/nsswitch.conf
hosts dns files
Save and exit

# vi /etc/resolv.conf
domain wil.com
nameserver 200.200.0.1
Save and exit
# svcadm restart \*dns\*
# nslookup
>
14.5. Network Information Service

NIS Fundamentals
By running NIS, the system administrator can distribute administrative databases, called maps, among a variety
of servers (master and slaves). The administrator can update those databases from a centralized location in an
automatic and reliable fashion to ensure that all clients share the same naming service information in a consistent
manner throughout the network. NIS was developed independently of DNS and has a slightly different focus.
Whereas DNS focuses on making communication simpler by using machine names instead of numerical IP
addresses, NIS focuses on making network administration more manageable by providing centralized control over
a variety of network information. NIS stores information not only about machine names and addresses, but also
about users, the network itself, and network services. This collection of network information is referred to as the
NIS namespace.
NIS Architecture
NIS uses a client-server arrangement. NIS servers provide services to NIS clients. The principal servers are
called master servers, and for reliability, they have backup, or slave servers. Both master and slave servers use
the NIS information retrieval software and both store NIS maps. NIS uses domains to arrange the machines,
users, and networks in its namespace. However, it does not use a domain hierarchy; an NIS namespace is flat.
An NIS domain cannot be connected directly to the Internet using just NIS. However, organizations that want to
use NIS and also be connected to the Internet can combine NIS with DNS.
NIS Machine Types
There are three types of NIS machines.
1. Master server
2. Slave servers
3. Clients of NIS servers
Any machine can be an NIS client, but only machines with disks should be NIS servers, either master or slave.
Servers are also clients, typically of themselves.
NIS Servers
The NIS server does not have to be the same machine as the NFS file server. NIS servers come in two varieties,
master and slave. The machine designated as master server contains the set of maps that the system
administrator creates and updates as necessary. Each NIS domain must have one, and only one, master server,
which can propagate NIS updates with the least performance degradation. You can designate additional NIS
servers in the domain as slave servers. A slave server has a complete copy of the master set of NIS maps.
Whenever the master server maps are updated, the updates are propagated among the slave servers. Slave
servers can handle any overflow of requests from the master server, minimizing server unavailable errors.
NIS Clients
NIS clients run processes that request data from maps on the servers. Clients do not make a distinction between
master and slave servers, since all NIS servers should have the same information.
NIS Elements
The NIS naming service is composed of the following elements:
1. Domains
2. Daemons
3. Utilities
4. Maps

5. NIS Command Set

NIS Domain
An NIS domain is a collection of machines which share a common set of NIS maps.
NIS Daemons
NIS service is provided by five daemons. The NIS service is managed by the Service Management Facility.
NIS Daemon Summary
NIS Utilities
NIS MAPS
NIS maps were designed to replace UNIX /etc files, as well as other configuration files, so they store much more
than names and addresses. On a network running NIS, the NIS master server for each NIS domain maintains a
set of NIS maps for other machines in the domain to query. NIS slave servers also maintain duplicates of the
master servers maps. NIS client machines can obtain namespace information from either master or slave
servers. NIS maps are essentially two-column tables. One column is the key and the other column is information
related to the key. NIS finds information for a client by searching through the keys.
NIS and the Service Management Facility:
The NIS Fault Managed Resource Identifiers (FMRIs) are
svc:/network/nis/server:<instance> for the NIS server and
svc:/network/nis/client:<instance> for the NIS client.
Preparing the Master Server Involves

1. Preparing Source Files for Conversion to NIS Maps
2. Check the source files on the master server to make sure they reflect an up-to-date picture of your
system.

3. Copy all of these source files, except passwd, to the DIR directory that you have selected.
4. Copy the passwd file to the PWDIR directory that you have selected.
5. Preparing the Makefile
NOTE
Source Files Directory

The source files should be located in the /etc directory, on the master server or in some other directory. Having
them in /etc is undesirable because the contents of the maps are then the same as the contents of the local files
on the master server. This is a special problem for passwd and shadow files because all users have access to the
master server maps and the root password would be passed to all NIS clients through the passwd map. However,
if you put the source files in some other directory, you must modify the Makefile in /var/yp by changing the
DIR=/etc line to DIR=/your-choice, where your-choice is the name of the directory you will be using to store
the source files. This allows you to treat the local files on the server as if they were those of a client. (It is good
practice to first save a copy of the original Makefile.)
After checking the source files and copying them into the source file directory, you now need to convert those
source files into the ndbm format maps that the NIS service uses. This is done automatically for you by ypinit
when called on the master server. The ypinit script calls the program make, which uses the Makefile located
in the /var/yp directory. A default Makefile is provided for you in the /var/yp directory and contains the
commands needed to transform the source files into the desired ndbm format maps.
The function of the Makefile is to create the appropriate NIS maps for each of the databases listed under all.
After passing through makedbm the data is collected in two files, mapname.dir and mapname.pag. Both files
are in the /var/yp/domainname directory on the master server. The Makefile builds passwd maps from the
/PWDIR/passwd, /PWDIR/shadow, and /PWDIR/security/passwd.adjunct files, as appropriate.
Setting Up the Master Server
The ypinit script sets up master and slave servers and clients to use NIS. It also initially runs make to create
the maps on the master server.
Copy the contents of the nsswitch.files file to the nsswitch.conf file.
# cp /etc/nsswitch.files /etc/nsswitch.conf
Edit the /etc/hosts or /etc/inet/ipnodes file to add the name and IP address of each of the NIS servers.
Build new maps on the master server.
# /usr/sbin/ypinit -m
When ypinit prompts for a list of other machines to become NIS slave servers, type the name of the server you
are working on, along with the names of your NIS slave servers.
When ypinit asks whether you want the procedure to terminate at the first nonfatal error or continue despite
nonfatal errors, type y.
Note A nonfatal error can appear when some of the map files are not present. This is not an error that affects
the functionality of NIS. You might need to add maps manually if they were not created automatically.
ypinit asks whether the existing files in the /var/yp/domainname directory can be destroyed.
This message is displayed only if NIS has been previously installed.
After ypinit has constructed the list of servers, it invokes make.
This program uses the instructions contained in the Makefile (either the default one or the one you modified)
located in /var/yp. The make command cleans any remaining comment lines from the files you designated. It
also runs makedbm on the files, creating the appropriate maps and establishing the name of the master server for
each map.
If the map or maps being pushed by the Makefile correspond to a domain other than the one returned by the
command domainname on the master, you can make sure that they are pushed to the correct domain by starting
make in the ypinit shell script with a proper identification of the variable DOM, as follows:
# make DOM=domainname password
This pushes the password map to the intended domain, instead of the domain to which the master belongs.

To enable NIS as the naming service, type the following.

# cp /etc/nsswitch.nis /etc/nsswitch.conf
This replaces the current switch file with the default NIS-oriented switch file. You can edit this file as necessary.
Starting and Stopping NIS Service on the Master Server
Now that the master maps are created, you can start the NIS daemons on the master server and begin service.
When you enable the NIS service, ypserv and ypbind start on the server. When a client requests information from
the server, ypserv is the daemon that answers information requests from clients after looking them up in the NIS
maps. The ypserv and ypbind daemons are administered as a unit.
There are three ways that NIS service can be started or stopped on a server:
1. automatically invoking the /usr/lib/netsvc/yp/ypstart script during the boot process
2. using the Service Management Facility
3. using the ypstart(1M) and ypstop(1M) commands from the command line
Setting Up NIS Slave Servers

Your network can have one or more slave servers. Having slave servers ensures the continuity of NIS services
when the master server is not available.
Preparing a Slave Server
Before actually running ypinit to create the slave servers, you should run the domainname command on each NIS
slave to make sure the domain name is consistent with the master server.
Note Domain names are case-sensitive.
Make sure that the network is working properly before you configure an NIS slave server. In particular, check to
be sure you can use rcp to send files from the master NIS server to NIS slaves.
The following procedure shows how to set up a slave server.
Edit the /etc/hosts or /etc/inet/ipnodes file on the slave server to add the name and IP addresses of all
the other NIS servers.
Change directory to /var/yp on the slave server.
Note You must first configure the new slave server as an NIS client so that it can get the NIS maps from the
master for the first time.
Initialize the slave server as a client.
# /usr/sbin/ypinit -c
The ypinit command prompts you for a list of NIS servers. Enter the name of the local slave you are working on
first, then the master server, followed by the other NIS slave servers in your domain in order from the physically
closest to the furthest in network terms.
Determine if the NIS client is running, then start the client service as needed.
# svcs network/nis/client
STATE STIME FMRI
online 20:32:56 svc:/network/nis/client:default
If svc:/network/nis/client is displayed with an online state, then NIS is running. If the service state is
disabled, then NIS is not running.
a. If the NIS client is running, restart the client service.
# svcadm restart network/nis/client
b. If the NIS client is not running, start the client service.
# svcadm enable network/nis/client
c. Initialize this machine as a slave.
# /usr/sbin/ypinit -s master

Where master is the machine name of the existing NIS master server.
Repeat the procedures described in this section for each machine you want configured as an NIS slave server.
The following procedure shows how to start NIS on a slave server.
Stop the client service and start all NIS server processes.
# svcadm disable network/nis/client
# svcadm enable network/nis/server
Setting Up NIS Clients

The two methods for configuring a client machine to use NIS as its naming service are explained below.
The recommended method for configuring a client machine to use NIS is to login to the machine as root and run
ypinit -c.
# ypinit -c
You will be asked to name NIS servers from which the client obtains naming service information. You can list as
many master or slave servers as you want. The servers that you list can be located anywhere in the domain. It is
a better practice to first list the servers closest (in network terms) to the machine, than those that are on more
distant parts of the net.
Broadcast method. An older method of configuring a client machine to use NIS to log in to the machine as root,
set the domain name with the domainname command, then run ypbind. ypstart will automatically invoke the NIS
client in broadcast mode (ypbind -broadcast), if the /var/yp/binding/domainname/ypservers file does not exist.
# domainname doc.com
# mv /var/yp/binding/domainname/ypservers /var/yp/binding/domainname
/ypservers.bak
# ypstart
When you run ypbind, it searches the local subnet for an NIS server. If it finds a subnet, ypbind binds to it. This
search is referred to as broadcasting. If there is no NIS server on the clients local subnet, ypbind fails to bind
and the client machine is not able to obtain namespace data from the NIS service.

Chapter 15 Advanced Installations Page 174 of 198
15. Advanced Installations

15.1. Solaris Containers
A Solaris Container is a complete runtime environment for applications. Solaris 10 Resource Manager and Solaris
Zones software partitioning technology are both parts of the container.
15.1.1. Resource Management

Resource Manager enables us to control how applications use available system resources. Using the Resource
Manager, we can
1. Allocate computing resources, such as processor time
2. Monitor how the allocations are being used, then adjust the allocations as necessary
3. Generate extended accounting information for analysis, billing, and capacity planning
A workload is an aggregation of all processes of an application or group of applications.
If resource management features are not used, the Solaris Operating System responds to workload demands by
adapting to new application requests dynamically. By using the Resource Manager we can perform resource
allocation at the application level. We can,
1. Restrict access to a specific resource
2. Offer resources to workloads on a preferential basis
3. Isolate workloads from each another
Resource management is implemented through a collection of algorithms. The algorithms handle the series of
capability requests that an application presents in the course of its execution.
15.1.2. Solaris Zones

A growing number of users are interested in improving the utilization of their computing resources through
consolidation and aggregation. Consolidation is already common in mainframe environments, where technology
to support running multiple applications and even operating systems on the same hardware has been in
development since the late 1960s. Such technology is now becoming an important differentiator in other markets
(such as Unix/Linux servers), both at the low end (virtual web hosting) and high end (traditional data center server
consolidation).
Zones are a new operating system abstraction for partitioning systems, allowing multiple applications to run in
isolation from each other on the same physical hardware. This isolation prevents processes running within a zone
from monitoring or affecting processes running in other zones, seeing each others data, or manipulating the
underlying hardware. Zones also provide an abstraction layer that separates applications from physical attributes
of the machine on which they are deployed, such as physical device paths and network interface names.
Much of the previous work in this area has involved running multiple operating system instances on a single
system, either through the use of hardware partitioning [IBMs lpar] or virtual machine monitors. Hardware
partitioning, while providing a very high degree of application isolation, is costly to implement and is generally
limited to high-end systems. In addition, the granularity of resource allocation is often poor, particularly in the area
of CPU assignment. Virtual machine implementations can be much more granular in how resources are allocated
(even time-sharing multiple VMs on a single CPU), but suffer significant performance overheads. With either
approach, the cost of administering multiple operating system instances can be substantial.
More recently, a number of projects have explored the idea of virtualizing the operating system environment,
rather than the physical hardware. These efforts differ from virtual machine implementations in that there is only
one underlying operating system kernel, which is enhanced to provide increased isolation between groups of
processes. The result is the ability to run multiple applications in isolation from each other within a single
operating system instance.
Zones build on this concept by extending this virtual operating system environment to include many of the
features of a separate machine, such as a perzone console, system log, packaging database, run level, identity
(including name services), and interprocess communication facility. For example, each zone has a virtualized
view of the process table (as reflected in the /proc file system) that reflects only the processes running in that
zone, as well as a virtualized /etc/mnttab file that shows only file system mounts within the zone.

A set of administrative tools have been developed to manage zones, allowing them to be configured, installed,
patched, upgraded, booted, rebooted, and halted. As a result, zones can be administered in a manner very similar
to separate machines. In fact, some types of administration are significantly easier; for example, an administrator
can apply a patch to every zone on a system with a single command.
A zone can either be bound to a dedicated pool of resources (such as a number of CPUs or a quantity of physical
memory), or can share resources with other zones according to defined proportions. This allows the use of zones
both on large systems (where dedicated resources may be most appropriate) and smaller ones (where a greater
degree of sharing is necessary). It also allows administrators to make appropriate tradeoffs depending on the
relative importance of resource isolation versus utilization.
Zones provide for the delegation of many of the expected administrative controls for the virtual operating system
environment. Since each zone has its own name service identity, it also has its own notion of a password file and
its own root user. The proportion of CPU resources that a zone can consume can be defined by an administator,
and then that share can be further divided among workloads running in the zone by the (potentially different) zone
administrator. In addition, the privileges available within a zone (even to the root user) are restricted to those that
can only affect the zone itself. As a result, even if a zone is compromised by an intruder, the compromise will not
affect other zones in the system or the system as a whole.
Zones also allow sharing of file system data, particularly read-only data such as executables and libraries.
Portions of the file system can be shared between all zones in the system through use of the read-only loopback
file system (or lofs), which allows a directory and its contents to be spliced into another part of the file system.
This not only substantially reduces the amount of disk space used by each zone, but reduces the time to install
zones and apply patches, and allows for greater sharing of text pages in the virtual memory system.
NOTE: Zones are part of the N1 Grid Containers feature in Solaris 10 and the container technology is still under
development.
The Solaris Zones partitioning technology is used to virtualize operating system services and provide an isolated
and secure environment for running applications. A zone is a virtualized operating system environment created
within a single instance of the Solaris Operating System. When you create a zone, you produce an application
execution environment in which processes are isolated from the rest of the system. This isolation prevents
processes that are running in one zone from monitoring or affecting processes that are running in other zones.
Even a process running with superuser credentials cannot view or affect activity in other zones.
A zone also provides an abstract layer that separates applications from the physical attributes of the machine on
which they are deployed. Examples of these attributes include physical device paths. Zones can be used on any
machine that is running the Solaris 10 release. The upper limit for the number of zones on a system is 8192. The
number of zones that can be effectively hosted on a single system is determined by the total resource
requirements of the application software running in all of the zones.
There are two types of non-global zone root file system models: sparse and whole root. The sparse root zone
model optimizes the sharing of objects. The whole root zone model provides the maximum configurability.
When to Use Zones

Zones are ideal for environments that consolidate a number of applications on a single server. The cost and
complexity of managing numerous machines make it advantageous to consolidate several applications on larger,
more scalable servers. Zones enable more efficient resource utilization on your system. Dynamic resource
reallocation permits unused resources to be shifted to other containers as needed. Fault and security isolation
mean that poorly behaved applications do not require a dedicated and underutilized system. With the use of
zones, these applications can be consolidated with other applications. Zones allow you to delegate some
administrative functions while maintaining overall system security.
How Zones Work
A non-global zone can be thought of as a box. One or more applications can run in this box without interacting
with the rest of the system. Solaris zones isolate software applications or services by using flexible, software-
defined boundaries. Applications that are running in the same instance of the Solaris Operating System can then
be managed independently of one other. Thus, different versions of the same application can be run in different
zones, to match the requirements of your configuration.
Each zone that requires network connectivity has one or more dedicated IP addresses. A process assigned to a
zone can manipulate, monitor, and directly communicate with other processes that are assigned to the same
zone. The process cannot perform these functions with processes that are assigned to other zones in the system
or with processes that are not assigned to a zone. Processes that are assigned to different zones are only able to
communicate through network APIs.

Every Solaris system contains a global zone. The global zone has a dual function. The global zone is both the
default zone for the system and the zone used for system-wide administrative control. All processes run in the
global zone if no non-global zones, referred to simply as zones, are created by the global administrator.
The global zone is the only zone from which a non-global zone can be configured, installed, managed, or
uninstalled. Only the global zone is bootable from the system hardware. Administration of the system
infrastructure, such as physical devices, routing, or dynamic reconfiguration (DR), is only possible in the global
zone. Appropriately privileged processes running in the global zone can access objects associated with other
zones.
Unprivileged processes in the global zone might be able to perform operations not allowed to privileged
processes in a non-global zone. For example, users in the global zone can view information about every process
in the system. If this capability presents a problem for your site, you can restrict access to the global zone.
Each zone, including the global zone, is assigned a zone name. The global zone always has the name global.
Each zone is also given a unique numeric identifier, which is assigned by the system when the zone is booted.
The global zone is always mapped to ID 0. Each zone also has a node name that is completely independent of
the zone name. The node name is assigned by the administrator of the zone. Each zone has a path to its root
directory that is relative to the global zones root directory. The scheduling class for a non-global zone is set to the
scheduling class for the system.
You can also set the scheduling class for a zone through the dynamic resource pools facility. If the zone is
associated with a pool that has its pool.scheduler property set to a valid scheduling class, then processes running
in the zone run in that scheduling class by default.
Features Summary:

15.2. Custom JumpStart Introduction

The custom JumpStart installation method is a commandline interface that enables you to automatically install or
upgrade several systems, based on profiles that you create. The profiles define specific software installation
requirements. You can also incorporate shell scripts to include preinstallation and postinstallation tasks. You
choose which profile and scripts to use for installation or upgrade. The custom JumpStart installation method
installs or upgrades the system, based on the profile and scripts that you select. Also, you can use a sysidcfg file
to specify configuration information so that the custom JumpStart installation is completely hands-off.
Custom JumpStart Example Scenario
The custom JumpStart process can be described by using an example scenario. In this example scenario, the
systems need to be set up with the following parameters:
Install Solaris on 100 new systems.

Seventy of the systems are SPARC based systems that are owned by the engineering group and need to be
installed as standalone systems with the Solaris OS software group for developers. The remaining 30 systems
are x86 based, owned by the marketing group and need to be installed as standalone systems with the Solaris
OS software group for end users.
First, the system administrator must create a rules file and a profile for each group of systems. The rules file is a
text file that contains a rule for each group of systems or single systems on which you want to install the Solaris
software. Each rule distinguishes a group of systems that are based on one or more system attributes. Each rule
also links each group to a profile. A profile is a text file that defines how the Solaris software is to be installed on
each system in the group. Both the rules file and profile must be located in a JumpStart directory. For the example
scenario, the system administrator creates a rules file that contains two different rules, one for the engineering
group and another for the marketing group. For each rule, the systems network number is used to distinguish the
engineering group from the marketing group. Each rule also contains a link to an appropriate profile. For example,
in the rule for the engineering group, a link is added to the profile, eng_profile, which was created for the
engineering group. In the rule for the marketing group, a link is added to the profile, market_profile, which was
created for the marketing group. You can save the rules file and the profiles on a diskette or on a server.
1. A profile diskette is required when you want to perform custom JumpStart installations on nonnetworked,
standalone systems.
2. A profile server is used when you want to perform custom JumpStart installations on networked systems
that have access to a server. After creating the rules file and profiles validate the files with the check
script. If the check script runs successfully, the rules.ok file is created. The rules.ok is a generated version
of the rules file that the JumpStart program uses to install the Solaris software.
How the JumpStart Program Installs Solaris Software

After you validate the rules file and the profiles, you can begin a custom JumpStart installation. The JumpStart
program reads the rules.ok file. Then, the JumpStart program searches for the first rule with defined system
attributes that match the system on which the JumpStart program is attempting to install the Solaris software. If a
match occurs, the JumpStart program uses the profile that is specified in the rule to install the Solaris software on
the system.
Figure 151 illustrates how a custom JumpStart installation works with more than one system on a network.
Previously, the system administrator set up different profiles and saved the profiles on a single server. The
system administrator initiates the custom JumpStart installation on one of the engineering systems. The
JumpStart program accesses the rules files in the JumpStart/ directory on the server. The JumpStart program
matches the engineering system to rule 1. rule 1 specifies that the JumpStart program use Engineering Groups
Profile to install the Solaris software. The JumpStart program reads Engineering Groups Profile and installs the
Solaris software, based on the instructions that the system administrator specified in Engineering Groups Profile.

Fig 15-1
15.3. Solaris Flash Introduction

The Solaris Flash installation feature enables you to use a single reference installation of the Solaris OS on a
system, which is called the master system. Then, you can replicate that installation on a number of systems,
which are called clone systems. You can replicate clone systems with a Solaris Flash initial installation that
overwrites all files on the system or with a Solaris Flash update that only includes the differences between two
system images. A differential update changes only the files that are specified and is restricted to systems that
contain software consistent with the old master image.
Installing Clone Systems with an Initial Installation
You can install a master system with a Solaris Flash archive for an initial installation by using any installation
method: Solaris installation program, custom JumpStart, Solaris Live Upgrade, or WAN boot. All files are
overwritten. The Solaris Flash installation is a five-part process.
1. Install the master system. You select a system and use any of the Solaris installation methods to install
the Solaris OS and any other software.
2. (Optional) Prepare customization scripts to reconfigure or customize the clone system before or after
installation.
3. Create the Solaris Flash archive. The Solaris Flash archive contains a copy of all of the files on the
master system, unless you excluded some nonessential files.

4. Install the Solaris Flash archive on clone systems. The master system and the clone system must have
the same kernel architecture. When you install the Solaris Flash archive on a system, all of the files in the
archive are copied to that system. The newly installed system now has the same installation configuration
as the original master system, thus the system is called a clone system. Some customization is possible:
Scripts can be used for customization.
You can install extra packages with a Solaris Flash archive by using the custom JumpStart installation
method. The packages must be from outside the software group being installed or a third-party package.
5. (Optional) Save a copy of the master image. If you plan to create a differential archive, the master image
must be available and identical to the image installed on the clone systems.
Figure below shows an installation of clone systems with an initial installation. All files are overwritten.

Chapter 16 Performance Tuning Page 180 of 194
16. Performance Tuning

Getting good performance from a computer a network is an important part of system administration. This chapter
is an overview of some of the factors that contribute to maintaining and managing the performance of
the computer systems in your care.
Scheduler Activation
Scheduler activation provides kernel scheduling support for applications with particular scheduling needs, such as
database and multithreaded applications. Multithreaded support changes for scheduler activation are
implemented as a private interface between the kernel and the libthread library, without changing the
libthread interface. Additionally, applications may give scheduling hints to the kernel to improve
performance.
The psrset Command
Another new feature allows a group of processors to be for the exclusive use of one or more applications. The
/usr/sbin/psrset command gives a system administrator control over the creation and management of processor
sets.
UFS Direct Input/Output (I/O)
Direct I/O is intended to boost I/O operations user large buffer sizes to transfer larger files (files larger than
physical memory).
An example of a bulk I/O operation is downloading satellite data, which writes large amounts of data to a file.
Direct I/O data is read or written into memory without using the overhead of the operating systems page caching
mechanism.
There is a potential penalty on direct I/O startup. If a file requested for I/O is already mapped by another
application, the pages will have to be flushed out of memory before the direct I/O operation can begin. Direct I/O
can also be enabled on a file system by using the forcedirectio option to the mount command. Enabling direct I/O
is a performance benefit only when a file system is tranferring large amounts of sequential data. When a file
system is mounted with this option; data is transferred directly between a users address space and the disk.
When forced direct I/O is not enabled for a file system, data transferred between a users address space and the
disk is first buffered in the kernel address space.
How to Enable Forced Direct I/O on a UFS File System
Become Superuser. Mount a file system with the forcedirectio mount option.
# mount F ufs o forcedirectio /dev/dsk/c0d0s7 /mnt
Verify the mounted file system has forced direct I/O enabled
# mount
/export/home on /dev/dsk/c0d0s7 fordirectio /setuid/read/write/largefiles on
Mon May 12 13:47:55 1998
The /proc File System
The previous flat /proc file system has been restructured into a directory hierarchy that contains additional sub-
directories for state information and control functions. It also provides a watch point facility that is used to remap
read/write permissions on the individual pages of a processs address space. This facility has no restrictions and
is MT-safe. The new /proc file structure provides complete binary compatibility with the old /proc interface
except that the new watchpoint facility cannot be used with the old interface. Debugging tools have been
modified to use /procs new watchpoint facility, which means the entire watchpoint process is faster.The following
restrictions have been removed when setting watchpoints using the dbx debugging tool:
Setting watchpoints on local variables on the stacks due to SPARC register windows
Setting watchpoints on multi-threaded processes
Where to Find System Performance Tasks
The performance of a computer system depends upon how the system uses and allocates its resources. It is
important to monitor your systems performance on a regularly so that you know how it behaves under normal
conditions. You should have a good idea of what to expect, and be able to recognize a problem when it occurs.
System resources that affect performance include

Central processing unit (CPU) The CPU processes instructions, fetching instructions from memory and
executing them. Input/Output (I/O) devices I/O devices transfer information into and out of the computer. Such
a device could be terminal and keyboard, a disk drive, or a printer. Memory Physical (or main) memory is the
amount of memory (RAM) on the system.
Monitoring Performance (Tasks) describes the tools that display statistics about the activity and the
performance of the computer system.
Processes and System Performance
Terms related to process are described in process
Process Term Description
Process An instance of program in execution

Lightweight process Is a virtual CPU or execution resource. LWPs are scheduled by the kernel to usePU
resources based on their scheduling class and priority. LWPs include a kernel thread,
which contians information that has to be in memory all the time and an LWP which
contians information that is swappable.
Application thread A series of instructions with a separate stack that can execute independently in a users
address space. They can be multiplexed on top of LWPs.
A processs can consist of multiple LWPs and multiple application threads. The kernel schedules a kernel- thread
structure, which is the structure, which is the scheduling entity in the Sun OS environment. Various process
structures are described in Process Structures.
Process Structures
Structure Desription
Proc Contains information that pertains to the whole process and has to be in main memory all
the time.
Kthread Contains information that pertains to one LWP and has to be in main memory all the time.
User Contians the per process information that is swappable.
Klwp Contains the per LWP process information that is swappable.
The illustration below shows the relationship among these structures.
Main Memory
(non-swappable)
proccess kernel thread
(proc structure) (kthread structure)
per process per LWP
user LWP
(user structure) (klwp structure)
swappable
Command for Managing Processes
ps Check the status of active processes on a system, as well as display detailed information about
the process
Dispadmin List default scheduling policies
priocntl Assignn processes to a priority class and manage process priorities
nice Change the priority of a timesharing process
In addition, process tools are available in /usr/proc/bin that display highly detailed information about the processes
listed in /proc, also know as the process file system ( PROCFS ). Images of active process are stored here by
their process ID number.
The process tools are similar to some options of the ps command, except that the output provided by the tools is
more detailed. In general, the process tools:
Display more details about processes, such as fstat and fcntl information, working directories, and trees of parent
and child processes. Provided control over processes, allowing users to stop or resume them

The new /usr/proc/bin utilities are summarized in Process Tools.

Process Tools
Tools That Control Process What the Tools Do
/usr/proc/bin/pstop pid Stops the process

/usr/proc/bin/prun pid Restarts the process
/usr/proc/bin/ptime pid Times the process using microstate accounting
/usr/proc/bin/pwait [ -v ] pid Waits for specified processes to terminate
Tools That Display Process What the Tools Display

/usr/proc/bin/pcred pid Credentials
/usr/proc/bin/pfiles pid fstat and fcntl information for open files
/usr/proc/bin/pflags pid /proc tracing flags, pending and held signals, and other status
/usr/proc/bin/pldd pid Dynamic libraries linked into each process
/usr/proc/bin/pmap pid Address space map
/usr/proc/bin/psig pid Signal actions
/usr/proc/bin/pstack pid Hex+synbolic stack trace for each lwp
/usr/proc/bin/ptree pid Process trees containing specified pids
/usr/proc/bin/pwdx pid Current working directory
In these commands, pid is a process identification number. You can obtain this number by using the ps ef
command.
Process Scheduling Classes and Priority Levels
A process is allocated CPU timem acording to its scheduling class and its priority level. By default, the solaris
operating system has four process scheduling classes: real-time, system, timesharing and interactive.
Real-time processes have the highest priority. This class includes processes that must respond too external
events as they happen. For example, processes that collect data from a sensing device may need to process the
data and respond immediately. In most cases, a real-time process requires a dedicated system. No other
processes can be serviced while a real-time process has control of the CPU. By default, the range of priorities is
100-159. System processes have the middle priorities. The class is made up of those processes that are
automatically run by the kernel, such as the swapper and the paging daemon. By default, the range of priorities is
60-99. Timesharing processes have the lowest priority. This class includes the standard UNIX processes.
Normally, all user processes are timesharing processes. They are subject to a scheduling policy that attempts to
distribute processing time fairly, giving interactive applications quick response time and maintaining good
throughput for computations. By default, the range of prorities is 0-59. Interactive processes are introduced in the
sunOS 5.4 environment. The priorities range from 0-59. All processes started under open windows are placed in
the interactive class and those processes with keyboard focus get higher priorities.The scheduling priority
determines the order in which processes will be run. Real-time processes have fixed priorities. If a read-time
process is ready to run, no system process or timesharing process can run. System processes have fixed
priorities that are established by the kernel when they are started. The processes in the system class are
controlled by the kernel, and cannot be changed. Timesharing and interactive processes are controlled by the
scheduler, which dynamically assigns their priorities. You can manipulate the priorities of the processes within this
class.
Disk I/O and System Performance
The disk is used to store data and instructions used by your computer system. You can examine how efficiently
the system is accessing data on the disk by looking at the disk access activity and termiinal activity. If the CPU
spends much of its time waiting for I/O completions, there is a problem with disk slowndown. Some ways to
prevent disk slowdowns are:
Keep disk space with 10% free so file systems are not full. If a disk becomes full, backup up and restore the
filesystems to prevent disk fragmentation. Consider purchasing products that resolve disk fragmentation.
Organize the filesystem to minimize disk activity. If you have two disks, distribute the file system for a more
balanced load. Using Suns Solstice DiskSuite produuct provides more efficient disk usage.
Add more memory. Additional memory reduces swapping and paging traffic, allows an expanded buffer pool
(reducing the number of user-level reads and writes that need to go out to disk). Add a disk and balance the
most active filesystems across the disks.
Memory and System Performance

Performance suffers when the programs running on the system require more physical memory than is available.
When this happens, the operating system begins paging and swapping, which is costly in both disk and CPU
overhead. Paging involves moving pages that have not been recently referenced to a free list of available
memory pages. Most of the kernel resides in main memory and is not pageable. Swapping occurs if the page
daemon cannot keep up with the demand for memory. The swapper will attempt to swap out sleeping or stopped
lightweight process. The swapper will swap LWPs back in based on their priority. It will attempt to swap in
processes that are runnable.
Swap Space
Swap areas are really file systems used for swapping. Swap areas should be sized based on the requirements of
your applications.Check with your vendor to identify application requirements.
Buffer Resources
The buffer cache for read and write system calls uses a range of virtual addresses in the kernel address space. A
page of data is mapped into the kernel address space and the amount of data requested by the process in then
physically copied to the process address space. The page is then unmapped in the kernel. The physical page
will remain in memory until the page is freed up by the page daemon.
This means a few I/O-intensive processes can monopolize or force other processes out of main memory. To
prevent monopolization of main memory, balance the running of I/O- intensive processes serially in a script or
with the at command. Programmers can use mmap and madvise to ensure that their programs free memory
when they are not using it.
Kernel Parameters and System Performance
Many basic parameters (or tables) within the kernel are calculated from the value of the maxusers parameter.
Tables are allocated space dynamically. However, you can set maximums for these tables to ensure that
applications wont take up large amounts of memmory.
By default, maxusers is approximately set to the number of Mbytes of physical memory on the system. However,
the system will never set maxusers higher than 1024. The maximum value of maxusers is 2048, which can be set
by modifying the /etc/system file. In addtion to maxusers, a number of kernel parameters are allocated
dynamically based on the amount of physical memory on the system, as shown in kernel parameters below
Kernel Parameter
Ufs_ninode The maximum size of the inode table
Ncsize The size of the direectory name lookup cache
Max_nprocss The maximum size of the process
Ndquot The number of disk quota structures
Maxuprc The maximum number of user processes per user-ID
Default Settings for Kernel Parameters

Kernel Table Variable Default Setting
Inode ufs_ninode max_nproces + 16 + maxusers + 64
Name cache ncsize max_nprocs + 16 + maxusers + 64
Process max_nprocs 10 + 16 * maxusers
Quota table ndquot ( maxusers * NMOUNT ) / 4 + max_nprocs
User process maxuprc max_nprocs -5
SAR (System Activity Report)

SAR command writes the standard output the contents of the selected cumulative activity counters in the
operating system. If the following list is a breakdown of those activity counters that SAR accumulates
File access (sar f)
Buffer usage (sar b)
System call activity (sar a)
Disk and tape input / output activity (sar d)
Free memory & swap space (sar w)
Kernel memory allocation (sar m)
Inter process communication (sar c)
Paging

Queue activity (sar q)

Central Processing Unit (CPU) (sar u)
Kernel tables (sar k)
Switching (sar s)
Buffers
A cache of memory storage units that holds recently used data. (Buffers increase efficiency by keeping this data
on hand and decrease reading from the disk).
Table Entries
A space in system tables that the kernel uses to keep track of current tasks, resources and events.
Other Parameters
These are other definable values that govern special resources (Such as number of multi screens available).
The use of these resources is defined by certain limits known as tunable kernel parameters. These limits can be
decreased or extended. Some times at the expense of other resources.
Kernel Parameters
These are the values contain in the Unix system kernel, which is the core of operating system. Performance
tuning is activity that may need your attention when you first setup your Unix system. When you bring the system
up for the first time, the system is automatically set to a basic configuration i.e. satisfactory for most sites.
Changing kernel parameters:
The sysdef command shows current configuration of the kernel along with the relevant keywords which can be
used in /etc/system file to reconfigure the kernel.
Process Table
The process table sets the number of processes that the system can run at a time. These processes include
daemon processes, processes that local users are running, and processes those remote users are running.
User Process Table
The user process table controls the number of processes per user that the system can run.
Inode Table
When inode table is full, performance will degrade. This table is also relevant to the open file table since they are
both concern with same sub-system.
Open File Table
This table determines the number of files that can be open at the same time. When the system call is made and
the table is full the program will get error indication.
Quota Table
If your system is configured to support disk quotas, this table contains the number of structures that have been
set aside for that use. The quota table will have an entry for each user who has a file system that has quotas
turned on. As with the inode table, performance suffers when the table fills up, and errors are written to the
console.
Callout Table
This table controls the number of timers that can be active concurrently. Timers are critical to many kernel related
and I/O activities. If the callout table over flows, the system is likely to crash.
NICE
The nice command is used to execution a command at a different scheduling priority than usual. The range of
nice value is from 0 to 39, with higher nice values resulting in lower priorities. By default, when nice is
not used, commands have nice value range of 20 to 20. Usually, you should use the nice command to
lower the priority of background or batch processes for which you do not need fast turn around.
Example
#nice find . name *.c print &

This will set the process to a default nice priority.

#nice 16 find . name *.c print &
This runs the process at given range of lower priority.
Linking Files
Link is a pointer stored else where on the system. Instead of two or more copies of a file on your system, you can
link to a file that already exists on your system. Links are also useful for centralizing files. There are two types of
links for a file.
1. Hard Link
2. Symbolic Link
Hard Link
In hard links, original file name and linked file names points to the same physical address and are absolutely
identical. In this a directory cannot have hard link and it cannot cross-file system. It is possible to delete the
original file name without deleting a linking file name. Under such circumstances, the file is not deleted. But the
directory of the original file is deleted and the link count is decrement by one. Data blocks of the file are deleted
when the link count becomes zero.
Symbolic Link (Soft Link)
In the symbolic link there are two files, one is the original file, and other is the linked file name-containing name of
the original file. In symbolic link you may remove original file and it will cause linked file name to be there, but
without any data. An important feature of symbolic link is that it can be used to link directories as well as files.
Compress Utility
In UNIX we can compress large files if we need more free disk space. It is recommended that always maintain
atleast 15% free space in every filesystem. In case if you see any filesystem is low on freespace, you can consult
your users, and compress some of the big files.
# compress export.dmp
This command will compress the above file and renames the file with .Z extension. To uncompress this file, you
can use another command called uncompress command.
Solaris kernel tuning
Kernel is the core of Operating system and provides services such as process and memory management, I/O
services, device drivers, job scheduling, and low-level hardware interface routines such as test and set
instructions. The kernel consists of many internal routines that handle users requests. You cannot call Kernels
internal routines directly. The only way to call it is by using system calls.
The kernel manages requests from users via system calls that switch the process from user space to Kernel
space. Each time a user process makes a system call such as read (), fork (), open (), exec (), etc.
The user process experiences a context switch. A context switch is a mechanism by which a process switches
from one state to another. The process may be either suspended until the system call is completed (blocking) or
the process may continue and later be notified of the system call completion via a signal (non-blocking).
On sun Solaris the path for the UNIX Kernel is /kernel/genunix. Each time a process is started, the kernel
has to initialize the process, assign the process a priority, allocate memory and resources for the process, and
schedule the process to run. When the process terminates, the kernel frees any resources held by it.
Unix buffers
UNIX employs a file system buffer cache to cache file system information. When a user process issues a read,
the kernel first scans through the UNIX buffer cache to determine if the data is already in the cache, the Kernel
then copies the data from the buffer cache into the users work space.
The UNIX buffer is controlled by Kernel parameter bufhwm controls the size of the UNIX buffer cache, another
parameter npbuf controls the number of physical I/O buffers allocated each time when more buffers are needed.
These parameters can be set in /etc/system file.
Any reads issued to a UNIX file system-based file causes the data first to be brought into UNIX buffer cache, and
then copied into the user space (in Oracle database it is the Oracle SGA). Therefore each read translates into a
read followed by a copy from Kernel space to user space.

The UNIX buffer cache is used to cache file data and file-related information such as file headers, inodes, and
indirect block addresses. You can use sar -b to monitor the hit ratio of the buffer cache.
Virtual memory
The virtual memory model allows a process or a system to address more memory than physically exists. The
UNIX operating system uses swap device in addition to physical memory to manage the allocation and
deallocation of memory, For example, a machine with 64 MB of physical memory and 192MB swap device
supports a virtual memory size of 256 M.
The physmem kernel parameter sets the total amount of physical memory in the system. This value is
automatically set when the system boots up. For benchmarking purpose this parameter can be set to study the
system behavior, e.g., if you have 1GB physical memory, you may want to set physmem to 128M and run
applications.
The physmem parameter can be set in /etc/system file, use
# set physmem = 260000
Remember the size is set in pages, not in bytes, in the case above it is (260000 * 4K).
The kernel memory allocator (kma) is responsible for serving all memory allocation and de-allocation requests.
The kma is responsible for maintaining memory free list.
On solaris, you can monitor the activity of the kma using kma command.
Using sar -k, you can monitor the workload of the kma.
Note: The Sun4u architecture (ultra series) uses an 8K page size.
Swapping
Swapping is the process by which the system no longer has enough free physical memory, and memory pages of
a process are completely swapped (written) to the swap device. The minfree kernel parameter sets the
absolute lower limit of free available memory. If free memory drops below minfree, swapping activity begins.
To list the swap devices configured on your system use
# swap -l
Paging
Current versions of UNIX provide a more granular approach to swapping known as paging. Paging swaps out
various different pages in memory to swap device rather than the entire process as in swapping. Typical memory
pages are 4K in size. There are several paging parameters that control both the action and the frequency of the
page daemon. The paging parameters are lotsfree, desfree, minfree, slowscan, fastscan and
handspreadpages these parameters can be set in /etc/system file.
Because the UNIX operating system is based on the virtual memory model, a translation layer is needed between
virtual memory addresses and physical memory addresses. This translation layer is part of the Kernel and is
usually written in machine level language (Assembly) to achieve optimal performance when translating and
mapping addresses.
For example, declaring large SGA when only a small section of the SGA is actively used could cause the unused
portions of the SGA to be paged back to the free list. This allows other processes access to the physical memory
pages. UNIX kernel maintains a free list of memory pages and uses the page daemon to periodically scan the
memory pages for active and idle pages.
The lotsfree kernel parameter sets the upper bound of free memory that the system tries to maintain. If the
available free memory is always above lotsfree, the page daemon will remain idle. Setting lotsfree
parameter to a higher value if you have low memory causes page daemon to be active and the processes do not
have to starve for memory.
The maxpgio parameter regulates the number of page-out I/O operations per second that are scheduled by the
system. On Solaris, the default is 40 pages per second. This value is based on the 3600rpm disk drive. However,
most new disk drives are either 5400 or 7200 rpm. On Solaris, the formula for maxpgio is rpm value X 2/3.
When tuning kenel paging parameters, you must maintain the following range check:
LOTSFREE > DESFREE > MINFREE

Thrashing occurs when swapping was not successful in freeing memory, and memory is needed to serve critical
processes. This usually results in a panic.
Memory Leaks
Programs sometimes cause memory leaks due to improper process cleanup during the life of a process. Memory
leaks are generally difficult to detect, especially in daemon that run continuously and fork children to parallelize
requests. There are numerous tools available in the market those help to detect memory leaks and access
violations.
Shared memory
The UNIX system V Release 4 operating system standard provides many different mechanisms for inter-process
communication. Inter-process communication is required when multiple distinct processes need to communicate
with each other either by sharing data or resources or both.
Shared memory, as the term suggests, enables multiple processes to "share" the same memory. In other words,
multiple processes mapping into the same virtual address map.
Oracle uses shared memory to hold the System Global Area (SGA).
The kernel parameters associated with the shared memory are:
SHMMAX, SHMMIN, SHMNI, and SHMSEG.
These parameters can be set in /etc/system file.
Process model
The UNIX operating system uses a priority-based round-robin process scheduling architecture. Processes are
dispatched to the run queue based on priority, and are placed on the sleep queue based either on the process
completion of its time slice or by waiting on a event or resource. Processes can sometimes result in a deadlock
when waiting on a resource. The kernel provides deadlock detection within the kernel; the best practice is for the
user application to provide deadlock detection.
For example if three processes are on dispatch queue which begins execution on three different CPUs, and three
more processes are sleeping. Once the time slice of the running process is exceeded, the process will be
migrated to sleep queue in favor of other sleeping processes.
Then the the process with highest priority (which is in the Ready to runqueue) will be scheduled to run. The kernel
may also decide to preempt processes by reducing their priority to make way for other processes.
Process states
The lifetime of a process can be concptually didvided into a set of states that describe the process. At any time, a
process can be in one of the following states.
1. The process is executing in user mode.
2. The process is executing in kernel mode.
3. The process is not executing but ready to run as soon as the kernel schedules it.
4. The process is sleeping & resides in main memory.
5. The process is ready to run, but the swapper (process 0) must swap the process into main memory
before the kernel can schedule it to execute.
6. The process is sleeping, and the swapper has swapped the process to secondary storage
7. To make room for other processes in main memory.
The process is returning from kernel to user mode, but the kernel preempts it and does a context switch to
schedule another process.
The process is newly created and is in a transition state; the process is ready to exist, but it is not ready to run,
nor it is sleeping. This state is the start state for all processes except process 0.
The process executed the exit system call and is in the zombie state. The process no longer exists, but it leaves a
record containing the exit code and some timing statistics for its parent process to collect. The zombie state is the
final state of a process.
The zombie process has two meanings:
The first is that process (child process) has terminated, and has a parent process.

The second is that the process is marked to be killed by the UNIX kernel. During the zombie state, the process
structure and address space is removed and freed back to the system. The only information remaining in the
kernel for a zombie process is an entry in the process table.
The process structure contains many different fields, including process information and process statistics in case
the process is swapped out. Each time a process is created, a separate process structure for that process is
created. The complete listing of process structure is available in proc.h file located in /usr/include/sys
directory.
nice command can be used to change priority levels of a process and only super-user can do this.
Job Scheduler
UNIX operating system job scheduler provides three different types of job classes as below
Job Class Priority Range Description
Time-share 0 through 59 Default job class
System 60 through 99 Reserved for system daemon processes
Real-Time 100 through 159 Highest priority job class
In theTime-slice job class, each process is assigned a time slice (or Quantum). The time slice specifies the
number of CPU clock ticks that a particular process can occupy the CPU. Once the process finishes its time slice,
the process priority is usually decreased and the process is placed on the sleep queue. Other process waiting for
the CPU time may have their priority increased & they are likelihood to run.
The system job class is reserved for system daemon processes such as the pageout daemon or the file system
daemon.
Real-Time job class is the highest priority job class, and has no time slice. Best example is thrashing.
Use ps -efc command to list job class and priority of a process.
Threads
A thread is an independent path (unit of control) of execution within a process.
A thread can be thought of as a sub-task or sub-process. Unlike process model, which creates a separate
process structure for each process, the threads model has substantial less overhead than a process. A thread is a
part of the process address space; therefore it is not necessary to duplicate the address space of a process when
a new thread is created. There is an order of magnitude of difference between creating a process versus a thread.
It takes approximately 1,000 times longer to create a full process that it does to create a thread. Sun Solaris 2.x
provides a Solaris threads library as well as the POSIX thread library.
Most of the system daemons use threads to serve requests.

Chapter 17 Miscellaneous Page 189 of 194
17. Miscellaneous
17.1. Dynamic Host Configuration Protocol
Not very long ago, networks used to be small and static in nature and easy to manage on a per-host basis. Plenty
of IP addresses were available, and these IP addresses were assigned statically to all hosts connected to a
network. An IP address was reserved for each host in this scheme even if the host was not turned on. This
scheme worked fine until networks grew larger and mobile hosts, such as laptops and PDAs, started creeping in.
Mobile hosts that moved frequently from one network to another needed special attention, because of the
difficulty of reconfiguring a laptop computer whenever it was connected to a different network. With very large
networks, the need for centralized configuration management also became an issue. The Dynamic Host
Configuration Protocol (DHCP) solves these problems by dynamically assigning network configuration to hosts at
boot time. A DHCP server keeps information about IP addresses that can be allocated to hosts. It also keeps
other configuration data, such as the default gateway address, Domain Name Server (DNS) address, the NIS
server, and so on. A DHCP client broadcasts a message that locates a DHCP server. If one or moreDHCP
servers are present, they offer an IP address and other network configuration data to the client. If the client
receives a response from multiple servers, it accepts the offer from one of the servers. The server then leases
one IP address to the client for a certain period of time and the client configures itself with network configuration
parameters provided by the server. If the client host needs an IP address for a longer period, it can renew the
lease time. If a client host goes down before the lease time is over, it sends a message to the DHCP server to
release the IP address so that it can be assigned to another host. DHCP is usually not used for hosts that need
static IP addresses, although it has the provision to assign static IP addresses to clients. These hosts include
different types of servers and routers. Servers need static IP addresses so that clients of that server always
connect to the right host. Similarly, routers need a static IP address to have a consistent and reliable routing table.
Other than that, user PCs, workstations, and laptop computers may be assigned dynamic addresses.
The Dynamic Host Configuration Protocol is based on the Bootstrap Protocol (BOOTP). BOOTP was used to boot
diskless workstations. BOOTP has many limitations, however, including the manual configuration on the BOOTP
server. DHCP also can be used to configure several more network parameters compared to BOOTP, and it is
more flexible.
DHCP Lease Time
When a client connects to a DHCP server, the server offers an IP address to the client for a certain period of time.
This time is called the lease time. If the client does not renew the lease, the IP address is revoked after the
designated time. If configured as such, the client can renew its lease as many times as it likes.
DHCP Scope
Scope is the range of IP addresses from a network that a DHCP server can assign to clients. A server may have
multiple scopes. However, a server must have at least one scope to be able to assign IP addresses to DHCP
clients. DHCP scope is defined at the time of configuring the DHCP server.
Booting a Workstation Using DHCP
DHCP uses BOOTP port numbers 67 (for clients) and 68 (for servers). The process of booting a host using DHCP
consists of a number of steps. First, a DHCP client locates a DHCP server using a broadcast packet on the
network. All the DHCP servers listen to this request and send a lease offer. The client accepts one of the lease
offers and requests the offering server to assign an IP address and other network parameters. The following
sections describe these steps in more detail.
Discovering the DHCP Server
First, the DHCP client sends a DHCPDISCOVER type of broadcast message to find the available DHCP servers
on the network. The source address in this message is 0.0.0.0 because the DHCP client does not know its own IP
address at this time. If no DHCP server responds to this message, the message send attempt is retried. The
number of retries depends on the client.
Lease Offer
When the DHCP server listens to the DHCPDISCOVER message, a response is sent back using the
DHCPOFFER message. A client may receive multiple offers depending on how many DHCP servers are present
on the network. The DHCPOFFER message contains the offered IP address and other network configuration
information.
Lease Acknowledgment

The selected DHCP server then sends back a DHCP acknowledgment message (DHCPACK) to the DHCP client.
If response from the client is too late and the server is not able to fulfill the offered IP address, a negative
acknowledgment (DHCPNAK) is sent back to the client.
Client Configuration
When a client receives an acknowledgment message with configuration parameters, it verifies that any other host
on the network is not using the offered IP address. If the IP address is free, the client starts using it. The snoop
command can be used to see how data packets are exchanged between a client and a server during the time that
the client verifies that no other host is using the offered IP address.
DHCP Lease Renewal
A DHCP client requests the DHCP server to renew the IP lease time when 50% of the lease time has passed. It
does so by sending a DHCPREQUEST message to the server. If the server responds with a DHCPACK
message, the lease is renewed and a time counter is reset. If the client does not receive an acknowledgment from
the server, it again tries to renew the lease when 87.5% of the lease time has passed. If it does not receive a
message for this request, it restarts the DHCP configuration process at the end of the lease time.
Lease Release
If a client shuts down before the lease time is expired, it sends a DHCPRELEASE message to the DHCP server
telling it that it is going down and the IP address is going to be free. A server can then reuse this IP address
immediately. If the client does not send this message before shutting down, the IP address may still be marked as
being in use.
DHCP IP Address Allocation Types
Basically, the following three types of IP address allocations are used by DHCP when assigning IP addresses to
DHCP clients:
1. Automatic: The automatic lease is used to assign permanent IP addresses to hosts. No lease
expiration time applies to automatic IP addresses.
2. Dynamic: The dynamic lease is the most commonly used type. Leased IP addresses expire after lease
time is over, and the lease must be renewed if the DHCP client wants to continue to use the IP address.
3. Manual:A manual allocation is used by system administrators to allocate fixed IP addresses to certain
hosts.
Planning DHCP Deployment

#/usr/sadm/admin/bin/dhcpmgr
This is GUI tool to configure DHCP
Normally two types of hosts reside on a network: those hosts that have fixed IP address allocation and those that
can have dynamic IP address allocation. Usually servers and routers have fixed allocation, whereas user PCs and
workstations can be assigned IP addresses dynamically. When planning DHCP on a network, keep in mind the
following things:
How many IP addresses can be used with DHCP? When you calculate this number keep in mind the number of
IP addresses assigned to servers and routers. These are the fixed IP addresses that will not be used in DHCP.
Subtract this number from the total available IP addresses to determine the number of available IP addresses for
DHCP. Remember that you also might need more fixed IP addresses in the future than you are currently using.
How many DHCP servers should be installed? This depends on the number of DHCP clients and the lease time.
The larger the number of clients, the more servers should be used. If the lease time is too short, it might load
DHCP servers (because in such a case, each DHCP client has to renew its lease very often). The number of
DHCP servers also depends on the number of network segments.
How many people use laptops or mobile units that may be connected to different networks? Practically, it might
not be realistic to figure this number out, but you should make an educated guess.
Do people reboot their systems on a daily basis or do they keep their systems running? This will help you choose
the appropriate lease time.
If you have plenty of IP addresses, you might want to install backup DHCP servers. Remember that two DHCP
servers cannot have the same scope; therefore, there isnt really a true DHCP server backup. You must have a
different scope for each DHCP server. If you install two DHCP servers on the same network but with a different
scope of IP addresses, one of these can respond to clients if the other one is dead. If you have fewer than 100

DHCP clients on network 192.168.2.0, for example, you can have two DHCP servers. One of these DHCP
servers has the scope of IP addresses from 192.168.2.51 to 192.168.2.150, and the other one has a scope of IP
addresses from 192.168.2.151 to 192.168.2.250.
When planning to deploy DHCP, follow these steps:
Collect information about your network topology to find out how many DHCP servers or relay agents are required.
DHCP cannot be used where multiple IP networks use the same network physical media.
1. Select the best available servers for DHCP.
2. Determine which data storage method should be used. The data storage method tells the DHCP server
how to keep the DHCP database. Two methods are available on Solaris systems: the files method
and the nisplus (NIS+) method. In the files method, DHCP database files are stored in a local directory
on the DHCP server. In the NIS+ method, the DHCP data is stored in NIS+ database on the NIS+ server.
I recommend using the files method; in fact, NIS+ is seldom used.
3. Determine a lease policy for your network. Keep in mind the factors mentioned earlier while deciding on a
lease policy. Also decide whether youll use a dynamic or permanent lease type.
4. Determine which routers you need for DHCP clients. You have to assign these addresses to clients when
offering a lease.
5. Determine the IP addresses to be managed by each server. After going through each of these steps, you
should have a fairly good idea about how to proceed with the installation of DHCP on your network.
DHCP Configuration Files

dhcp_network This file is present in the same directory as the dhcptab file.
The actual name of the file is in the NNN_NNN_NNN_NNN notation, where NNN shows octet values in the
network address.
dhcptab This is a DHCP macro table file.
/etc/default/dhcp This file contains the location of the preceding two files along with other information.
Automatic Startup of DHCP Server
When you configure the DHCP service using dhcpmgr or dhcpcon.g utilities, startup and shutdown scripts are
created in appropriate directories. The default startup script for DHCP is present in /etc/init.d/dhcp and is shown
here:
bash-2.03# cat /etc/init.d/dhcp
This is a simple script and is copied as /etc/rc3.d/S34dhcp to start the DHCP service and as /etc/rc2.d/K34dhcp to
shut down DHCP services. Ideally you dont need to do anything if you are using one of the DHCP configuration
methods discussed earlier. However, you also can create and modify the script manually.
Configuring the DHCP Client
You can enable DHCP on one or more of the network interfaces installed on your server or workstation.
Configuring a DHCP client is very easy. First you must determine on which interface you want to enable DHCP. If
this interface is already configured with an IP address, you have to unconfigure it using the ifconfig
<interface> unplumb command.
Manually Configuring the DHCP Client
Use the ifconfig command to list the interfaces. If an interface is not listed but you know it is present, use the
ifconfig plumb command to bring it up. The following command brings hme1 up:
bash-2.03# ifconfig hme1 plumb
Use the following command to list this interface to determine what the current configuration is:
bash-2.03# ifcon.g hme1
hme1: .ags=1000842<BROADCAST,RUNNING,MULTICAST,IPv4> mtu.1500 index 2
inet 0.0.0.0 netmask 0
bash-2.03#
Enable DHCP on the interface by using the following command:

#ifconfig hme1 dhcp

You can check the status of DHCP on this interface by using the following command:
#ifconfig hme1 dhcp status
Enabling DHCP on Interfaces at Boot Time
To enable DHCP on an interface at boot time, you have to create two files. If you want to enable DHCP on the
newly configured interface hme1, for example, you have to create the following two files in the /etc directory:
homename.hme1
dhcp.hme1
Next time you reboot your system, interface hme1 will be configured with DHCP.
Troubleshooting DHCP
If you are using files to store DHCP databases rather than nisplus, you should have few problems to troubleshoot.
The following common DHCP server problems may occur:
The reutilization of IP addresses. It may happen that one or more IP addresses included in the DHCP scope are
statically assigned to other hosts. In this case, there is conflict of IP addresses. Use the snoop command in
conjunction with the ping command to find the MAC address of the other host that is using the conflicting IP
address.
Same IP address included in scopes of multiple DHCP servers. An IP conflict may also occur if overlapping IP
addresses are included in the scope of multiple DHCP servers. You should use DHCP Administrator or dhcpcon.g
to correct this problem.
A client asks to renew a lease for an IP address that has been marked as unusable. A message from the DHCP
server will appear in the SYSLOG message, if configured, in such a case. You can use DHCP Manager to correct
this problem. This also might happen if a client ID is configured for a particular IP address and that address is
marked as unusable.
If you see a message such as No more IP addresses, the number of DHCP clients is more than the number of
available IP addresses. You can trace many DHCP problems using the snoop command. This command will
show network packets flowing on a particular interface. You also can trace DHCP problems by running DHCP
client and DHCP server in Debug mode.
17.2. Samba
UNIX has brought TCP/IP and the Internet to the table, while windows has brought millions of users. And so, we
just cant survive only with one operating system, rather we have to take advantage of the of the variety and
cooperate to make most of the available OSs.
The most powerful level of PC/UNIX integration is achieved by sharing directories that live on a UNIX host with
desktop PCs that run Windows. The shared directories can be made to appear transparently under Windows, as
an extension to the regular Windows network file tree. Either NFS or CIFS can be used to implement this
functionality.
NFS was designed to share files among UNIX hosts, on which the file locking and security paradigms are
significantly different from those of Windows. Although a variety of products (e.g. PC-NFS) that mount NFS-
shared directories on Windows clients are available, their use should be aggressively avoided, both because of
the paradigm mismatch and because CIFS just works better.
CIFS: the Common Internet File System
CIFS is based on protocols that were formerly referred to as Server Message Block or SMB. SMB was an
extension that Microsoft added to DOs in tis early days to allow disk I/O to be redirected to a system known as
NetBIOS (Network Basic Input/Output System). Designed by IBM and Sytec, NetBIOS was a crude interface
between the network and application.
In the modern world, SMB packets are carried in an extension of NetBIOS known as NBT, NetBIOS over TCP.
While this sounds very convoluted, the result is that these protocols have become widespread and are available
on platforms ranging from MVS and VMS to our friends UNIX and Windows.
Samba is an enormously popular software package available under the GNU public license that implements CIFS
on UNIX hosts. Andrew Tridgell, an Australian, who reverse engineered the SMB protocol from another system
and published the resulting code in 1992, originally created it.

Today, Samba is well supported and actively under development to expand its functionality. It provides a stable,
industrial-strength mechanism for integrating Windows machines into a UNIX network. The real beauty of it is that
you only need to install one package on the UNIX machine; no additional software is needed on the Windows
side.
CIFS provides five basic services:
File Sharing
Network Printing
Authentication and authorization
Name Resolution
Service announcement (file server and printer browsing)
Most of Sambas functionality is implemented by two daemons: smbd and nmbd. smbd implements the first three
services (as listed above) and nmbd provides the remaining two services.
Unlike NFS, which is deeply intertwined with the kernel, Samba requires no kernel modifications and runs entirely
as a user process. It binds to the sockets used for NBT requests and waits for a client to request access to a
resource. Once the request has been made and authenticated, smbd forks an instance of itself that runs as the
user who is making the requests. As a result, all normal UNIX file access permissions (including group
permissions) are obeyed. The only special functionality that smbd adds on top of this is a file locking service that
provides client PCs with the locking semantics they are accustomed to.
17.3. Apache
In the 1980s, UNIX established a reputation for providing a high-performance, production-quality networked
environment on a variety of hardware platforms. When the World Wide Web appeared on the scene as the
ultimate distributed client/server application in the early 1990s, UNIX was there as its ready-made platform, and a
new era was born.
Web Hosting
In the early 1990s, UNIX was the only choice for serving content on the web. As the webs popularity grew, an
increasing number of parties developed an interest in having their own presence on the net.
Seizing the opportunity, companies large and small jumped into the ring with their own server solutions. A new
industry segment known as web-hosting or Internet hosting was born around the task serving content to the
web. These days we have a variety of web hosting platforms to choose from, and a number of specialized web
servers have been developed to meet the needs of specific market channels. Foe reliability, maintainability,
security and performance, UNIX is a better choice.
The foremost advantages of UNIX are its maintainability and performance. UNIX was designed from the start as a
multi-user, interactive operating system. On a UNIX box, one administrator can maintain a database, while
another looks after I/O performance and a third maintains the web server.
Web Hosting Basics
Hosting a web site isnt substantially different from providing any other network service. The foundation of the
World Wide Web is the Hyper-Text Transfer Protocol (HTTP), a simple TCP-based protocol thats used to format,
transmit, and link documents containing a variety of media types, including text, pictures, sound, animation, and
video. HTTP behaves much like the other client/server protocols used on the Internet, for example, SMTP (for
email) and FTP (for file transfer).
A web-server is simply a system thats configured to answer HTTP requests. To convert your UNIX system into a
web hosting platform, you need to install a daemon that listens for connections on TCP port 80 (the HTTP
standard), accepts requests for documents, and transmits them to the requesting user.
Web browsers such as Netscape and IE contact remote web-servers and make requests on behalf of users. The
documents thus obtained can contain hypertext pointers to other documents, which may or may not live and the
server that the user originally contacted. Since the HTTP protocol standard is well defined, clients running on any
OS can connect to any HTTP server.
How HTTP works

HTTP is the protocol that makes the WWW really work and it is an extremely basic, stateless, client/server
protocol. In the HTTP model, the initiator of a connection is always a client (usually a browser). The client asks
the server for contents of a specific URL. The server responds with either a spurt of data or with some type of
error message.
Virtual Interfaces
In the olden days, a UNIX machine typically acted as a server for single web site. As the webs popularity grew,
everybody wanted to have their own web-sites, and overnight, thousands of companies became web hosting
providers.
Providers quickly realized that they could achieve significant economies of scale if they were able to host more
than one site on a single server. In response to this business need, virtual interfaces were born (in fact, the
research project of UNIX was funded by the then big companies to support their businesses).
The idea is simple: a single UNIX machine responds on the network to more IP addresses than it has physical
network interfaces. Each of the resulting virtual network interfaces can be associated with a corresponding
domain name that users on the Internet might want to connect to. This feature allows a single UNIX machine to
serve literally hundreds of web sites.
WWW Servers
Installing and configuring a Web server is a much more involved process. A Web server is a very complex
daemon with numerous features controlled by a couple of configuration files. Web servers not only access files
containing Web pages, graphics and other media types for distribution of clients, they can also assemble pages
from more than one file, run CGI applications, and negotiate secure communications. Basic server configuration
issues are discussed in the follwing sections.
Apache is a free Web server developed by a community of Internet Programmers; it is available for many UNIX
systems as well as Solaris in source code form. It includes the latest features and provides for a broad range of
customization and configuration. It is a good choice for sites that require the latest web server features and
possess the required software development tools to compile and maintain the program.

Appendix
SMF Services
The following table lists some of the services that have been converted to use SMF. Each service includes the
daemon or service name, the FMRIs for that service, the run script that used to start the service, and whether the
service is started by inetd.


Solaris 10 Handbook

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Solaris 10 Handbook

Încărcat de

Drepturi de autor:

Formate disponibile

Solaris Handbook

Info-ap@wilshiresoft.com Ph: 040-23757906 / 07, 64526173 info-ht@wilshiresoft.com

Info-ap@wilshiresoft.com Ph: 040-23757906 / 07, 64526173 info-ht@wilshiresoft.com

Info-ap@wilshiresoft.com Ph: 040-23757906 / 07, 64526173 info-ht@wilshiresoft.com

Info-ap@wilshiresoft.com Ph: 040-23757906 / 07, 64526173 info-ht@wilshiresoft.com

1.2. A Brief History of Sun Microsystems

Info-ap@wilshiresoft.com Ph: 040-23757906 / 07, 64526173 info-ht@wilshiresoft.com

1.3. Working with Host

Alice Humpty Dumpty Queen

Info-ap@wilshiresoft.com Ph: 040-23757906 / 07, 64526173 info-ht@wilshiresoft.com

1.4. Roles of Servers and Clients

A typical file server providing html pages for a client

Info-ap@wilshiresoft.com Ph: 040-23757906 / 07, 64526173 info-ht@wilshiresoft.com

Info-ap@wilshiresoft.com Ph: 040-23757906 / 07, 64526173 info-ht@wilshiresoft.com

Solaris Release History

Info-ap@wilshiresoft.com Ph: 040-23757906 / 07, 64526173 info-ht@wilshiresoft.com

Solaris Installation over the network

Info-ap@wilshiresoft.com Ph: 040-23757906 / 07, 64526173 info-ht@wilshiresoft.com

2.1.2. Hardware Requirements for Installation of the Solaris 10 OE

2.1.3. Solaris OE Software Groups

Info-ap@wilshiresoft.com Ph: 040-23757906 / 07, 64526173 info-ht@wilshiresoft.com

Accessing the GUI or Console-based Installations

Installation with 128383 MB minimal memory

Info-ap@wilshiresoft.com Ph: 040-23757906 / 07, 64526173 info-ht@wilshiresoft.com

Installation with 384 MB memory or greater

2.1.4. Pre-Installation Information

Info-ap@wilshiresoft.com Ph: 040-23757906 / 07, 64526173 info-ht@wilshiresoft.com

3. File Systems & Software Management

Solaris OE Directory Hierarchy (Its not a complete tree)

3.1.2. File Components

Info-ap@wilshiresoft.com Ph: 040-23757906 / 07, 64526173 info-ht@wilshiresoft.com

3.1.3. File Types

Info-ap@wilshiresoft.com Ph: 040-23757906 / 07, 64526173 info-ht@wilshiresoft.com

Info-ap@wilshiresoft.com Ph: 040-23757906 / 07, 64526173 info-ht@wilshiresoft.com

Info-ap@wilshiresoft.com Ph: 040-23757906 / 07, 64526173 info-ht@wilshiresoft.com

Character-Special Device Files

3.2.1. Disk Architecture

Physical Disk Media

Info-ap@wilshiresoft.com Ph: 040-23757906 / 07, 64526173 info-ht@wilshiresoft.com

Disk Slice Naming Convention

Embedded SCSI configuration

Info-ap@wilshiresoft.com Ph: 040-23757906 / 07, 64526173 info-ht@wilshiresoft.com

3.2.2. Device Naming Convention

3.2.3. Managing Devices

Info-ap@wilshiresoft.com Ph: 040-23757906 / 07, 64526173 info-ht@wilshiresoft.com

3.2.4. Reconfiguring Devices

Info-ap@wilshiresoft.com Ph: 040-23757906 / 07, 64526173 info-ht@wilshiresoft.com

3.2.5. Disk Partitioning

Info-ap@wilshiresoft.com Ph: 040-23757906 / 07, 64526173 info-ht@wilshiresoft.com

Introducing Disk Partition Tables

3.2.6. Introducing Disk Labels

3.3. Solaris OE File Systems

Info-ap@wilshiresoft.com Ph: 040-23757906 / 07, 64526173 info-ht@wilshiresoft.com

Info-ap@wilshiresoft.com Ph: 040-23757906 / 07, 64526173 info-ht@wilshiresoft.com

3.3.2. UFS File System

The above tabulates the features of UFS FileSystem.

Info-ap@wilshiresoft.com Ph: 040-23757906 / 07, 64526173 info-ht@wilshiresoft.com

Customizing UFS File System Parameters

Logical Block Size

Info-ap@wilshiresoft.com Ph: 040-23757906 / 07, 64526173 info-ht@wilshiresoft.com

Info-ap@wilshiresoft.com Ph: 040-23757906 / 07, 64526173 info-ht@wilshiresoft.com

Features of Format Command

Creating a UFS FileSystem

Info-ap@wilshiresoft.com Ph: 040-23757906 / 07, 64526173 info-ht@wilshiresoft.com