Sa 210 S10

Make the Transition to the
Solaris™ 10 Operating System

SA-210-S10
Student Guide With Instructor Notes
Sun Microsystems, Inc.

UBRM05-104
500 Eldorado Blvd.
Broomfield, CO 80021
U.S.A.
Revision A
March 29, 2006 12:13 pm
Copyright 2006 Sun Microsystems, Inc., 901 San Antonio Road, Palo Alto, California 94303, U.S.A. All rights reserved.
This product or document is protected by copyright and distributed under licenses restricting its use, copying, distribution, and
decompilation. No part of this product or document may be reproduced in any form by any means without prior written authorization of
Sun and its licensors, if any.
Third-party software, including font technology, is copyrighted and licensed from Sun suppliers.
Sun, Sun Microsystems, the Sun logo, Solaris, Sunsolve, JumpStart, Java, Sun Java System, Sun Update Connection, Sun Update Manager,
Sun Enterprise Authentication Mechanism, and Ultra are trademarks or registered trademarks of Sun Microsystems, Inc. in the U.S. and
other countries. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc.
in the U.S. and other countries. Products bearing SPARC trademarks are based upon an architecture developed by Sun Microsystems, Inc.
UNIX is a registered trademark in the U.S. and other countries, exclusively licensed through X/Open Company, Ltd.
Federal Acquisitions: Commercial Software – Government Users Subject to Standard License Terms and ConditionsExport Laws. Products,
Services, and technical data delivered by Sun may be subject to U.S. export controls or the trade laws of other countries. You will comply
with all such laws and obtain all licenses to export, re-export, or import as may be required after delivery to You. You will not export or re-
export to entities on the most current U.S. export exclusions lists or to any country subject to U.S. embargo or terrorist controls as specified
in the U.S. export laws. You will not use or provide Products, Services, or technical data for nuclear, missile, or chemical biological
weaponry end uses.
DOCUMENTATION IS PROVIDED “AS IS” AND ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS, AND
WARRANTIES, INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE
OR NON-INFRINGEMENT, ARE DISCLAIMED, EXCEPT TO THE EXTENT THAT SUCH DISCLAIMERS ARE HELD TO BE
LEGALLY INVALID.
THIS MANUAL IS DESIGNED TO SUPPORT AN INSTRUCTOR-LED TRAINING (ILT) COURSE AND IS INTENDED TO BE
USED FOR REFERENCE PURPOSES IN CONJUNCTION WITH THE ILT COURSE. THE MANUAL IS NOT A STANDALONE
TRAINING TOOL. USE OF THE MANUAL FOR SELF-STUDY WITHOUT CLASS ATTENDANCE IS NOT RECOMMENDED.
Export Control Classification Number (ECCN) assigned: 26 March, 2006
Please
Recycle
Copyright 2006 Sun Microsystems Inc., 901 San Antonio Road, Palo Alto, California 94303, Etats-Unis. Tous droits réservés.
Ce produit ou document est protégé par un copyright et distribué avec des licences qui en restreignent l’utilisation, la copie, la distribution,
et la décompilation. Aucune partie de ce produit ou document ne peut être reproduite sous aucune forme, par quelque moyen que ce soit,
sans l’autorisation préalable et écrite de Sun et de ses bailleurs de licence, s’il y en a.
Le logiciel détenu par des tiers, et qui comprend la technologie relative aux polices de caractères, est protégé par un copyright et licencié
par des fournisseurs de Sun.
Sun, Sun Microsystems, le logo Sun, Solaris, SunSolve, JumpStart, Java, Sun Java System, Sun Update Connection, Sun Update Manager,
Sun Enterprise Authentication Mechanism, etUltra sont des marques de fabrique ou des marques déposées de Sun Microsystems, Inc. aux
Etats-Unis et dans d’autres pays.
Toutes les marques SPARC sont utilisées sous licence sont des marques de fabrique ou des marques déposées de SPARC International, Inc.
aux Etats-Unis et dans d’autres pays. Les produits portant les marques SPARC sont basés sur une architecture développée par Sun
Microsystems, Inc.UNIX est une marques déposée aux Etats-Unis et dans d’autres pays et licenciée exclusivement par X/Open Company,
Ltd.Législation en matière dexportations. Les Produits, Services et données techniques livrés par Sun peuvent être soumis aux contrôles
américains sur les exportations, ou à la législation commerciale dautres pays. Nous nous conformerons à lensemble de ces textes et nous
obtiendrons toutes licences dexportation, de ré-exportation ou dimportation susceptibles dêtre requises après livraison à Vous. Vous
nexporterez, ni ne ré-exporterez en aucun cas à des entités figurant sur les listes américaines dinterdiction dexportation les plus courantes,
ni vers un quelconque pays soumis à embargo par les Etats-Unis, ou à des contrôles anti-terroristes, comme prévu par la législation
américaine en matière dexportations. Vous nutiliserez, ni ne fournirez les Produits, Services ou données techniques pour aucune utilisation
finale liée aux armes nucléaires, chimiques ou biologiques ou aux missiles.
LA DOCUMENTATION EST FOURNIE “EN L’ETAT” ET TOUTES AUTRES CONDITIONS, DECLARATIONS ET GARANTIES
EXPRESSES OU TACITES SONT FORMELLEMENT EXCLUES, DANS LA MESURE AUTORISEE PAR LA LOI APPLICABLE, Y
COMPRIS NOTAMMENT TOUTE GARANTIE IMPLICITE RELATIVE A LA QUALITE MARCHANDE, A L’APTITUDE A UNE
UTILISATION PARTICULIERE OU A L’ABSENCE DE CONTREFAÇON.
CE MANUEL DE RÉFÉRENCE DOIT ÊTRE UTILISÉ DANS LE CADRE D’UN COURS DE FORMATION DIRIGÉ PAR UN
INSTRUCTEUR (ILT). IL NE S’AGIT PAS D’UN OUTIL DE FORMATION INDÉPENDANT. NOUS VOUS DÉCONSEILLONS DE
L’UTILISER DANS LE CADRE D’UNE AUTO-FORMATION.
Please
Recycle
Table of Contents
About This Course .................................................................Preface-i
Course Goals............................................................................ Preface-i
Course Map..............................................................................Preface-ii
Topics Not Covered...............................................................Preface-iii
How Prepared Are You?.......................................................Preface-iv
Introductions ........................................................................... Preface-v
How to Use Course Materials ..............................................Preface-vi
Conventions ...........................................................................Preface-vii
Typographical Conventions ..................................... Preface-viii
Managing Services With the Service Management Facility
(SMF)..................................................................................................1-1
Objectives ........................................................................................... 1-1
Additional Resources ........................................................................ 1-3
The Service Management Facility.................................................... 1-4
Features ...................................................................................... 1-4
The SMF Architecture............................................................... 1-4
Services ...................................................................................... 1-6
Writing a Service Manifest..................................................... 1-14
Example New Service Script ................................................ 1-23
The /usr/share/lib/xml/dtd/service_bundle.dtd
File ............................................................................................. 1-29
Managing Services .................................................................. 1-29
Troubleshooting ...................................................................... 1-43
Example of Adding a Service to startd ............................. 1-51
Example of Adding a Service to inetd................................ 1-53
Exercise: Listing, Enabling, and Disabling Services.................... 1-56
Preparation............................................................................... 1-56
Task ........................................................................................... 1-56
Exercise: Implementing an SMF Service....................................... 1-58
Preparation............................................................................... 1-58
Task ........................................................................................... 1-58
Exercise: Implementing an SMF inetd Service ......................... 1-60
vii
Copyright 2006 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services, Revision A
Preparation............................................................................... 1-60
Task ........................................................................................... 1-60
Exercise: Creating Your Own Services.......................................... 1-62
Preparation............................................................................... 1-62
Task ........................................................................................... 1-62
Exercise Summary............................................................................ 1-64
Exercise Solutions: Listing, Enabling, and Disabling
Services .............................................................................................. 1-65
Task ........................................................................................... 1-65
Exercise Solutions: Implementing an SMF Service ..................... 1-69
Task ........................................................................................... 1-69
Exercise Solutions: Implementing an SMF inetd Service........ 1-70
Task ........................................................................................... 1-70
Exercise Solutions: Creating Your Own Services ........................ 1-72
Task ........................................................................................... 1-72
Introducing the Solaris OS Directory Hierarchy ........................... 2-1
Objectives ........................................................................................... 2-1
System Directory Changes................................................................ 2-4
In-Memory versus On-disk System Directories ................... 2-4
Directory Name Changes and New/Old Directories.......... 2-5
Managing Local Disk Devices......................................................... 3-1
Objectives ........................................................................................... 3-1
Listing a System’s Devices................................................................ 3-4
The format Command............................................................. 3-4
Multiterabyte Volume Support With EFI Disk Labels ........ 3-7
Reconfiguring Devices .................................................................... 3-11
/devices and /dev Directory Link Changes ..................... 3-11
Managing the Solaris OS File System............................................ 4-1
Objectives ........................................................................................... 4-1
Pseudo File Systems .......................................................................... 4-4
Pseudo File Systems in the /etc/vfstab File...................... 4-4
Multiterabyte UFS File Systems....................................................... 4-5
UFS Logging Enabled by Default ........................................... 4-6
Logging and the /etc/vfstab File........................................ 4-7
New mount Command Flags............................................................ 4-8
Installing the Solaris OS.................................................................. 5-1
Objectives ........................................................................................... 5-1
Installation Methods.......................................................................... 5-4
Solaris 10 OS Installation and Upgrade Options.................. 5-4
Solaris Installation Command Line Interpreter (CLI) ......... 5-4
viii Make the Transition to the Solaris™ 10 Operating System

Solaris WAN Boot ..................................................................... 5-5
Installation Requirements for the Solaris 10 OS ............................ 5-6
Solaris 10 OS Hardware Requirements for Installation ...... 5-6
Memory Requirements for Display Options During
Installation............................................................................... 5-7
Installation Media ..................................................................... 5-9
Solaris OS Software Groups .................................................... 5-9
Specific Configuration Changes During Text-Based
Solaris Installation................................................................... 5-10
Solaris x86/x64 Installation and GRUB ........................................ 5-12
Influencing Boot Behavior .................................................... 5-17
Introducing the Fundamentals of Package and Patch
Administration ..................................................................................6-1
Objectives ........................................................................................... 6-1
Longer Package Names..................................................................... 6-4
Signed Packages and Patches........................................................... 6-5
Solaris 10 OS Patch Access Policy.................................................... 6-7
Introducing the Sun Update Connection ....................................... 6-8
Administering Patches ............................................................. 6-9
Sun Update Connection Modes ........................................... 6-10
Using Sun Update Manager ........................................................... 6-20
Establishing a Sun Online Account ...................................... 6-20
Obtain a Sun Service Plan (Optional)................................... 6-20
Downloading and Installing the Sun Update
Connection Client Software................................................... 6-21
Starting Sun Update Manager For the First Time .............. 6-21
Installing Updates With the Sun Update Manager..................... 6-30
Setting Sun Update Manager Client Preferences ........................ 6-32
Sun Update Connection Proxy....................................................... 6-33
Registration .............................................................................. 6-33
Obtaining, Installing and Initially Configuring the
Sun Update Connection Proxy.............................................. 6-33
Configuring Clients to Use the Sun Update Connection
Proxy .................................................................................................. 6-36
Patch Admininstration From the Command Line (CLI) ............ 6-38
Using the smpatch Command ....................................................... 6-40
Phases for Applying Updates ............................................... 6-40
Example Commands .............................................................. 6-41
Configuring the Patch Management Environment..................... 6-46
Using the Update Policy for Applying Updates ................ 6-47
Example of Using the Update Policy ................................... 6-50
Working With Multiple Updates.......................................... 6-56
Working With Multiple Systems .......................................... 6-57
Authorization and Authentication ....................................... 6-57
ix
Installing Patch Clusters ................................................................. 6-59
Further Information......................................................................... 6-64
Introducing the Sun Update Connection Hosted Web
Application ....................................................................................... 6-65
Using the Sun Update Connection Hosted Web
Application ....................................................................................... 6-67
Leveraging the Systems Affected Function......................... 6-75
Performing User Administration .................................................... 7-1
Objectives ........................................................................................... 7-1
Relevance............................................................................................. 7-2
Performing User Administration..................................................... 7-4
Managing User Accounts......................................................... 7-4
Miscellaneous Items................................................................. 7-5
Changes in Command-Line Tools ................................................... 7-6
Using the smuser Command .................................................. 7-7
Using the smgroup Command ............................................. 7-11
Changes in GUI Tools ..................................................................... 7-13
Introducing the Solaris Management Console ................... 7-13
Performing System Security........................................................... 8-1
Objectives ........................................................................................... 8-1
Relevance............................................................................................. 8-2
Controlling System Access ............................................................... 8-4
File Transfer Protocol (FTP) Access........................................ 8-4
System Files That Store User Account Information ............. 8-6
Password Management............................................................ 8-7
Configuring and Using Printer Services........................................ 9-1
Objectives ........................................................................................... 9-1
Relevance............................................................................................. 9-2
Network Printing Fundamentals..................................................... 9-4
Printer Filters ............................................................................. 9-4
Printer Tools........................................................................................ 9-6
GUI Tools ................................................................................... 9-6
Command Line Tools ............................................................... 9-9
Other Changes in Functionality..................................................... 9-10
Directory and File Locations ................................................. 9-10
Print Requests From the Network ........................................ 9-11
Describing Network Basics........................................................... 10-1
Objectives ......................................................................................... 10-1
Additional Resources ...................................................................... 10-3
Interface Configuration ................................................................... 10-4
Interface Files........................................................................... 10-4
x Make the Transition to the Solaris™ 10 Operating System

Changing the System Host Name ....................................... 10-7
Describing the Client-Server Model .................................... 10-8
Managing Crash Dumps, Core Files and Paging.........................11-1
Objectives ......................................................................................... 11-1
Changing the Core File Configuration ................................ 11-6
Paging .............................................................................................. 11-12
Multiple Page Size Support (MPSS) ................................... 11-12
Configuring NFS .............................................................................12-1
Objectives ......................................................................................... 12-1
NFSv4 (New With Solaris 10)......................................................... 12-4
Pseudo-File System................................................................. 12-5
The /etc/default/nfs file ............................................... 12-14
SMF Effects on NFS ............................................................. 12-16
NFS Server and Client Daemon Recap ............................. 12-19
Displaying NFS Mounted Resources ................................ 12-20
NFS Server Logging.............................................................. 12-20
Configuring AutoFS .......................................................................13-1
Objectives ......................................................................................... 13-1
Special Mountings............................................................................ 13-4
New AutoFS Configuration File .......................................... 13-5
Configuring Solaris Volume Manager Software ..........................14-1
Objectives ......................................................................................... 14-1
Solaris Volume Manager Concepts ............................................... 14-4
The State Database Replicas ........................................................... 14-5
Creating the State Database................................................... 14-6
Configuring RAID-0 ...................................................................... 14-17
RAID-0 Striped Volumes .............................................................. 14-18
Creating a RAID-0 Volume ................................................ 14-20
Configuring RAID-1 ...................................................................... 14-34
Building a Mirror of the Root (/) File System............................ 14-37
The Scenario.......................................................................... 14-38
Creating The RAID-0 Volumes ........................................... 14-38
Creating The RAID-1 Volume............................................. 14-50
Unmirroring the Root (/) File System............................... 14-67
The metassist Command ................................................. 14-69
Exercise: Mirroring the Root (/) File System ............................. 14-71
Preparation............................................................................. 14-71
Task ........................................................................................ 14-71
Exercise Summary.......................................................................... 14-75
Exercise Solutions .......................................................................... 14-76
xi
Exercise: Mirroring the Root (/) File System .................... 14-76
Task ......................................................................................... 14-76
Controlling Access and Configuring System Messaging .......... 15-1
Objectives ......................................................................................... 15-1
Configuring System Messaging ..................................................... 15-4
The loghost Setting ............................................................... 15-4
The /etc/syslog.conf File ................................................ 15-6
Naming Services ............................................................................ 16-1
Objectives ......................................................................................... 16-1
Lightweight Directory Access Protocol (LDAP) ......................... 16-4
LDAP Directory Server .......................................................... 16-4
Changes in the /etc/nsswitch File ............................................. 16-5
The /etc/nsswitch.conf File .................................................. 16-5
The /etc/nsswitch.dns File ................................................... 16-5
The /etc/nsswitch.ldap File................................................. 16-7
The /etc/nsswitch.nis File.................................................... 16-8
Configuring the NIS Domain ......................................................... 16-9
The /var/yp/Makefile File ................................................. 16-9
NIS to LDAP Transition Tool .............................................. 16-10
Configuring the Custom JumpStart Procedure .......................... 17-1
Objectives ......................................................................................... 17-1
Relevance........................................................................................... 17-2
Introducing JumpStart Differences ............................................... 17-4
Boot Services ............................................................................ 17-4
Identification Services ............................................................ 17-5
Configuration Services ........................................................... 17-5
Installation Services ................................................................ 17-5
Examples of the sysidcfg File ............................................. 17-6
Changes to the Profile File ................................................. 17-8
Booting the JumpStart Client ............................................. 17-14
Finish Scripts.......................................................................... 17-14
Performing a Flash Installation .................................................... 18-1
Objectives ......................................................................................... 18-1
Introducing Flash Archives and Installations.............................. 18-4
Creating and Manipulating Flash Archives........................ 18-5
Creating a Flash Archive........................................................ 18-6
Administering a Flash Archive ............................................. 18-8
Using a Flash Archive for Installation ............................... 18-10
Differential Flash Archives ........................................................... 18-18
Creating a Differential Flash Archive ................................ 18-18
xii Make the Transition to the Solaris™ 10 Operating System

Exercise: Creating a Flash Archive .............................................. 18-21
Preparation............................................................................. 18-21
Task ......................................................................................... 18-21
Creating a Flash Archive...................................................... 18-24
Using Live Upgrade........................................................................19-1
Objectives ......................................................................................... 19-1
Introducing Solaris Live Upgrade ........................................ 19-4
Solaris Live Upgrade Process................................................ 19-5
Live Upgrade Commands ..................................................... 19-6
Example Procedure: Live Upgrade and Differential
Flash Archives ......................................................................... 19-7
Live Upgrade and Other Configurations ................................... 19-27
Introducing WANBoot ....................................................................20-1
Objectives ......................................................................................... 20-1
Introducing the Basics of WANboot (New in Solaris 9
Updates) ............................................................................................ 20-4
Advantages of the WAN Boot Procedure ........................... 20-4
Features .................................................................................... 20-5
WAN Boot Changes................................................................ 20-5
The WAN Boot Process ......................................................... 20-7
WAN Boot Server Configuration........................................ 20-11
WAN Boot Troubleshooting................................................ 20-22
Exercise: Configuring WANboot................................................. 20-23
Preparation............................................................................. 20-23
Task 1– Configuring the Apache Web Server.................. 20-25
Task 2– Configuring the WAN Boot and JumpStart
Files ......................................................................................... 20-25
Task 3– Booting the WAN Boot Client .............................. 20-26
Task 1– Configuring the Apache Web Server................... 20-28
Files ........................................................................................ 20-29
Task 3– Booting the WAN Boot Client ............................. 20-34
xiii
Preface
About This Course
Course Goals
Upon completion of this course, you should be able to describe
differences between the Solaris™ 8 or 9 OS and the Solaris 10 OS as they
relate to the administration tasks in the following areas:
● Managing file systems
● Installing software
● Performing system boot procedures
● Performing user and security administration
● Managing network printers and system processes
● Performing system backups and restores
● Describing network basics
● Managingvirtual file systems and core dumps
● Managing storage volumes
● Controlling access and configure system messaging
● Setingt up name services
● Performing advanced installation procedures
Preface-i
Copyright 2006 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A
Course Map
Course Map
The course map enables you to see what you have accomplished and
where you are going in reference to the course goals.
Managing Services
Managing
Services
With the
Service
Management
Facility
Managing File Systems
Introducing Managing
Managing
the Solaris™ Local Disk the Solaris OS
OS Directory File System
Devices
Hierarchy
Installing Software Performing User and Security Administration
Introducing the
Installing Performing Performing
Fundamentals
the User Security
of Package
Solaris OS and Patch Administration Administration
Administration
Managing Printers Describing Network Basics
Configuring Describing
and Using Network
Printer Services Basics
Managing Virtual File Systems and Core Dumps
Managing
Crash Dumps, Configuring Configuring
Core Files, NFS AutoFS
and Paging
Controlling Access
Managing Setting Up
and Configuring
Storage Volumes Naming Services
System Messaging
Configuring Controlling
Solaris Access Using
Volume and Configuring Name
Manager System Services
Software Messaging
Performing Advance Installation Procedures
Configuring Performing a Using Introducing

the Custom Flash Live
JumpStart™ WANBoot
Installation Upgrade
Procedure
Preface-ii Make the Transition to the Solaris™ Operating System

Topics Not Covered
Topics Not Covered

This course does not cover the following topics. Many of these topics are
covered in other courses offered by Sun Educational Services:
● Basic UNIX® commands – Covered in SA-100: UNIX® Essentials
Featuring the Solaris™ 10 Operating System
● The vi editor – Covered in SA-100: UNIX® Essentials Featuring the
Solaris™ 10 Operating System
● Basic UNIX file security – Covered in SA-100: UNIX® Essentials
● Basic system security – Covered in SA-100: UNIX® Essentials
● Hardware or software troubleshooting – Covered in ST-350: Sun™
Systems Fault Analysis Workshop
● System tuning – Covered in SA-400: Enterprise System Performance
Management
● Detailed shell programming – Covered in SA-245: Shell Programming
for System Administrators
● Detailed network administration concepts – Covered in
SA-300: Network Administration for the Solaris™ 10 Operating System
Refer to the Sun Educational Services catalog for specific information and
registration.
About This Course Preface-iii

How Prepared Are You?
How Prepared Are You?

To be sure you are prepared to take this course, as a Solaris 8 or Solaris 9
administrator, can you answer yes to the following questions?
● Can you install and boot the Solaris 10 Operating System (Solaris 10
OS) on a stand-alone workstation?
● Can you implement basic system security?
● Can you add users to the system using the Solaris Management
Console software?
● Can you use the pkgadd command to add software packages?
● Can you monitor and mount file systems?
● Can you manage disk devices and processes?
● Can you perform backups and restorations?
Preface-iv Make the Transition to the Solaris™ Operating System

Introductions
Introductions
Now that you have been introduced to the course, introduce yourself to
the other students and the instructor, addressing the following items:
● Name
● Company affiliation
● Title, function, and job responsibility
● Experience related to topics presented in this course
● Reasons for enrolling in this course
● Expectations for this course.
About This Course Preface-v

How to Use Course Materials
How to Use Course Materials

To enable you to succeed in this course, these course materials contain a
learning module that is composed of the following components:
● Goals – You should be able to accomplish the goals after finishing
this course and meeting all of its objectives.
● Objectives – You should be able to accomplish the objectives after
completing a portion of instructional content. Objectives support
goals and can support other higher-level objectives.
● Lecture – The instructor presents information specific to the objective
of the module. This information helps you learn the knowledge and
skills necessary to succeed with the activities.
● Activities – The activities take oemailsn various forms, such as an
exercise, self-check, discussion, and demonstration. Activities help
you facilitate the mastery of an objective.
● Visual aids – The instructor might use several visual aids to convey a
concept, such as a process, in a visual form. Visual aids commonly
contain graphics, animation, and video.
Preface-vi Make the Transition to the Solaris™ Operating System

Conventions
Conventions
The following conventions are used in this course to represent various
training elements and alternative learning resources.
Icons
Additional resources – Indicates other references that provide additional

information on the topics described in the module.
Demonstration – Indicates a demonstration of the current topic is

1 recommended at this time.
2
3
Discussion – Indicates a small-group or class discussion on the current

topic is recommended at this time.
!
?
Note – Indicates additional information that can help students but is not
crucial to their understanding of the concept being described. Students
should be able to understand the concept or complete the task without
this information. Examples of notational information include keyword
shortcuts and minor system adjustments.
About This Course Preface-vii

Conventions
Typographical Conventions
Courier is used for the names of commands, files, directories,
programming code, and on-screen computer output; for example:
Use ls -al to list all files.
system% You have mail.
Courier bold is used for characters and numbers that you type; for
example:
To list the files in this directory, type:
# ls
Courier italics is used for variables and command-line placeholders

that are replaced with a real name or value; for example:
To delete a file, use the rm filename command.
Courier italic bold is used to represent variables whose values are to

be entered by the student as part of an activity; for example:
Type chmod a+rwx filename to grant read, write, and execute
rights for filename to world, group, and users.
Palatino italics is used for book titles, new words or terms, or words that
you want to emphasize; for example:
Read Chapter 6 in the User’s Guide.
These are called class options.
Preface-viii Make the Transition to the Solaris™ Operating System

Conventions
Notes to the Instructor

There are no overheads for this course.
If you are teaching an LVC, display the PDF file of the Student Guide in the whiteboard area.
Total
Lecture Lab
Module Time
(Minutes) (Minutes)
(Minutes)
About This Course 40 40
Managing Services With the Service Management 90 75 165
Facility (SMF)
Introducing the Solaris OS Directory Hierarchy 15 0 15
Managing Local Disk Devices 15 0 15
Managing the Solaris OS File System 15 0 15
Installing the Solaris OS 30 0 30
Introducing the Fundamentals of Package and 120 0 120
Patch Administration
Performing User Administration 30 0 30
Performing System Security 15 0 15
Configuring and Using Printer Services 15 0 15
Describing Network Basics 15 0 15
Managing Crash Dumps, Core Files and Paging 15 00 15
Configuring NFS 30 0 30
Configuring AutoFS 15 0 15
OK Configuring Solaris Volume Manager Software 90 60 150
Controlling Access and Configuring System 15 0 15
Messaging
Naming Services 15 0 15
Configuring the Custom JumpStart Procedure 15 0 15
Performing a Flash Installation 30 45 75
Using Live Upgrade 60 0 60
About This Course Preface-ix

Conventions
Total
Lecture Lab
Module Time
(Minutes) (Minutes)
(Minutes)
Introducing WANBoot 60 90 150
Preface-x Make the Transition to the Solaris™ Operating System

Module 1
Managing Services With the Service

Management Facility (SMF)
Objectives
This module is an overview of the service management features included
in the Solaris™ 10 Operating System (Solaris 10 OS).
Upon completion of this module, you should be able to identify features

of the Service Management Facility (SMF).
1-1
Objectives
Relevance
Present the following questions to stimulate the students and get them thinking about the issues and topics
presented in this module. While they are not expected to know the answers to these questions, the answers
should be of interest to them and inspire them to learn the material presented in this module.
Discussion – The following question is relevant to understanding the

SMF features in the Solaris 10 OS
!
?
● How are services started and managed in the Solaris 10 OS?
1-2 Make the Transition to the Solaris™ 10 Operating System

Additional Resources
Additional resources – The following references provide additional

information on the topics described in this module:
● System Administration Guide: Basic Administration, PN 817-1985
● System Administration Guide: Advanced Administration, PN 817-0403
Managing Services With the Service Management Facility (SMF) 1-3

The Service Management Facility

The Service Management Facility (SMF) delivers a unified Solaris service
configuration infrastructure capable of accurately modeling any Solaris
service and its interaction with Solaris and other services. Rather than the
problematic use of rc scripts, SMF starts services in parallel according to
dependencies, which allows the system to boot faster, and reduces
dependency conflicts.
Features
An SMF infrastructure consisting of a service configuration repository,
process re-starter, and administrative CLI utilities along with supporting
kernel functionality is available, enabling Solaris services to express the
following:
● Restart requirements
● Requirements for the presence of prerequisite services and system
facilities (such as networking)
● Requirements for identity and privileges for various tasks
● Configuration settings per instance
Solaris services are modeled by describing them in terms of an SMF

schema and associated service methods. For existing services converted to
SMF services, compatibility or conversion of legacy configuration files is
handled on a service-by-service basis. Once service descriptions are
bootstrapped into SMF, instances of such services can be created, started,
stopped, and status collected by the infrastructure. This saves time and
system administration effort.
The SMF Architecture

The service management facility is a mechanism for providing service
start and restart contracts. The goals of the project are the following:
● Supply a mechanism to formalize relationships between services
● Provide a unified repository for configuration of service startup
behavior
● Allow Solaris to start and restart services automatically over the
lifetime of a Solaris instance

Figure 1-1 shows the main components of SMF.
Management Observability
inet-service Service
Agent Agent
inetd(1M)
Repository API
svc.configd(1M) svc.startd(1M)
init(1M)
Process Repository
Contract Client
Kernel
Figure 1-1 The SMF Components
The main components of SMF are the following:

● Service abstraction
● Repository of service information
● Daemon to access the repository (svc.configd)
● APIs for access to the repository
● Master restarter daemon (svc.startd)
● Delegated restarters (for example, inetd)
● Command-line tools

Services
The fundamental unit of administration in SMF is the service. Generically,
a service is an entity which provides a known list of capabilities to other
local and remote services. The categories of services are:
● milestone – Synthetic services for clean dependency statements
● device – General device services
● system – Services concerned with host-centric, non networked
capabilities
● system/security – Low-level host-centric services implementing
security facilities
● network – Services concerned with host-centric, network
infrastructure capabilities
● application – General software services
● application/management – Services implementing management
facilities
● application/security – Services implementing high-level security
facilities
● site – Services implementing site-specific software
● platform – Services implementing platform-specific software
The milestone service is special in that there is no software to run in

connection with the service. A milestone corresponds to the system
arriving at a defined set of capabilities. The milestones are used to replace
the run levels used with the init command and the rc*.d scripts. The
current milestones are:
● milestone/name-services:default – A milestone for use by
services who can not run until a name service is running.
● milestone/devices:default – A milestone for use by services that
have a dependency on local devices being available.
● milestone/single-user:default – A milestone roughly
equivalent to single-user mode or init run level one.
● milestone/multi-user:default – A milestone roughly equivalent
to init run level two.
● milestone/multi-user-server:default – A milestone roughly
equivalent to init run level three.

Information about services and their state is kept in the repository. This
information can be accessed using the svcs command.
sys-01# svcs
STATE STIME FMRI
legacy_run 9:17:58 lrc:/etc/rcS_d/S10pfil
legacy_run 9:17:58 lrc:/etc/rcS_d/S29wrsmcfg
legacy_run 9:17:58 lrc:/etc/rcS_d/S35cacheos_sh
legacy_run 9:17:58 lrc:/etc/rcS_d/S41cachefs_root
legacy_run 9:17:58 lrc:/etc/rcS_d/S55fdevattach
legacy_run 9:18:09 lrc:/etc/rc2_d/S10lu
legacy_run 9:18:09 lrc:/etc/rc2_d/S20sysetup
legacy_run 9:18:09 lrc:/etc/rc2_d/S40llc2
legacy_run 9:18:09 lrc:/etc/rc2_d/S42ncakmod
legacy_run 9:18:09 lrc:/etc/rc2_d/S47pppd
legacy_run 9:18:10 lrc:/etc/rc2_d/S65ipfboot
legacy_run 9:18:10 lrc:/etc/rc2_d/S70sckm
legacy_run 9:18:10 lrc:/etc/rc2_d/S70uucp
. . .
online 9:16:08 svc:/system/svc/restarter:default
online 9:17:12 svc:/milestone/name-services:default
online 9:17:28 svc:/network/loopback:default
online 9:17:29 svc:/network/initial:default
online 9:17:29 svc:/network/physical:default
online 9:17:30 svc:/network/service:default
online 9:17:44 svc:/network/ssh:default
online 9:17:46 svc:/milestone/devices:default
online 9:17:46 svc:/system/device/local:default
online 9:17:55 svc:/system/filesystem/minimal:default
online 9:17:56 svc:/network/rpc/bind:default
online 9:17:56 svc:/network/rpc/keyserv:default
. . .
online 9:55:48 svc:/system/console-login:default
online 13:19:00 svc:/network/telnet:default
offline 9:16:11 svc:/application/print/ipp-listener:default
Solaris uses a URI string called a Fault Managed Resource Identifier

(FMRI ) to identify system objects for which advanced fault and resource
management capabilities are provided. Services managed by SMF are
assigned FMRI strings prefixed with the scheme name svc or lrc. The
svc scheme is the type used for services that are SMF aware. The lrc
scheme is used to support legacy services which have not been migrated
to SMF.

A service provides a known list of capabilities. There are times when it is

helpful to run multiple instances of a service (for example a Web Server
serving multiple ports). SMF provides for service instances. The first
instance of a service is normally tagged the default instance. For example,
svc:/network/rpc/bind:default identifies the default instance of the
/network/rpc/bind service.
The following is an example of a service with multiple instances:

sys-01# svcs sysidtool
STATE STIME FMRI
online 9:17:56 svc:/system/sysidtool:net
online 9:17:58 svc:/system/sysidtool:system
Service States
A service can be in one of the following states (see Figure 1-2):

● Uninitialized – Uninitialized is the initial state for all instances.
Services in this state are not yet running, and their configuration
data is unread.
● Offline – Instances are in the offline state when their configuration
has been read but they aren’t running. Instances remaining in this
state are usually the victim of unsatisfied dependencies or errors
occurring during the start method.
● Online – The online state describes a running service with all
dependencies met.
● Disabled – The disabled state is a result of the service instance being
marked as disabled in the configuration data or explicitly disabled
by the administrator. While the service may be startable, the
administrator must interact with SMF to start the service.
● Degraded – The degraded state is when the service instance still
meets most of its criteria for execution but has some limited set of
failures which identify it as degraded.
● Maintenance – The maintenance state indicates the service is
unavailable due to maintenance activities or requires administrator
intervention. The maintenance state can be reached either by explicit
administrative request or through an internal action by SMF in
response to a non-transient error of the service or the state machine.

Services transition from one state to another either due to explicit

administrative action or by SMF in response to dependency changes or
error conditions. Figure 1-2 shows the SMF service states.
Service put in maintenance state
Service
disabled
UNINITALIZED
Can’t read
config
Start
Administrator service Re-read
intervention config data
Re-read
config data
Dependency
not met or Service marked
start failed disabled
MAINTENANCE OFFLINE DISABLED
Unresolvable error Service enabled
or thresholds reached by admin
Service shutdown,
restart or disable
Unresolvable error or
thresholds reached
Dependency met
and service enabled
ONLINE
Service shutdown,
restart or disable
Refresh
Unresolvable error or
thresholds reached Partial failure of
service or dependency
Dependencies staisfied No improveme

and service is healthy in service
DEGRADED
Figure 1-2 SMF Service States

Service Components
Services are composed of several components, for example:

● A mechanism to start and stop the service
● A mechanism to monitor and restart services
● A location for configuration data (properties)
● A location for error messages
SMF organizes services using profiles and manifests. A profile is used to

set general settings for a system as to what services need to run. The
profile files are usually found in the /var/svc/profile directory.
A manifest is used to describe a single service or set of related services. It

is possible to specify configuration parameters for the service in the
manifest as properties or property groups, or to have configuration
parameters in a separate file. The manifest files are in the
/var/svc/manifest directory tree and the profiles are in the
/var/svc/profile tree. Both profiles and manifests are xml type files.
Most of the class should be familiar with HTML. As necessary describe how tags match their beginning and
ending. This is particularly important when looking at manifest files. Do not get too detailed about the
contents of this file. Emphasize instances.
The following is an example of the generic_open profile:

sys-01# cd /var/svc/profile
sys-01# more generic_open.xml
<?xml version='1.0'?>
<!DOCTYPE service_bundle SYSTEM
'/usr/share/lib/xml/dtd/service_bundle.dtd.1'>
...
<service_bundle type='profile' name='generic_open'
xmlns:xi='http://www.w3.org/2003/XInclude' >

<xi:include href='file:/var/svc/profile/name_service.xml' />

<service name='system/coreadm' version='1' type='service'>
<instance name='default' enabled='true'/>
</service>

<service name='system/cron' version='1' type='service'>

</service>
<service name='system/cryptosvc' version='1' type='service'>
</service>
...

<xi:include href='file:/var/svc/profile/inetd_services.xml' />
</service_bundle>
The generic_open profile contains several sections, as indicated by the

comments. (Sometimes a set of services from a separate file is included
with the XML xi:include directive.) Each section lists the services that
should be enabled and their instance name. This profile is always read
when svc.startd(1M) starts.
A manifest is a list of things pertaining to each service. The list contains the
name of the service, the method to start and stop the service, and many
other things. All manifests live in the /var/svc/manifest directory tree.
This directory contains subdirectories that logically group services.

For example, the system console is found under

/var/svc/manifest/system/console-login.xml and telnet is found
under /var/svc/manifest/network/telnet.xml. The current
directories found in the /var/svc/manifest directory are as follows:
● application
● device
● milestone
● network
● platform
● site
● system
The following is a copy of the system/coreadm.xml manifest:
Do not get too detailed about the contents of this file. Emphasize dependencies and properties.
...
<service_bundle type=’manifest’ name=’SUNWcsr:coreadm’>
<service
name=’system/coreadm’
type=’service’
version=’1’>
<create_default_instance enabled=’false’ />
<single_instance />
<dependency
name=’usr’
type=’service’
grouping=’require_all’
restart_on=’none’>
<service_fmri value=’svc:/system/filesystem/minimal’ />
</dependency>
<exec_method
type=’method’
name=’start’
exec=’/usr/bin/coreadm -u’
timeout_seconds=’60’ />

<exec_method
type=’method’
name=’stop’
exec=’:true’
<property_group name=’startd’ type=’framework’>

<propval name=’duration’ type=’astring’
value=’transient’ />
</property_group>
<stability value=’Unstable’ />
<template>
<common_name>
<loctext xml:lang=’C’>
System-wide core file configuration
service
</loctext>
</common_name>
<documentation>
<manpage
title=’coreadm’
section=’1M’
manpath=’/usr/share/man’ />
</documentation>
</template>
</service>
</service_bundle>
The use of the tags is as follows:

● service_bundle – Tag used to open and close the body of the
manifest. The first portion of the name component specifies the
package from which this service comes.
● service – Tag to specify services available in this manifest. This tag
occurs only once in most manifests but may appear more than once
(see the /var/svc/manifest/system/device/devices-local.xml
file).
● dependency – Tag used to specify services on which this service is
dependent. There may be multiple dependency tags.

● exec_method – Tag used to specify a method. A method defines

what is used to execute the start and stop of a service. The
recommended location of a method is /lib/svc/method/svc-name
for integrated products and /basedir/method/svc-name for added
applications.
● property_group – Tag used to specify values for property groups.
Properties are grouped to make it easier to specify only the
properties appropriate to the service being defined.
All manifests in the /var/svc/manifest directory tree are read by

svc.startd as it starts. If new services are found, they are imported into
the repository.
Configuration information for services is maintained in the repository.

This repository is accessed using the svc.configd daemon or through the
use of the API interface. The disk copy of the configuration information is
kept in the /etc/svc/repository.db file. SMF keeps snapshots of
configuration changes so that a change can be backed out using the
svccfg(1M) command if it does not work. As a last resort backup, the
initial repository is kept in the /lib/svc/seed/global.db file. This file
can be accessed by booting with the boot -m seed command (see
kernel(1M)).
Error logs are found in the /var/svc/log directory. This directory

contains a file for each service instance which has created log entries.
Perhaps the easiest way to search for problems is to search for the words
ERROR and WARNING in these log files.
Writing a Service Manifest

In order to compose your own manifest, please refer to the following
sections for some guidelines.
Name Your Service
General service categories for naming of services are provided, but these
categories aren’t used by the system. They help the administrator in
identifying the general use of the service.
These categories are shown in /var/svc/manifest, and include:

● application – higher level applications such as Apache
● milestone – collections of other services such as name services

● platform – platform-specific services such as Dynamic

Reconfiguration daemons
● system – Solaris system services such as coreadm
● device – device-specific services
● network – network/internet services such as protocols
● site – site specific descriptions
The service name describes what is being provided and includes both any
category identifier and the actual service name, separated by forward
slashes (/). Service names should usefully identify the service being
provided by the administrator.
The instance name describes any specific features about the instance. Most
services deliver a default instance. Some services such as Oracle may
want to create instances based on administrative configuration choices.
Services that are shipped as part of a product or generally extend beyond

a site-specific definition should include either the stock symbol or Java-
style reversed domain prefix followed by a comma as part of the category
or service name for uniqueness.
As an example of the naming conventions above, the cron service

specifies as its prelude:
<service
name=’system/cron’
type=’service’
version=’1’>
Identify Multiple Instances
If multiple binaries of your service running simultaneously on the system

will cause an error, define it as a single_instance service. This tag tells
the restarter to not start up multiple service instances simultaneously,
regardless of administrative configuration.
Most configuration and system services require single_instance tags.

Services such as web servers or databases which could run multiple
configurations simultaneously (such as use a different database source or
run on a different port) should not be specified as single_instance.

To specify a single instance service, include after the service block:

<single_instance />
Identify Your Service Model
In order to provide restart capabilities for services with different run-time

characteristics, SMF provides a variety of models for services. Currently,
these models are provided by the svc.startd and inetd restarters.
Additional models may be provided in the future by either these
restarters or by additional restarters. The svc.startd restarter provides
three distinct models for service processes:
● Transient services – These are often configuration services which
require no long-time running processes in order to provide service.
Common transient services take care of boot-time cleanup or load of
configuration properties into the kernel. Transient services are also
sometimes used to overcome difficulties in conforming to the
method requirements for contract or wait services. This is not
recommended and should be considered a stop gap measure.
● Wait services – These run for the lifetime of the child process, and are
restarted when that process exits.
● Contract services – These are the standard system daemons. They
require processes that run forever once started in order to provide
service. Death of any processes in a contract service is considered a
service error, which will cause the service to restart.
The default service model is contract, but may be modified by specifying

the following in your service manifest for a transient service:
<propval name=’duration’ type=’astring’ value=’transient’ />
</property_group>
Identify Start and Stop Methods
SMF interacts with services primarily by its methods. The stop and start
methods must be provided for services managed by svc.startd. The
service can either directly invoke a service binary, or a script which
invokes a more complex setup. The refresh method is optional for
svc.startd-managed services. Different restarters may require different
methods.
Existing init scripts can easily serve as the basis for service methods. The
following rules and guidance for the methods supported by svc.startd:

All Methods
● Shell scripts should include /lib/svc/share/smf_include.sh to

gain access to convenience functions and return value definitions.
● Failures must cause explicit error returns. All non-0 values are
considered errors. Additional information (for example, to avoid
restart due to configuration errors) may be provided to the restarter
with the SMF_EXIT_* definitions.
● Methods should emit log messages on failure. They will be logged
by svc.startd to the service log file so the administrator can
determine cause for failure.
● The following keywords available for all method definitions:
● :true – simply returns success to the restarter.
● :kill – kills all processes started by your service’s start
method. The list of all processes is determined by the service’s
contract.
● Timeouts must be provided for all methods. The timeout should be
defined to be the maximal amount of time in seconds that your
method might take to run on a slow system or under heavy load. A
method which exceeds its timeout will be killed. If the method could
potentially take an unbounded amount of time, such as a large
filesystem fsck, an infinite timeout may be specified as 0.
Start Methods
● A start method is required for all svc.startd-managed services.

● Start methods run only when the service is enabled and
dependencies are met. Therefore, start methods should exit with
SMF_EXIT_ERR_CONFIG if the service cannot come online due to any
configuration error.
● If your service is of type contract, the start method must leave your
daemon running if returning success because exit of all processes
will cause the service to be restarted.

● For contract and transient services, the start method should not
return success until the service is being provided. Note that this is
true for daemons as well. Daemons should not fork() then exit()
from their initial process, they should wait to return until startup
errors have been accumulated and can be reported. Many init scripts
previously started up the daemon and return immediately, counting
on the fact that the serial boot took some time to start dependent
services. Now that dependent services are started precisely, and
often immediately after your service returns successfully from its
start method, imprecise semantics are not acceptable.
● If code changes to the daemon/service can not be made, a positive
test for service is required before returning success. If no other
options are available, insert an appropriate long sleep() before
successful return.
Stop Methods
● A stop method is required for all svc.startd-managed services.

● Stop methods run in a number of different scenarios including when
a dependency goes offline, when a service fails, and when an
administrator requests to disable or restart the service.
● Thus, stop methods should return success if the service is no longer
running after execution is complete, even if the service was not
running when the execution started. This is because stop methods
may be called in error scenarios.
Refresh Methods
● Refresh methods are optional for all svc.startd-managed services.

● Any defined refresh method has very precise semantics; it must
reload appropriate configuration parameters from the repository or
other configuration source without interrupting service. It must not
cause exit of the existing processes for contract or wait services.
Expecting user interaction (such as console input) is strongly discouraged

as part of the service methods. Scripts which do so will not work without
modification.
A set of method tokens are available for use in method specification for
commonly used property values. A comprehensive list is available in
smf_method(5).

The default method environment is inherited from init(1M) with the

PATH set to /usr/sbin:/usr/bin. Variables beginning with SMF_ are
reserved for framework use. The SMF_ variables defined in smf_method(5)
are provided to all methods including; SMF_FMRI, SMF_METHOD, and
SMF_RESTARTER.
Finally, each method may specify a method context to define system and
security attributes used during method execution. It is recommend that
long-running services are started with reduced privileges and safe uids
and gids, when possible. The following is an example of a start method:
<exec_method
type=’method’
name=’start’
exec=’/lib/svc/method/svc-cron’
timeout_seconds=’60’>
<method_context>
<method_credential user=’root’ group=’root’ />
</method_context>
</exec_method>
Determine Faults to be Ignored
If your service is poorly behaved or it might spawn poorly behaved sub

processes, inform the restarter that certain errors are expected and do not
constitute service faults. For instance, you can specify that core dumps
from sub processes should not be considered errors or that external kill
signals are not errors:
<propval name=’ignore_error’ type=’astring’ value=’core,signal’ />
</property_group>
Identify Dependencies
This is the most difficult part of service conversion, as most dependencies

are not explicitly stated. There are two different types of dependencies;
file and service dependencies.
First, identify what other services are required for your service to start.
For example, does your service require the network to be plumbed, local
devices to be configured, or name services to be available? Once you’ve
decided what your service is dependent on, specify the fault propagation
model:

● none – The dependency is required only for startup. No fault or

administrative action requires restart.
● fault – Restart if the dependency has a fault such as core dump or a
system fault.
● restart – If the dependency is restarted, so should the service.
● refresh – If the dependency is refreshed because its configuration is
changed, the service should be restarted.
The following values correspond to the ability to handle restart of the

specified dependency utilizing the restart_on property. Dependencies
may be specified in groupings such as:
● require_all – All in the group must be online or degraded before
the dependency is started.
● require_any – Any one of the services in the group must be online
or degraded before the dependency is started.
● optional_all – If the services are enabled, able to run and not in
maintenance, they must be online or degraded before the
dependency is started
● exclude_all – If the service is enabled and online or degraded, the
dependency should not be started.
If your service is dependent on a legacy script, it is recommended to

either convert, or encourage your vendor to convert, the legacy script to
an SMF service. Otherwise, specify that the service has a dependency on
the script in the milestone. This will never propagate errors from the
legacy service, so it should be a restart_on=none dependency.
Don’t forget to write a comment about the dependencies to help future

maintainers:

<dependency
name=’nameservice’
type=’service’
<service_fmri value=’svc:/milestone/name-services’ />
<dependency>

Identify Dependents
If you wish to deliver a service which is a dependency of another service

that you do not supply, specify that information in your manifest so that
you do not have to modify a manifest you do not own. Specifying
dependents are an easy way to have your service run before a service
delivered by Sun, however there is no way to specify a dependent on a
legacy script so all dependents need to be converted to SMF. To avoid
naming conflicts, prefacing your dependent name with the name of your
service.
For example, if you’re delivering a service (mysvc) that must start before
syslog, use the following:
<dependent
name=’mysvc_syslog’
grouping=’optional_all’
<service_fmri value=’svc:/system/system-log’ />
<dependent>
Insert Your Service Into a Milestone
If your service was previously delivered into an rc*.d directory and

other services depend on it, create a milestone corresponding to your
previous delivery location as a dependent.
For example, if your service was previously started at run level 2, this
clause will make sure that run level 2 is not considered complete until
your service has started:
<dependent
name=’mysvc_multi-user’
<service_fmri value=’svc:/milestone/multi-user’ />
<dependent>
Create Default Instance
If your service does not require additional administrative intervention for

configuration before it starts the first time, configure a default instance for
your service. If the instance has no configuration differences from the
service, this can easily be done:

Alternatively, you can explicitly define the instance:

<instance name=’default’ enabled=’false’>

</instance>
It is recommend that all instances be delivered as disabled unless they

are critical to boot the system.
Create Template Information
Document at least a common name in the C locale and a man page

reference. The common name should be short (40 characters or less),
avoid punctuation and capital letters aside from trademarks like Solaris,
and do not use the word service. Do distinguish between client and server
services.
The following information is presented by various forms of svcs(1) to

provide the administrator with concise detail about your service and
where to get more technical information. Common names may be
localized.
<template>
<common_name>
Solaris fault manager
<loctext>
<common_name>
<documentation>
<manpage title=’fmd’ section=’1M’ manpath=’/usr/share/man’ />
<documentation>
</template>

Example New Service Script

You can create new scripts to start and stop additional processes or
services to customize a system.
For example, to eliminate the requirement for a manual start of a database

server, you could create a script to start the database server automatically
after the appropriate network services have started.
You could then create another script to terminate this service and shut
down the database server before the network services are stopped.
The correct procedure is to incorporate the new service into the SMF. This
procedure can be quite complex. The general steps required are detailed
in the following list:
● Determine the process for starting and stopping your service.
● Establish a name for the service, and the category this service falls
into.
● Determine whether your service runs multiple instances.
● Identify any dependency relationships between this service and any
other services.
● If a script is required to start and stop the process, create the script
and place it in a local directory such as /usr/local/svc/method.
● Create a service manifest file for your service. This file describes the
service and any dependency relationships. Service manifests are
pulled into the repository either by using the svccfg command or
at boot time.
● Incorporate the script into the SMF using the svccfg utility.

The following displays an example:

# vi /usr/local/svc/method/newservice
#!/sbin/sh
#
# Copyright 2004 Sun Microsystems, Inc. All rights reserved.
# Use is subject to license terms.
#
# ident "@(#)newservice 1.14 04/08/30 SMI"
case "$1" in
’start’)
/usr/bin/newservice &
;;
’stop’)
/usr/bin/pkill -x -u 0 newservice
;;
*)
echo "Usage: $0 { start | stop }"
;;
esac
exit 0
# chmod 544 /usr/local/svc/method/newservice
# cd /var/svc/manifest/site
# vi newservice.xml
<?xml version="1.0"?>
"/usr/share/lib/xml/dtd/service_bundle.dtd.1">

<service_bundle type=’manifest’ name=’OPTnew:newservice’>
<service
name=’site/newservice’
type=’service’
version=’1’>
<single_instance/>

<dependency
name=’usr’
type=’service’
<service_fmri value=’svc:/system/filesystem/local’ />
</dependency>
<dependent
name=’newservice’
</dependent>
<exec_method
type=’method’
name=’start’
exec=’/lib/svc/method/newservice start’
<exec_method
type=’method’
name=’stop’
exec=’/lib/svc/method/newservice stop’

<propval name=’duration’ type=’astring’ value=’transient’
/>
</property_group>
<instance name=’default’ enabled=’true’ />
<template>
<common_name>
New service
</loctext>
</common_name>
</template>
</service>

</service_bundle>
The following describes the entries in the file:

● Standard header.
● Comment section.

● The name of the service. The type (manifest) indicates a simple
service rather than a milestone, the package providing the service,
and the service name.
<service_bundle type=’manifest’ name=’OPTnew:newservice’>
● Service category, type, name, and version.
<service
name=’site/newservice’
type=’service’
version=’1’>
● Whether multiple instances of the service will run.
<single_instance/>
● The service model to use. The entry shows that the service will be
started by svc.startd. Transient services are started once and not
restarted.
/>
</property_group>
● How the service is started and stopped.
<exec_method
type=’method’
name=’start’
exec=’/lib/svc/method/newservice start’

<exec_method
type=’method’
name=’stop’
exec=’/lib/svc/method/newservice stop’
● Define any dependencies for this service. The first entry states that
the newservice requires the filesystem/local service.
<dependency
name=’usr’
type=’service’
<service_fmri value=’svc:/system/filesystem/local’ />
</dependency>
● The second entry makes sure that your service is associated with the
multi-user milestone and that the multi-user milestone requires this
service.
<dependent
name=’newservice’
</dependent>
● Creating the instance.

<instance name=’default’ enabled=’true’ />

● Creating information to describe the service.
<template>
<common_name>
New service
</loctext>
</common_name>
</template>
The new service (newservice) now needs to be imported into SMF.

This is done by running the svccfg utility:

# svccfg import /var/svc/manifest/site/newservice.xml
After the service has been imported into SMF it should be visible using
the svcs command.
# svcs newservice
STATE STIME FMRI
online 8:43:45 svc:/site/newservice:default
#
It should also be possible to manipulate the service using svcadm.

# svcadm -v disable site/newservice
site/newservice disabled.
# svcs newservice
STATE STIME FMRI
disabled 9:11:38 svc:/site/newservice:default
# svcadm -v enable site/newservice
site/newservice enabled.
# svcs newservice
STATE STIME FMRI
#
Finally, you can observe that the multiuser milestone requires the
newservice in order to complete its requirements.
# svcs -d milestone/multi-user:default
STATE STIME FMRI
disabled 8:43:16 svc:/platform/sun4u/sf880drd:default
online 8:43:33 svc:/system/rmtmpfiles:default
online 8:43:42 svc:/network/rpc/bind:default
online 8:43:46 svc:/milestone/single-user:default
online 8:43:46 svc:/system/utmp:default
online 8:43:47 svc:/system/system-log:default
online 8:43:47 svc:/system/system-log:default
online 8:43:49 svc:/system/filesystem/local:default
online 8:44:01 svc:/system/mdmonitor:default
#

The /usr/share/lib/xml/dtd/service_bundle.dtd
File
The /usr/share/lib/xml/dtd/service_bundle.dtd file is a DTD
(Document Type Definition) file that defines the structure the *.xml files
used in SMF. This file has many comments that explain the use of the
elements and attributes used in the *.xml files. Elements their attributes
are the building blocks of the data structures or models used for defining
services and manifests. Consult this file for additional information when
writing services.
Point out that the filename may actually have a .1 or .2 appended to it which is the naming convention being
use for revision marking.
Students will have varying backgrounds on XML files and the syntax used in DTDs. Share a session and walk
students through what is in this somewhat self documenting DTD file. (For example, explain notation like the
asterisk symbol which specifies that that element can appear zero or more times in a parent structure.) Use
the grep command to find the strings ELEMENT and ATTRIBUTE where the main data models are defined.
Instruct students that they may want to use this technique during the lab exercise which has them write a
simple service.
Managing Services
This section contains a number of command examples and output. Engage the students and keep the
training interactive by having them execute appropriate ones on a lab system in a shared window for all to
see.
One of the more significant benefits of SMF is visibility into services and
their dependencies. There are mechanisms to accomplish the following:
● Enable or disable service startup
● View and modify a service’s dependencies
● View the current state of all services
● View and modify service startup configuration data
The tools responsible for running services and accessing the repository are
as follows:
● svc.startd(1M) – Responsible for starting and stopping services as
requested
● svc.configd(1M) – Responsible for accessing the configuration
repository
● inetd(1M) – Delegated restarter

The tools available for observing and managing services are as follows:
● svcs(1) – Show services, their current state, and their dependencies
● svcprop(1) – Show property values for services
● svcadm(1M) – Manipulate service instances
● svccfg(1M) – Import, export and modify service configurations
● inetadm(1M) – Observe or configure inetd- controlled services
Changes to the inetd Daemon
The inetd daemon performs the same function as, but is implemented
significantly different from, the daemon of the same name in Solaris 9 and
prior Solaris operating system releases. In the current Solaris release,
inetd is part of SMF and runs only within that facility.
The following is an example of trying to run inetd from the command

line:
# inetd
inetd is now an smf(5) managed service and can no longer be run from the
command line. To enable or disable inetd refer to svcadm(1M) on
how to enable "svc:/network/inetd:default", the inetd instance.
The traditional inetd command line option mappings are:

-d : there is no supported debug output
-s : inetd is only runnable from within the SMF
-t : See inetadm(1M) on how to enable TCP tracing
-r : See inetadm(1M) on how to set a failure rate
To specify an alternative configuration file see svccfg(1M)

for how to modify the "start/exec" string type property of
the inetd instance, and modify it according to the syntax:
"/usr/lib/inet/inetd [alt_config_file] %m".
For further information on inetd see inetd(1M).
The network/inetd:default service instance is run by the SMF restarter

(svc.startd). In turn, inetd is the restarter for the network facilities that
it has managed in the past. The inetd daemon does not read the
inetd.conf file for configuration information. If there is information in
that file that needs to be converted for SMF, use the inetconv(1M)
command.

The svcs Command
The svcs command displays the current state of system services. Using
the svcs command with the -a option shows all services. Without the -a
the svcs command shows only services which are running or available to
run.
sys-01# svcs -a
STATE STIME FMRI
legacy_run Aug_31 lrc:/etc/rcS_d/S10pfil
legacy_run Aug_31 lrc:/etc/rcS_d/S29wrsmcfg
legacy_run Aug_31 lrc:/etc/rcS_d/S35cacheos_sh
legacy_run Aug_31 lrc:/etc/rcS_d/S41cachefs_root
legacy_run Aug_31 lrc:/etc/rcS_d/S55fdevattach
legacy_run Aug_31 lrc:/etc/rc2_d/S10lu
legacy_run Aug_31 lrc:/etc/rc2_d/S20sysetup
. . .
disabled Aug_31 svc:/platform/sun4u/mpxio-upgrade:default
disabled Aug_31 svc:/network/dns/client:default
disabled Aug_31 svc:/network/ldap/client:default
disabled Aug_31 svc:/network/nis/client:default
disabled Aug_31 svc:/network/nis/server:default
disabled Aug_31 svc:/network/rpc/nisplus:default
disabled Aug_31 svc:/network/dns/server:default
disabled Aug_31 svc:/network/inetd-upgrade:default
disabled Aug_31 svc:/platform/sun4u/sf880drd:default
disabled Aug_31 svc:/system/consadm:default
disabled Aug_31 svc:/application/print/cleanup:default
disabled Aug_31 svc:/application/print/server:default
. . .
online Aug_31 svc:/system/svc/restarter:default
online Aug_31 svc:/milestone/name-services:default
online Aug_31 svc:/network/loopback:default
online Aug_31 svc:/network/initial:default
online Aug_31 svc:/network/physical:default
online Aug_31 svc:/network/service:default
online Aug_31 svc:/network/ssh:default
online Aug_31 svc:/milestone/devices:default
online Aug_31 svc:/system/device/local:default
online Aug_31 svc:/system/filesystem/minimal:default
online Aug_31 svc:/network/rpc/bind:default
. . .
online Aug_31 svc:/network/telnet:default
online 17:03:46 svc:/network/smtp:sendmail
offline Aug_31 svc:/application/print/ipp-listener:default

To produce its output, the svcs command queries the configuration

repository and retrieves the name and current state of each service, and
the time it was started. Notice that only services started within the past 24
hours show the actual time stamp.
The svcs command has a -p option that allows you to see the processes
that are associated with a service. The following example uses a pattern
match to specify the services to display.
sys-01# svcs -p "*nfs*"
disabled Feb_18 svc:/network/nfs/cbd:default
disabled Feb_18 svc:/network/nfs/mapid:default
disabled Feb_18 svc:/network/nfs/server:default
online Feb_18 svc:/network/nfs/status:default
Feb_18 191 statd
online Feb_18 svc:/network/nfs/nlockmgr:default
Feb_18 200 lockd
online Feb_18 svc:/network/nfs/rquota:default
online Feb_18 svc:/network/nfs/client:default
SMF also makes it easier to view the dependencies among various

services. In earlier versions of Solaris, this was basically impossible
without access to the service source code and a significant amount of
time. SMF requires each service to describe its dependencies on other
services, explicitly using service identifier strings. The -d option of the
svcs command lists the service or service instance upon which the given
service instance depends. The -D option lists the service instances which
depend on the given service or service instances.
The following example shows the service or service instances which

/system/filesystem/minimal:default service instance depends on.
# svcs -D filesystem/minimal
STATE STIME FMRI
online Aug_31 svc:/system/device/local:default
online Aug_31 svc:/system/filesystem/usr:default

The following example shows the service instances which depend on the
service instance /system/filesystem/minimal:default.
# svcs -d filesystem/minimal
STATE STIME FMRI
online Aug_31 svc:/system/cryptosvc:default
online Aug_31 svc:/system/sysidtool:net
online Aug_31 svc:/system/sysidtool:system
Being able to list dependencies of a service is very useful in

troubleshooting service failures as well as helping to understand the
consequences of taking a service down.
To see all configuration information about a service instance, use the -l

option of the svcs command.
sys-01# svcs -l filesystem/minimal
fmri svc:/system/filesystem/minimal:default
enabled true
state online
next_state none
restarter svc:/system/svc/restarter:default
dependency require_all/none svc:/system/device/local (online)
dependency require_all/none svc:/system/filesystem/usr (online)
The svcprop Command
The svcprop command allows you to see the properties associated with a
service instance. The following example shows the properties for the
syslog default instance.
sys-01# svcprop svc:/system/system-log:default
general/package astring SUNWcsr
general/enabled boolean true
restarter/contract count 41
restarter/start_pid count 593
restarter/auxiliary_state astring none
restarter/next_state astring none
restarter/state astring online
restarter/state_timestamp time 1093965480.562821000
restarter_actions/refresh integer
Specifying the service instead of the instance shows additional properties

associated with the service.
sys-01# svcprop system/system-log
milestone/entities fmri svc:/milestone/single-user

milestone/grouping astring require_all

milestone/restart_on astring none
milestone/type astring service
dependents/system-log_single-user astring svc:/milestone/multi-user
general/entity_stability astring Unstable
general/single_instance boolean true
stop/exec astring :kill
stop/timeout_seconds count 3
stop/type astring method
start/exec astring /lib/svc/method/system-log
start/timeout_seconds count 3
start/type astring method
tm_man_syslogd/manpath astring /usr/share/man
tm_man_syslogd/section astring 1M
tm_man_syslogd/title astring syslogd
tm_common_name/C ustring system log
The svcprop command allows you to look at certain groups of properties

by the use of the -p option. The following example shows the general
properties for the spray service.
sys-01# svcprop -p general network/rpc/spray
general/restarter fmri svc:/network/inetd:default
To find out the default milestone, type the following command:

# svcprop restarter:default | grep milestone
If nothing returns, than the default milestone is all.
The svcadm Command
The svcadm command is used to manipulate the state of services and to

specify the milestone to which the machine should be brought. The
subcommands of the svcadm command are:
● enable – Enable the specified service instance
● disable – Disable the specified service instance
● restart – Stop and then start the specified service instance
● refresh – Have the specified service instance re-read its
configuration information
● mark – Assign the specified service instance to the specified state
(degraded or maintenance)

● clear – Restore a service instance from its previous degraded or

maintenance state
● delegate – Assign a new restarter for the specified service instance
● milestone – Restrict the set of services to those between the
beginning of the graph and the specified milestone
When a service is disabled, all dependent services are also disabled. The
svcs -D command can be used to see the impact of disabling a service.
# svcadm disable apache2
The disable setting not only persists across reboots, but also across
software upgrades and patch installation. Use this command to disable
any Solaris service.
A service is enabled using the svcadm enable command. Use the -r

option to enable a service and all of its dependencies. To enable sar
performance recording, type the following command:
# svcadm enable sar
To verify that the service is in fact running, examine the service with the
svcs command.
# svcs -l sar
fmri svc:/system/sar:default
enabled true
state online
next_state none
dependency require_all/none svc:/system/filesystem/minimal (online)
The milestone subcommand is used to specify the milestone to which

the system will change. This is basically the replacement for the init n
command.
# svcadm milestone all
After the above command is running, the svcs command can be used to
follow the progress of services being brought online.

The svccfg Command
The svccfg(1M) command can be used to either browse the SMF

repository interactively or run a set of commands from a command file.
An example of running the svccfg command interactively follows.

After starting the svccfg utility, the list subcommand prints a list of the
service identifiers for all services installed on the system:
example% svccfg
svc:> list
system/console-login
milestone/devices
system/device/local
system/identity
system/filesystem/local
system/manifest-import
system/filesystem/minimal
milestone/multi-user-server
milestone/multi-user
milestone/name-services
network/initial
network/loopback
network/physical
system/svc/restarter
system/filesystem/root
milestone/single-user
system/filesystem/usr
network/rpc/bind
network/inetd-upgrade
system/utmp
system/metainit
system/mdmonitor
smf/manifest
...
The select command identifies a service on which future svccfg

commands should operate, similar to the concept of a shell's current
working directory. SMF also supports multiple active instances of the
same service on a single system, so you can use svccfg on service
instance identifiers as well. The following examples use services that have
only a single instance named default. Type the following commands to
select the name service cache and list its instances.
svc:> select name-service-cache
svc:/system/name-service-cache> list
:properties
default
Notice the list contains not only the default instance but also the
:properties value. The presence of this string in the list output
identifies that there are properties related to the currently selected FMRI.

Type the listprop command to list the SMF properties associated with
the name service cache:
svc:/system/name-service-cache> listprop
usr dependency
usr/entities fmri svc:/system/filesystem/usr
usr/grouping astring require_all
usr/restart_on astring none
usr/type astring service
config_data dependency
config_data/entities fmri file://localhost/etc/nscd.conf
file://localhost/etc/nsswitch.conf
config_data/grouping astring require_all
config_data/restart_on astring restart
config_data/type astring path
general framework
general/single_instance boolean true
stop method
stop/exec astring :kill
stop/timeout_seconds count 3
stop/type astring method
start method
start/exec astring /lib/svc/method/svc-nscd
start/timeout_seconds count 30
start/type astring method
tm_man_nscd template
tm_man_nscd/manpath astring /usr/man
tm_man_nscd/section astring 1M
tm_man_nscd/title astring nscd
tm_common_name template
tm_common_name/C ustring "Name service cache daemon"
general framework
general/package astring SUNWcsr
general/enabled boolean true
restarter framework NONPERSISTENT
restarter/contract count 180
restarter/start_pid count 2430
restarter/auxiliary_state astring none
restarter/next_state astring none
restarter/state astring online
restarter/state_timestamp time 1094137041.968560000
restarter_actions framework NONPERSISTENT
restarter_actions/refresh integer

You can modify a single property using the setprop command. For
example, to set the start method timeout to 15 seconds, type:
svc:/system/name-service-cache> setprop start/timeout_seconds = 15
The property names, values, and meanings are explained in further detail
in the SMF System Administration Guide documentation. You can also
use the editprop command to edit groups of properties in your preferred
text editor. SMF automatically stores a persistent snapshot of the changes
made to the current configuration to serve as backup copy of your
changes and to permit administrators to undo any configuration mistakes.
The listsnap subcommand can be used to list configuration snapshots
associated with the service instance:
svc:/system/name-service-cache> select default
svc:/system/name-service-cache:default> listsnap
initial
running
start
The snapshot of the current configuration used by the active service

instance is shown in the list and is named running. The snapshot named
initial is the initial system state immediately after install. To undo
configuration changes, you can use the revert command to restore an
earlier snapshot.
When you execute an undo operation with the revert command, SMF
automatically restores your configuration settings and then starts, restarts,
and stops services based on the new settings immediately and
automatically.
The inetadm Command
The inetadm(1M) command allows observation and configuration of

inetd-controlled services (services with inetd as the restarter). The
capabilities of inetadm are a combination of the svcs command, the
svcadm command, and the svccfg command.
The inetadm command with no arguments lists all the services under the
control of the inetd daemon.
# inetadm
ENABLED STATE FMRI
disabled disabled svc:/network/rpc/ocfserv:default
disabled disabled svc:/network/lp:default
enabled online svc:/network/rpc/mdcomm:tcp

disabled disabled svc:/network/rpc/mdcomm:tcp6

enabled online svc:/network/rpc/meta:tcp
disabled disabled svc:/network/rpc/meta:tcp6
enabled online svc:/network/rpc/metamed:tcp
disabled disabled svc:/network/rpc/metamed:tcp6
enabled online svc:/network/rpc/metamh:tcp
disabled disabled svc:/network/rpc/metamh:tcp6
disabled disabled svc:/network/tname:default
enabled online svc:/network/security/ktkt_warn:ticotsord
enabled online svc:/network/telnet:default
enabled online svc:/network/rpc/smserver:default
enabled online svc:/network/rpc/gss:ticotsord
disabled disabled svc:/network/rpc/rex:tcp
disabled disabled svc:/network/uucp:default
disabled disabled svc:/network/chargen:dgram
disabled disabled svc:/network/chargen:stream
disabled disabled svc:/network/daytime:dgram
disabled disabled svc:/network/daytime:stream
. . .
The -l option of the inetadm command allows you to see all the
properties for a particular service. Those values preceded by default are
values inherited from the inetd service.
# inetadm -l network/telnet:default
SCOPE NAME=VALUE
name="telnet"
endpoint_type="stream"
proto="tcp6"
isrpc=FALSE
wait=FALSE
exec="/usr/sbin/in.telnetd"
user="root"
default bind_addr=""
default bind_fail_max=-1
default bind_fail_interval=-1
default max_con_rate=-1
default max_copies=-1
default con_rate_offline=-1
default failrate_cnt=40
default failrate_interval=60
default inherit_env=TRUE
default tcp_trace=FALSE
default tcp_wrappers=FALSE

Services can be enabled and disabled with the -e and -d options of the
inetadm command respectively. The following is an example of enabling
the services to allow the rdate command to work.
# rdate localhost
rdate: connect: Connection refused
# inetadm -e network/time:dgram
# inetadm -e network/time:stream
# rdate localhost
Thu Sep 2 16:18:59 2004
The -p option of the inetadm command shows the service property

values provided by the inetd service.
# inetadm -p
NAME=VALUE
bind_addr=""
bind_fail_max=-1
bind_fail_interval=-1
max_con_rate=-1
max_copies=-1
con_rate_offline=-1
failrate_cnt=40
failrate_interval=60
inherit_env=TRUE
tcp_trace=FALSE
tcp_wrappers=FALSE
It is also possible to modify the properties of the inetd service and any
service that is inetd-controlled. Following are command examples for
modifying the properties of an inetd-controlled service.
First find the service of interest and verify that its restarter is inetd:
# svcs ftp
STATE STIME FMRI
online 12:49:06 svc:/network/ftp:default
# svcs -l ftp
fmri svc:/network/ftp:default
name FTBR server
enabled true
state online
next_state none
state_time Thu Apr 21 12:49:06 2005
restarter svc:/network/inetd:default
contract_id

Verified as an inet-controller service, use the inetadm command to list

this service’s properties and property values:
# inetadm -l ftp
SCOPE NAME=VALUE
name="ftp"
proto="tcp6"
isrpc=FALSE
wait=FALSE
exec="/usr/sbin/in.ftpd -a"
user="root"
The above output shows that tcp_wrappers is currently set to FALSE.

Enable (and verify) this property for the service by using the following
command:
# inetadm -m ftp tcp_trace=true
# inetadm -l ftp
SCOPE NAME=VALUE
name="ftp"
proto="tcp6"
isrpc=FALSE
wait=FALSE
exec="/usr/sbin/in.ftpd -a"
user="root"

tcp_trace=TRUE
Either of the following commands will disable this property for the ftp
service:
# inetadm -m ftp tcp_wrappers=
# inetadm -m ftp tcp_wrappers=false
Troubleshooting
A common problem experienced by users new to SMF is the diagnosis of
failure of a service to start either automatically at boot time or manually.
Debugging a Hang on Boot
To debug a system hang on boot, use the -m option of the boot command.
For this type of problem specify milestone=none as the -m option (see
kernel(1M)).
{1} ok boot -m milestone=none
Resetting ...
screen not found.

Can’t open input device.
Keyboard not present. Using ttya for input and output.
Sun Enterprise 420R (3 X UltraSPARC-II 450MHz), No Keyboard

OpenBoot 3.29, 1024 MB memory installed, Serial #16241000.
Ethernet address 8:0:20:f7:d1:68, Host ID: 80f7d168.
Rebooting with command: boot -m milestone=none

Boot device: /pci@1f,4000/scsi@3/disk@0,0:a File and args: -m
milestone=none
SunOS Release 5.10 Version s10_64 64-bit
Copyright 1983-2004 Sun Microsystems, Inc. All rights reserved.
Requesting System Maintenance Mode
Type control-d to proceed with normal startup,

(or give root password for system maintenance):

After you receive the sulogin prompt, log in with the root password.
This brings the system to a console prompt with no services running.
single-user privilege assigned to /dev/console.
Entering System Maintenance Mode
Jul 28 11:53:07 su: ’su root’ succeeded for root on /dev/console

Sun Microsystems Inc. SunOS 5.10 s10_64 May 2004
# svcs -a
STATE STIME FMRI
disabled 12:18:28 svc:/milestone/single-user:default
disabled 12:18:28 svc:/network/initial:default
disabled 12:18:28 svc:/network/loopback:default
disabled 12:18:28 svc:/network/physical:default
disabled 12:18:28 svc:/network/rpc/bind:default
disabled 12:18:28 svc:/system/device/local:default
disabled 12:18:28 svc:/system/filesystem/local:default
disabled 12:18:28 svc:/system/filesystem/minimal:default
disabled 12:18:28 svc:/system/filesystem/root:default
disabled 12:18:28 svc:/system/filesystem/usr:default
disabled 12:18:28 svc:/system/identity:domain
. . .
Next, you use the svcadm command with the all option to specify that all
services should be started. The all milestone is a special one meaning all
services possible.
# svcadm milestone all
# Configuring devices.
Progress of the service startup can be watched with the svcs command.
# svcs
STATE STIME FMRI
online 11:52:41 svc:/system/svc/restarter:default
online 11:54:05 svc:/network/loopback:default
online 11:54:05 svc:/system/filesystem/root:default
online 11:54:07 svc:/system/filesystem/usr:default
online 11:54:16 svc:/network/physical:default
online 11:54:17 svc:/system/identity:node
online 11:54:19 svc:/network/service:default
online 11:54:23 svc:/milestone/devices:default
online 11:54:23 svc:/system/device/local:default
online 11:54:23 svc:/system/filesystem/minimal:default
online 11:54:23 svc:/system/sysevent:default


online 11:54:24 svc:/network/dns/client:default
online 11:54:24 svc:/network/ntp:default
online 11:54:24 svc:/system/manifest-import:default
online 11:54:24 svc:/system/rmtmpfiles:default
offline 11:54:04 svc:/milestone/multi-user:default
offline 11:54:04 svc:/milestone/single-user:default
offline 11:54:04 svc:/network/rpc/bind:default
. . .
Notice that the milestone/multi-user service is offline. To determine

why, look at the dependencies for this service.
# svcs -l svc:/milestone/single-user:default
fmri svc:/milestone/single-user:default
enabled true
state offline
next_state none
dependency require_all/none svc:/system/sysidtool:net (offline)
svc:/system/sysidtool:system (offline)
dependency optional_all/none svc:/network/physical (online)
dependency require_any/none svc:/network/loopback (online)
dependency require_all/none svc:/system/manifest-import (online)
dependency require_all/none svc:/system/filesystem/minimal (online)
dependency require_all/none svc:/system/identity:node (online)
dependency require_all/none svc:/system/sysevent (online)
dependency optional_all/none svc:/system/metainit (offline)
The above output shows that all dependencies are met. The next step is to
look for errors in the error logs in the /var/svc/log directory.
If students ask about the output showing sysidtool being offline you can refer them to the explanation which
is a comment in the /var/svc/manifest/milestone/single-user.xml file. For convenience, here is that
information:
Single-user's dependency on sysidtool is obsolete, but instead of

removing it from this manifest, retain it here with its delete
attribute set to true. This is to try and prevent a dependency
cycle with the new sysidtool which declares a dependency on
single-user. This will force the deletion of single-user's
sysidtool dependency as soon as this manifest is imported
(instead of waiting for upgrade to delete it).
Note that this does not guarantee the prevention of a dependency

cycle (if the new sysidtool manifest is imported before
single-user's) - if this does occur, the code in upgrade will

catch it - it deletes single-user's dependency and "svcadm

clear"s sysidtool.
Using Debug Mode
SMF can be put in a debug mode by using the boot -m debug command.
This causes SMF to start all services serially and display messages on the
console for all services.
Executing last command: boot -m debug
Boot device: /pci@1f,0/pci@1/scsi@8/disk@0,0:a File and args: -m debug
SunOS Release 5.10 Version s10_66 64-bit
-
INIT: Executing svc.startd
Sep 3 08:04:00/1: Initialized restarter protocol
Sep 3 08:04:00/1: Initialized restarter
Sep 3 08:04:00/1: Initialized graph
Sep 3 08:04:00/6: Graph adding svc:/system/console-login:default.
Sep 3 08:04:00/6: Graph engine: Refreshing svc:/system/console-
login:default.
Sep 3 08:04:00/6: Graph adding svc:/system/sysidtool:net.
Sep 3 08:04:00/6: Graph engine: Refreshing svc:/system/sysidtool:net.
Sep 3 08:04:00/6: Graph adding svc:/system/identity:node.
Sep 3 08:04:00/6: Graph engine: Refreshing svc:/system/identity:node.
Sep 3 08:04:00/3: svc:/system/console-login:default is a wait-style
service
Sep 3 08:04:00/3: svc:/system/console-login:default: inserted instance
into restarter list
Sep 3 08:04:00/3: svc:/system/sysidtool:net is a transient-style service
Sep 3 08:04:00/3: svc:/system/sysidtool:net: inserted instance into
restarter list
Sep 3 08:04:00/3: svc:/system/identity:node is a transient-style service
Sep 3 08:04:00/3: svc:/system/identity:node: inserted instance into
restarter list
Sep 3 08:04:00/6: Graph adding svc:/network/physical:default.
Sep 3 08:04:00/6: Graph engine: Refreshing
svc:/network/physical:default.
Sep 3 08:04:00/6: Enabling svc:/network/physical:default.
Sep 3 08:04:00/6: Graph adding svc:/network/loopback:default.
Sep 3 08:04:00/6: Graph engine: Refreshing
svc:/network/loopback:default.
Sep 3 08:04:00/6: Enabling svc:/network/loopback:default.
Sep 3 08:04:00/6: Enabling svc:/system/identity:node.
Sep 3 08:04:00/6: Graph adding svc:/system/identity:domain.

Sep 3 08:04:00/6: Graph engine: Refreshing svc:/system/identity:domain.

Sep 3 08:04:00/6: Graph adding svc:/system/filesystem/minimal:default.
. . .
Sep 3 08:07:37/9: Propagating start of svc:/system/zones:default.
Sep 3 08:07:37/3: svc:/system/zones:default: trying to start instance
Sep 3 08:07:37/3: svc:/system/zones:default: start_instance -> is
already started
Sep 3 08:07:39/54: svc:/network/inetd:default: state updates for
svc:/network/rpc/smserver:default (5, 0)
Sep 3 08:07:39/9: Graph noting svc:/network/rpc/smserver:default online
-> online.
Sep 3 08:08:21/54: svc:/network/inetd:default: state updates for
svc:/network/telnet:default (5, 0)
Sep 3 08:08:21/9: Graph noting svc:/network/telnet:default online ->
online.
Sep 3 08:08:27 sys-01 login: ROOT LOGIN /dev/pts/1 FROM gateway
This approach is similar to putting sh -x in all of the rc*.d scripts. The

console shows all the processing done by SMF. If this is done on a
problem system, errors will display.
Debugging a Service
The following is an example of troubleshooting the lpsched service when

it is failing to start with the command:
sys-02# svcadm enable /application/print/server
After running the previous command, the service still shows as disabled.
sys-02# svcs print/server
STATE STIME FMRI
disabled 11:14:24 svc:/application/print/server:default
The first step would be to determine if all the dependencies are met. To do
this, use the following command:
sys-02# svcs -d print/server
STATE STIME FMRI
sys-02
Because the command returned no dependencies, there is no need to

check for services running that the print server service might require. This
also means that the root of the problem lies with svc.startd not starting
the service. If errors were made to /application/print/server, you
can revert to the last good known running state.

sys-02# svccfg
svc:> select print/server:default
svc:/application/print/server:default> listsnap
initial
running
svc:/application/print/server:default>
This shows that you could revert to the initial configuration for this
service.
svc:/application/print/server:default> revert initial
svc:/application/print/server:default> listsnap
initial
running
previous
svc:/application/print/server:default>
Now try to start the service.

sys-02# svcadm -v enable print/server
/application/print/server enabled.
sys-02# svcs print/server
STATE STIME FMRI
online 11:43:50 svc:/application/print/server:default
sys-02#
The svcs command now shows that the service is running. The problem
is fixed. If the print server still had not started, the error logs should be
searched for problems.
sys-02# more /var/svc/log/application-print-server:default.log
Aug 25 11:43:50 Executing start method ("/lib/svc/method/print-server
start")
Print services started.
sys-02#
You can also use the following command to check for additional errors.
The -l option to svcs lists the status of the FMRI. Any error or
complaints from svc.startd is reported here.
sys-02# svcs -l print/server:default
fmri svc:/application/print/server:default
enabled true
state online
next_state none

contract_id 122
sys-02#
Repository Problems
There are two types of problems that can occur with the repository. The
repository can be corrupted, or it can be inaccessible. The following is an
example of an inaccessible repository:
# svccfg
svc:> select network/nfs/client
svccfg: Could not connect to repository server: repository server
unavailable.
The repository server is the svc.configd daemon. Either the

svc.configd daemon is not running or the svc.startd daemon is not
running. Look at the state of the system/svc/restarter:default
service and the error logs for this service.
If the repository becomes unusable, you can restore the repository from
backup data, or you can copy in the initial seed repository and reboot.
There is a script that walks you through the procedure.
As root, run the command:

# /lib/svc/bin/restore_repository
Repository Restore utility
See http://sun.com/msg/SMF-8000-MY for more information on the use of

this script to restore backup copies of the smf(5) repository.
If there are any problems which need human intervention, this script will
give instructions and then exit back to your shell.
Note that upon full completion of this script, the system will be
rebooted
using reboot(1M), which will interrupt any active services.
The following backups of /etc/svc/repository.db exist, from

oldest to newest:
boot-20050126_115535
manifest_import-20050126_115846
boot-20050126_124919
boot-20050203_082002
manifest_import-20050203_082451

The backups are named based on their type and the time what they were
taken.
Backups beginning with "boot" are made before the first change is made to
the repository after system boot. Backups beginning with
"manifest_import"
are made after svc:/system/manifest-import:default finishes its
processing.
The time of backup is given in YYYYMMDD_HHMMSS format.
Please enter one of:

1) boot, for the most recent post-boot backup
2) manifest_import, for the most recent manifest_import backup.
3) a specific backup repository from the above list
4) -seed-, the initial starting repository. (All customizations
will be lost.)
5) -quit-, to cancel.
Enter response [boot]: manifest_import
After confirmation, the following steps will be taken:
svc.startd(1M) and svc.configd(1M) will be quiesced, if running.

/etc/svc/repository.db
-- renamed --> /etc/svc/repository.db_old_20050222_150658
/etc/svc/repository-manifest_import
-- copied --> /etc/svc/repository.db
and the system will be rebooted with reboot(1M).
Proceed [yes/no]? y
Quiescing svc.startd(1M) and svc.configd(1M): done.
/etc/svc/repository.db
-- renamed --> /etc/svc/repository.db_old_20050222_150658
/etc/svc/repository-manifest_import
-- copied --> /etc/svc/repository.db

The backup repository has been successfully restored.
Rebooting in 5 seconds.
Example of Adding a Service to startd

To register a service or script to start at boot time using svc.startd, you
must create an XML file to import into the repository database. This .xml
file then points to the desired script or service to start.
Here is an example script called run.boot.script:

1. Create an executable script called
/opt/ses/labs/smf/run.boot.script.
sys-01# cat run.boot.script
#!/bin/sh
echo "Hello World" > /opt/ses/labs/smf/test
Note – When this script is run, it writes “Hello World” to

/opt/ses/labs/smf/test.
2. Create an .xml file in /var/svc/manifest/site called test.xml:

sys-01#cat test.xml

<service_bundle type=’manifest’ name=’test’>
<service
name=’site/test’
type=’service’
version=’1’>
<create_default_instance enabled=’true’ />

<single_instance/>

<exec_method
type=’method’
name=’start’
exec=’/opt/ses/labs/smf/run.boot.script’
<exec_method
type=’method’
name=’stop’
exec=’:true’

/>
</property_group>

</service>
</service_bundle>
3. Register the .xml file with the repository:
# svccfg -v import /var/svc/manifest/site/test.xml
svccfg: Taking "initial" snapshot for svc:/site/test:default.
svccfg: Taking "last-import" snapshot for svc:/site/test:default.
svccfg: Refreshed site/test:default.
svccfg: Successful import.
4. To verify it has been added, use the svcs command:
# svcs test
disabled 8:48:17 svc:/site/test:default
5. To enable the service, use the svcadm command:
# svcadm enable /site/test
6. To verify it has started running, use the svcs command again:
# svcs test
online 11:15:22 svc:/site/test:default
7. Verify that your script ran properly:
# cd /tmp
# more test
This is only a test
If you want to disable the script, type the following command:

# svcadm disable test:default

To verify that it has been disabled, type the following command:

# svcs test
Note – Troubleshooting tip:

If your .xml file does not come online and the status is listed as
maintenance, try running this command:
# svcs -x test:default
This command gives you more verbose information and also supplies you
with an error code and a web site on www.sun.com to help troubleshoot
the problem.
Another tip: xmllint is helpful in finding XML syntax errors. See the
xmllint(1) man page for details.
Example of Adding a Service to inetd

The new Service Management Facility has made the /etc/inetd.conf
file into a legacy. To add a new service under the control of inetd, you
can no longer simply edit the /etc/inetd.conf file, but instead should
add the service to the repository database under the control of inetd.
In this example, you add swat, a browser-based administration tool that

listens to port 901. The procedure is to simply create a .xml file and
register it with SMF by adding it to the repository data base.
1. Create the XML file. The file consists of the following:
a. xml version.
b. service_bundle type – This contains information about
whether it is under manifest or profile, and the name of the
SUNW package where the command lives.
c. service – The name is critical, because it will be the FMRI.
d. restarter.
e. exec_method – The type is method to indicate that this is a
command to run. The name is inetd_start to indicate that it is
under the control of inetd. The exec points to the command.
f. property_group name – Properties are name, endpoint_type,
proto, wait, isrpc.

g. template – This is not mandatory and can be used as a

comment string.
# cat /var/svc/manifest/network/swat.xml

<service_bundle type=’manifest’ name=’SUNWsmbau:swat’>
<service
name=’network/swat’
type=’service’
version=’1’>
<restarter>
<service_fmri value=’svc:/network/inetd:default’ />
</restarter>
<exec_method
type=’method’
name=’inetd_start’
exec=’/usr/sfw/sbin/swat’
<method_context>
<method_credential user=’root’ group=’root’ />
</method_context>
</exec_method>
<exec_method
type=’method’
name=’inetd_disable’
exec=’:kill’
</exec_method>
<property_group name=’inetd’ type=’framework’>
<stability value=’Evolving’ />
<propval name=’name’ type=’astring’ value=’swat’ />
<propval name=’endpoint_type’ type=’astring’
value=’stream’ />
<propval name=’proto’ type=’astring’ value=’tcp’ />
<propval name=’wait’ type=’boolean’ value=’false’ />
<propval name=’isrpc’ type=’boolean’ value=’false’ />
</property_group>
<template>

<common_name>
<loctext xml:lang=’C’> swat </loctext>
</common_name>
<description>
Swat supports a browser interface for Samba.
</loctext>
</description>
</template>
</service>
</service_bundle>
2. Add port 901 to the /etc/services file.

swat 901/tcp # Samba Web Administration Tool
3. Now register the XML file with the repository.

a. Run the following command:
sys-01# svccfg import /var/svc/manifest/network/swat.xml
b. To verify it has been added, use the svcs command.
sys-01# svcs swat
offline 9:53:18 svc:/network/swat:default
c. Enable the service.
sys-01# inetadm -e /network/swat
d. To verify it has started, use the svcs command.
sys-01# svcs swat
online 9:54:20 svc:/network/swat:default
swat is now ready to be accessed through http://hostname:901 in any

browser.

Exercise: Listing, Enabling, and Disabling Services

In this exercise, you complete the following:
● List various categories of services on the system.
● Determine service states, statuses and dependencies.
● Determine and change service properties.
● Enable and disable services.
Preparation
None.
Task
1. List all the services available on your system.
________________________________________________________
2. How many legacy services are running on your system?
________________________________________________________
3. How many SMF-controlled services are running on your system?
________________________________________________________
4. List the service status for network/shell instances.
________________________________________________________
5. List the state and dependencies for all network/shell instances.
________________________________________________________
6. What is the restarter for these instances?
________________________________________________________
7. Display the current settings for the default instance.
________________________________________________________
8. Enable TCP tracing for this service.
________________________________________________________
9. Execute the spray command to send packets to your host (localhost).
What happens? Why?
________________________________________________________

10. Change your system so that spray works.

________________________________________________________
11. Reboot your machine. Does spray still work? Why?
________________________________________________________
12. What processes are associated with the cron service?
________________________________________________________
13. Kill the cron service. What does SMF show now for cron processes?
________________________________________________________
14. Disable the cron service. What does SMF show now for cron
processes?
________________________________________________________

Exercise: Implementing an SMF Service

● Implement a service method script.
● Create a manifest entry for a service.
● Create a log file file for a service.
● Create a service configuration file for starting a service.
● Import a service into the database.
Preparation
The lab exercises reference the location for the files you need as
$LABFILES. Ask your instructor where your lab files directory is located.
Task
1. Create a script for a service in the /opt/svc/method directory by
copying the method called samba in your $LABFILES/smf directory
to the /opt/svc/method directory. Use the chmod command to make
the method executable (755).
________________________________________________________
________________________________________________________
________________________________________________________
________________________________________________________
2. Create the manifest for the script by copying samba.xml file in your
$LABFILES/smf directory to the /var/smv/manifest/site
directory.
________________________________________________________
________________________________________________________
3. Create an empty log file called site-samba:default.log for the
service in the /var/svc/log directory.
________________________________________________________
________________________________________________________
4. Create an smb.conf file to allow the service to start automatically by
executing the following commands:

# cd /etc/sfw
# cp smb.conf-example smb.conf
# mv /etc/rc3.d/S90samba /etc/rc3.d/s90samba
5. Import the service into the database by executing the following
svccfg command:
# svccfg -v import /var/svc/manifest/site/samba.xml
svccfg: Taking "initial" snapshot for svc:/site/samba:default. svccfg:
Taking "last-import" snapshot for svc:/site/samba:default. svccfg:
Refreshed svc:/site/samba:default.
6. Check that the new service is online by executing the following svcs
command:
# svcs samba

Exercise: Implementing an SMF inetd Service

● Use the inetconv command to create the xml file needed for
implementing an SMF servicef or the swat application.
● Configure the inetd SMF rstarter service to run the swat application.
Preparation
None.
Task
1. Edit the /etc/services file and add and following line:
2. Edit the /etc/inetd.conf file and add the following line:
swat stream tcp6 nowait root /usr/sfw/sbin/swat swat
3. Convert the existing swat run control script by executing the
following command:
# /usr/sbin/inetconv -n
4. Rename the swat-tcp6.xml file reported as the converted script by
inetconv to swat.xml.
________________________________________________________
________________________________________________________
5. Edit the swat.xml file and change the name of the service from
network/swat/tcp6 to network/swat.
6. Now register the XML file with the repository by executing the
following command:
# svccfg import /var/svc/manifest/network/swat.xml
7. Verify that the service has started by executing the following svcs
command:
# svcs swat
8. The swat application is now ready to be accessed through the
following URL:

http://hostname:901 in any browser.
Start a browser and verify that it is accessible. (The root username and
password is used for swat authentication.)

Exercise: Creating Your Own Services

● Create a service manifest file from a template.
● Validate and import your service.
● Enable and test your service.
● Disable and delete your service.
Preparation
None.
Task
1. Create a script called /opt/ses/labs/smf/run.boot.script that
writes “Hello World” to /opt/ses/labs/smf/test. Make sure execute
permissions are set on the script.
________________________________________________________
2. Create a manifest for the service named test.xml in the directory
/var/svc/manifest/site by executing the following command:
# svccfg export system/utmp > /var/svc/manifest/site/test.xml
This will provide a template, but you should make modifications to
this file for your service consulting the “Writing a Service” section in
the Student Guide. There is more than one solution, but one is
provided in the solution section.
3. Validate the test.xml file with the svccfg command.
________________________________________________________
If errors are returned, fix the errors before proceeding.
4. Import the manifest into the repository.
________________________________________________________
If there is an error that it cannot parse the document, check to make
sure there are no typographical errors in the path name. If the same
service has been imported more than once, the output will be slightly
different as it updates the snapshot.

5. Verify the service has been added.

________________________________________________________
If the service is already online, a default instance was created by a
line in the XML file:
<create_default_instance enabled=’true’/>
6. Enable the service.
________________________________________________________
7. Verify the service has started running.
________________________________________________________
8. Verify that your script ran properly.
________________________________________________________
9. Disable the service.
________________________________________________________
10. Verify that the service has been disabled.
________________________________________________________
A service may first appear in maintenance mode if the process
described in the manifest exits ungracefully. When this happens, the
repository tags the service for maintenance. Enter the command
again to disable it.
11. Delete the service.
________________________________________________________

Exercise Summary
Exercise Summary
Discussion – Take a few minutes to discuss what experiences, issues, or

discoveries you had during the lab exercises.
!
?
Manage the discussion based on the time allowed for this module, which was provided in the “About This
Course” module. If you do not have time to spend on discussion, then just highlight the key concepts students
should have learned from the lab exercise.
● Experiences
Ask students what their overall experiences with this exercise have been. Go over any trouble spots or
especially confusing areas at this time.
● Interpretations
Ask students to interpret what they observed during any aspect of this exercise.
● Conclusions
Have students articulate any conclusions they reached as a result of this exercise experience.
● Applications
Explore with students how they might apply what they learned in this exercise to situations at their workplace.

Exercise Solutions: Listing, Enabling, and Disabling Services
Exercise Solutions: Listing, Enabling, and Disabling

Services
This section contains solutions to the exercise.
Task
1. List all the services available on your system.
# svcs -a
STATE STIME FMRI
legacy_run Jun_07 lrc:/etc/rcS_d/S29wrsmcfg
legacy_run Jun_07 lrc:/etc/rc2_d/S10lu
legacy_run Jun_07 lrc:/etc/rc2_d/S20sysetup
legacy_run Jun_07 lrc:/etc/rc2_d/S40llc2
legacy_run Jun_07 lrc:/etc/rc2_d/S42ncakmod
legacy_run Jun_07 lrc:/etc/rc2_d/S47pppd
legacy_run Jun_07 lrc:/etc/rc2_d/S70sckm
legacy_run Jun_07 lrc:/etc/rc2_d/S70uucp
legacy_run Jun_07 lrc:/etc/rc2_d/S72autoinstall
. . .
2. How many legacy services are running on your system?
# svcs | grep legacy | wc -l
41
This number will vary depending on the version of the Solaris 10 OS you
are running.
3. How many SMF-controlled services are running on your system?
# svcs | grep online | wc -l
67
This number will vary depending on the number of services that have been
modified.
4. List the service status for network/shell instances.
# svcs network/shell
STATE STIME FMRI
disabled Jun_20 svc:/network/shell:kshell
online Jun_20 svc:/network/shell:default
# svcs shell
STATE STIME FMRI
# svcs svc:/network/shell

STATE STIME FMRI

Notice that you can specify different parts of the FMRI on the command
line and get the same results.
5. List the state and dependencies for all network/shell instances.
# svcs -l ’network/shell*’
fmri svc:/network/shell:kshell
name rsh
enabled false
state disabled
next_state none
state_time Fri Jun 20 10:50:36 2005
dependency require_any/error svc:/network/loopback (online)
dependency optional_all/error svc:/milestone/network (online)
fmri svc:/network/shell:default
name rsh
enabled true
state online
next_state none
state_time Fri Jun 20 10:50:41 2005
contract_id
dependency require_any/error svc:/network/loopback (online)
dependency optional_all/error svc:/milestone/network (online)
6. What is the restarter for these instances?
The inetd command.This means that inetadm is used to change settings.
7. Display the current settings for the default instance.
# inetadm -l svc:/network/shell:default
SCOPE NAME=VALUE
name="shell"
proto="tcp6only,tcp"
isrpc=FALSE
wait=FALSE
exec="/usr/sbin/in.rshd"
user="root"

8. Enable TCP tracing for this service.
# inetadm -m shell:default tcp_trace=true
The -m option enables TCP tracing for this service while the -M option
enables TCP tracing for all inetd services. Verify that it has been changed.
# inetadm -l svc:/network/shell:default
SCOPE NAME=VALUE
name="shell"
proto="tcp6only,tcp"
isrpc=FALSE
wait=FALSE
exec="/usr/sbin/in.rshd"
user="root"
default tcp_trace=TRUE
9. Execute the spray command to send packets to your host (localhost).
What happens? Why?
# spray localhost
spray: cannot clnt_create localhost:netpath: RPC: Program not
registered
The spray command does not work. Look at the spray service instances to
see if they are enabled.
# svcs -l ’*spray*’
fmri svc:/network/rpc/spray:default
name RPC spray
enabled false
state disabled

next_state none
state_time Tue Jun 07 10:50:33 2005
dependency require_all/restart svc:/network/rpc/bind (online)
All instances of the spray service are disabled.
10. Change your system so that spray works.
# svcadm enable svc:/network/rpc/spray:default
There are no errors, so try the spray command again.
# spray localhost
sending 1162 packets of length 86 to localhost ...
163 packets (14.028%) dropped by localhost
66 packets/sec, 5702 bytes/sec
11. Reboot your machine. Does spray still work? Why?
# /etc/reboot
...
# spray localhost
sending 1162 packets of length 86 to localhost ...
163 packets (14.028%) dropped by localhost
66 packets/sec, 5702 bytes/sec
The spray command still works because a change using the svcadm
command is persistent across reboots.
12. What processes are associated with the cron service?
# svcs -p ’*cron*’
STATE STIME FMRI
online Jun_07 svc:/system/cron:default
Jun_07 556 cron
13. Kill the cron service. What does SMF show now for cron processes?
# pkill cron
STATE STIME FMRI
online 11:52:24 svc:/system/cron:default
11:52:24 1766 cron
The service is still there but the process number for cron has changed. It is
automatically restarted by SMF.
14. Disable the cron service. What does SMF show now for cron
processes?
# svcadm disable svc:/system/cron:default
STATE STIME FMRI
disabled 11:53:58 svc:/system/cron:default

Exercise Solutions: Implementing an SMF Service
Exercise Solutions: Implementing an SMF Service

Task
1. Create a script for a service in the /opt/svc/method directory by
copying the method called samba in your $LABFILES/smf directory
to the /opt/svc/method directory. Use the chmod command to make
the method executable (755).
# mkdir -p /opt/svc/method
# cd /opt/svc/method
# cp $LABFILES/smf/samba .
# chmod 755 samba
2. Create the manifest for the script by copying samba.xml file in your
$LABFILES/smf directory to the /var/smv/manifest/site
directory.
# cd /var/svc/manifest/site
# cp $LABFILES/smf/samba.xml .
3. Create an empty log file called site-samba:default.log for the
service in the /var/svc/log directory.
# cd /var/svc/log
# touch site-samba:default.log
4. Create an smb.conf file to allow the service to start automatically by
executing the following commands:
# cd /etc/sfw
# cp smb.conf-example smb.conf
# mv /etc/rc3.d/S90samba /etc/rc3.d/s90samba
5. Import the service into the database by executing the following
svccfg command:
# svccfg -v import /var/svc/manifest/site/samba.xml
svccfg: Taking "initial" snapshot for svc:/site/samba:default. svccfg:
Taking "last-import" snapshot for svc:/site/samba:default. svccfg:
Refreshed svc:/site/samba:default.
6. Check that the new service is online by executing the following svcs
command:
# svcs samba
online 15:53:31 svc:/site/samba:default

Exercise Solutions: Implementing an SMF inetd Service

Task
1. Edit the /etc/services file and add and following line:
2. Edit the /etc/inetd.conf file and add the following line:
swat stream tcp6 nowait root /usr/sfw/sbin/swat swat
3. Convert the existing swat run control script by executing the
following command:
# /usr/sbin/inetconv -n
inetconv: Notice: Service manifest for 100235/1 already generated as
/var/svc/manifest/network/rpc/100235_1-rpc_ticotsord.xml, skipped
inetconv: Notice: Service manifest for 100083/1 already generated as
/var/svc/manifest/network/rpc/100083_1-rpc_tcp.xml, skipped
inetconv: Notice: Service manifest for 100068/2-5 already generated as
/var/svc/manifest/network/rpc/100068_2-5-rpc_udp.xml, skipped
swat -> /var/svc/manifest/network/swat-tcp6.xml
4. Rename the swat-tcp6.xml file reported as the converted script by
inetconv to swat.xml.
# cd /var/svc/manifest/network
# mv swat-tcp6.xml swat.xml
5. Edit the swat.xml file and change the name of the service from
network/swat/tcp6 to network/swat.
6. Now register the XML file with the repository by executing the
following command:
# svccfg import /var/svc/manifest/network/swat.xml
7. Verify that the service has started by executing the following svcs
command:
# svcs swat
8. The swat application is now ready to be accessed through the
following URL:
http://hostname:901 in any browser.

Start a browser and verify that it is accessible. (The root username and
password is used for swat authentication.)

Exercise Solutions: Creating Your Own Services

Task
1. Create a script called /opt/ses/labs/smf/run.boot.script that
writes “Hello World” to /opt/ses/labs/smf/test. Make sure execute
permissions are set on the script.
# cd /opt/ses/labs/smf
# cat run.boot.script
#!/bin/sh
echo "Hello World" > /opt/ses/labs/smf/test
# chmod 744 run.boot.script
2. Create a manifest for the service named test.xml in the directory
/var/svc/manifest/site by executing the following command:
# svccfg export system/utmp > /var/svc/manifest/site/test.xml
This will provide a template, but you should make modifications to
this file for your service consulting the “Writing a Service” section in
the Student Guide. There is more than one solution, but one is
provided in the solution section.
# cd /var/svc/manifest/site/
# cat test.xml
<?xml version=’1.0’ encoding=’UTF-8’?>
<!DOCTYPE service_bundle SYSTEM ’/usr/share/lib/xml/dtd/service_bundle.dtd.1’>
<service_bundle type=’manifest’ name=’test’>
<service
name=’site/test’
type=’service’
version=’1’>
<create_default_instance enabled=’false’/>
<single_instance/>
<exec_method
type=’method’
name=’start’
exec=’/opt/ses/labs/smf/run.boot.script’
</exec_method>
<exec_method

type=’method’
name=’stop’
exec=’:kill’
</exec_method>

<propval name=’duration’ type=’astring’ value=’transient’/>
</property_group>
</service>
</service_bundle>
3. Validate the test.xml file with the svccfg command.
# svccfg validate /var/svc/manifest/site/test.xml
If errors are returned, fix the errors before proceeding.
4. Import the manifest into the repository.
# svccfg -v import /var/svc/manifest/site/test.xml
svccfg: Taking "initial" snapshot for svc:/site/test:default.
svccfg: Taking "last-import" snapshot for svc:/site/test:default.
svccfg: Refreshed svc:/site/test:default.
If there is an error that it cannot parse the document, check to make
sure there are no typographical errors in the path name. If the same
service has been imported more than once, the output will be slightly
different as it updates the snapshot.
5. Verify the service has been added.
# svcs test
If the service is already online, a default instance was created by a
line in the XML file:
<create_default_instance enabled=’true’/>
6. Enable the service.
# svcadm enable test
7. Verify the service has started running.
# svcs test
online 17:01:22 svc:/site/test:default
8. Verify that your script ran properly.
# more /opt/ses/labs/smf/test
Hello World
9. Disable the service.

# svcadm disable test

10. Verify that the service has been disabled.
# svcs test
A service may first appear in maintenance mode if the process
described in the manifest exits ungracefully. When this happens, the
repository tags the service for maintenance. Enter the command
again to disable it.
11. Delete the service.
# svccfg delete test
# svcs test
svcs: Pattern ’svc:/site/test’ doesn’t match any instances
STATE STIME FMRI

Module 2
Introducing the Solaris OS Directory

Hierarchy
Objectives
Upon completion of this module, you should be able to identify System
Directory Changes.
2-1
Objectives
Relevance
Discussion – The following questions are relevant to understanding

directory changes in the Solaris 10 OS
!
?
● Which disk based directories are now in-memory?
● What are new directories (and removed directories) in the Solaris 10
OS?
● Which directories have been renamed or relocated in the Solaris 10
OS?


Introducing the Solaris OS Directory Hierarchy 2-3

System Directory Changes
In-Memory versus On-disk System Directories

The following table shows the directories that used to reside on disk prior
to the Solaris 10 OS but now reside in memory..
Table 2-1 In-Memory System Directories
/dev/fd The directory that contains special files

relating to current file-descriptors in use by
the system.
/devices The primary directory for physical device
names.
/etc/mnttab A memory-based file, in its own file system,
that contains details of current file system
mounts.
/etc/svc/volatile The directory that contains log files and
(new in Solaris 10 OS) reference files relating to the current state of
system services.
/proc The directory that stores current
process-related information. Every process has
its own set of subdirectories below the /proc
directory.
/system/contract CTFS (the contract file system) is the interface
(new in Solaris 10 OS) 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 to track the processes which
compose a service, so that a failure in a part of
a multi-process service can be identified as a
failure of that service.
The contract file system supports all the SMF

services.

Table 2-1 In-Memory System Directories (Continued)

/system/object The OBJFS (object) file system describes the
(new in Solaris 10 OS) 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. It
is used primarily for DTrace activity.
/tmp The directory for temporary files.
/var/run The directory that contains lock files, special
files, and reference files for a variety of system
processes and services.
The system/contact file system keeps track of processes including those resulting from zones. In the case of
those resulting from zones the command ctstat shows that processes are owned based on a zone id #.
Note – These in-memory directories are maintained by the kernel and

system services. Users should never attempt to manually create, alter, or
remove files from these directories.
Directory Name Changes and New/Old Directories

The following table lists some new directories and directory name
changes of interest in the Solaris 10 OS...
Table 2-2 Directory Name Changes and New Directories
/etc/svc The Service Management Facility database and

(new in Solaris 10 OS) log files
/var/svc The Service Management Facility manifest and
(new in Solaris 10 OS) profiles
/etc/zones Initialization and reference files for the Solaris
(new in Solaris 10 OS) 10 OS Zones facility
/usr/jdk Directories that contain Java™ technology
(name changed in programs and libraries
Solaris 10 OS)
/etc/openwin Directory that contains CDE (Common
(removed in Solaris 10 Desktop Environment) profiles
OS)
Introducing the Solaris OS Directory Hierarchy 2-5

Module 3
Managing Local Disk Devices
Objectives
Upon completion of this module, you should be able to:
● Identify changes to the format command
● Implement EFI disk labels
● Identify changs to the behavior of the devfsadm command
3-1
Objectives
Relevance
Discussion – The following questions are relevant to understanding new

device features in the Solaris 10 OS?
!
?
● How has the format command changed in the Solaris 10 OS?
● How has the behavior of the devfsadm command changed in the
Solaris 10 OS?


● System Administration Guide: Advanced Administration, PN 817-
● System Administration Guide: Devices and File Systems, PN 817-6960
● The EFI specification at:
http://www.intel.com/technology/efi/main_specification.htm
Managing Local Disk Devices 3-3

Listing a System’s Devices
The format Command

Engage the students and keep the training interactive by having one of them execute the format command
on a lab system in a shared window for all to see.
Array Tags in format Output
In the Solaris 10 OS one of the tag names shown in the output of the
format command changed to Sun StorEdgeTM Volume Manager (from
Veritas Volume Manager). This reflects the use of the newer storage
product.
format Command Menus
The format command now supports the -e option which is the scsi expert
option. When invoked with this option the following format menu output
shows (in bold) new submenu entries after you select a disk to work with.
FORMAT MENU:
disk - select a disk
type - select (define) a disk type
partition - select (define) a partition table
current - describe the current disk
format - format and analyze the disk
repair - repair a defective sector
label - write label to the disk
analyze - surface analysis
defect - defect list management
backup - search for backup labels
verify - read and display labels
save - save new disk/partition definitions
inquiry - show vendor, product and revision
scsi - independent SCSI mode selects
cache - enable, disable or query SCSI disk cache
volname - set 8-character volume name
!<cmd> - execute <cmd>, then return
quit
format>
The cache and scsi submenus will display only for supported SCSI
devices (and only if you use the -e option with the format command).

Following are the choices in the scsi submenu:

format> scsi
Warning: these functions are intended for expert use only, for
debugging disk devices and for unusual configuration settings.
It is recommended that you do not use this menu for normal disk
configuration and formatting, unless you have explicit instructions,
or know exactly what you are doing.
SCSI MENU:
p<n> - display a mode sense page
p<n> b<n> <op> [~]<n> - change a byte and issue mode select
b<n> <op> [~]<n> - add an operation to the mode select list
for the current page
where: p<n> specifies the page with page code <n>

b<n> specifies byte <n> of the page
<op> can be one of the following operators:
= (set specified value)
|= (bitwise OR with current value)
&= (bitwise AND with current value)
<n> can be a decimal value in the range 0-255,
or two hexadecimal digits, in the form 0x<xx>.
[~] complements the specified value
apply - apply mode select list

cancel - cancel mode select list
display - display mode select list
all - display all supported mode sense pages
default p<n> - mode select page <n> to default values
default all - mode select all pages to default values
format - format without standard mode selects
inquiry - display device's inquiry response
list - list common SCSI-2 mode pages
!<cmd> - execute <cmd> , then return
quit
scsi>
Be sure students see the warning associated with this expert menu.
Following are the choices in the cache submenu:

format> cache
CACHE MENU:

write_cache - display or modify write cache settings

read_cache - display or modify read cache settings
!<cmd> - execute <cmd>, then return
quit
cache>
Again, this is an expert menu.
Format Sizing Specifications
After the release of the Solaris 8 OS and before the first release of the
Solaris 9 OS, the format command supported specifiying the ending
cylinder size as an alternative way to size a partition.
For example, in the Solaris 8 OS, the prompt for entering a partition size is
is shown below (bolded):
....
partition> 3
Part Tag Flag Cylinders Size Blocks
3 unassigned wm 0 0 (0/0/0)
0
Enter partition id tag[unassigned]:

Enter partition permission flags[wm]:
Enter new starting cyl[0]: 52
Enter partition size[0b, 0c, 0.00mb, 0.00gb]:
By comparision, the partition size prompt in the Solaris 9 and 10

Operating Systems now has an ending cylinder specification option
(bolded) as follows:
...
partition> 3
3 unassigned wm 12312 - 18467 8.48GB (6156/0/0)
17784684
Enter partition id tag[unassigned]:

Enter partition permission flags[wm]:
Enter new starting cyl[12312]:
Enter partition size[17784684b, 6156c, 18467e, 8683.93mb, 8.48gb]:

Multiterabyte Volume Support With EFI Disk Labels

This multiterabyte disk support is available only for systems that run a
64-bit kernel. This feature is new in the Solaris 9 4/03 release.
The Solaris 9 4/03 release provides support for disks that are larger than 1
terabyte (Tbyte) on systems that run a 64-bit Solaris kernel.
The Extensible Firmware Interface (EFI) label provides support for

physical disks and virtual disk volumes. The UFS file system is
compatible with the EFI disk label, and you can create a UFS file system
that is greater than 1 Tbyte. This release also includes updated disk
utilities for managing disks that are greater than 1 Tbyte.
The EFI disk label differs from the VTOC disk label in the following ways:
● Support for disks that are greater than 1 Tbyte in size is provided.
● Slices 0-6, where slice 2 is just another slice, are provided.
● Partitions, or slices, cannot overlap with the primary or backup label,
nor with any other partitions. The size of the EFI label is usually 34
sectors, so partitions start at sector 34. This feature means that no
partition can start at sector zero (0).
● No cylinder, head, or sector information is stored in the label. Sizes
are reported in blocks.
● Information that was stored in the alternate cylinders area, the last
two cylinders of the disk, is now stored in slice 8.
● If you use the format utility to change partition sizes, the unassigned
partition tag is assigned to partitions with sizes equal to zero. By
default, the format utility assigns the usr partition tag to any
partition with a size greater than zero. You can use the partition
change menu to reassign partition tags after the partitions are
changed. However, you cannot change a partition with a non-zero
size to the unassigned partition tag.
Keep the following restrictions in mind when determining whether to use

disks greater than 1 terabyte is appropriate for your environment:
● The SCSI driver, ssd, currently only supports up to 2 terabytes. If
you need greater disk capacity than 2 terabytes, use a volume
management product like Solaris Volume Manager to create a larger
device.

● Layered software products intended for systems with EFI-labeled

disks might be incapable of accessing a disk with an EFI disk label.
● A disk with an EFI disk label is not recognized on systems running
previous Solaris releases.
● The EFI disk label is not supported on IDE disks.
● You cannot use the Solaris Management Console's Disk Manager
Tool to manage disks with EFI labels. Use the format utility to
partition disks with EFI labels. Then, you can use the Solaris
Management Console's Enhanced Storage Tool to manage volumes
and disksets with EFI-labeled disks.
● The EFI specification prohibits overlapping slices. The whole disk is
represented by cxtydz.
● Information about disk or partition sizes is given in sectors and
blocks, but not in cylinders and heads.
● The following format options are either not supported or are not
applicable on disks with EFI labels:
● The save option is not supported because disks with EFI labels
do not need an entry in the format.dat file.
● The backup option is not applicable because the disk driver
finds the primary label and writes it back to the disk.
EFI Labels and the format Command
The format command has been enhanced to support EFI labelling.
Following is an example of labeling choices for disks that support EFI

labelling:
# format -e
Searching for disks...done
AVAILABLE DISK SELECTIONS:
1. c1t0d0 <SUNW18g cyl 7506 alt 2 hd 19 sec 248>
/sbus@2,0/QLGC,isp@2,10000/sd@0,0
/sbus@2,0/QLGC,isp@2,10000/sd@1,0
/sbus@2,0/QLGC,isp@2,10000/sd@8,0
/sbus@2,0/QLGC,isp@2,10000/sd@9,0
Specify disk (enter its number): 4
selecting c1t9d0
[disk formatted]

format> label
[0] SMI Label
[1] EFI Label
Specify Label type[0]: 1
Ready to label disk, continue? yes
format> quit
The following example shows the disk label information for disk with a
VTOC label.
# prtvtoc /dev/rdsk/c0t0d0s0
* /dev/rdsk/c0t0d0s0 partition map
*
* Dimensions:
* 512 bytes/sector
* 63 sectors/track
* 15 tracks/cylinder
* 945 sectors/cylinder
* 8894 cylinders
* 8892 accessible cylinders
*
* Flags:
* 1: unmountable
* 10: read-only
*
* First Sector Last
* Partition Tag Flags Sector Count Sector Mount Directory
0 2 00 1048950 3381210 4430159 /
1 3 01 0 1048950 1048949
2 5 00 0 8402940 8402939
7 8 00 4430160 3972780 8402939 /export/home
The following example shows the disk label information for disk with an
EFI label.
*
* Dimensions:
* 512 bytes/sector
* 2479267840 sectors
* 2479267773 accessible sectors
*
* Flags:
* 1: unmountable
* 10: read-only
*

* First Sector Last

* Partition Tag Flags Sector Count Sector Mount
Directory
0 2 00 34 262144 262177
1 3 01 262178 262144 524321
6 4 00 524322 2478727100 2479251421
8 11 00 2479251422 16384 2479267805
After the Solaris release is installed on a system with an EFI-labeled disk,

the partition table looks similar to the following:
Current partition table (original):
Total disk sectors available: 2576924638 + 16384 (reserved sectors)
Part Tag Flag First Sector Size Last Sector

0 root wm 34 1.20TB
2576924636
1 unassigned wm 0 0 0
8 reserved wm 2576924638 8.00MB
2576941021
There is bug logged which discusses an issue where if an EFI label is written to a disk that has an SMI label
the slice 7 still shows (it shouldn’t). The workaround is to quit the format command and re-invoke it (with the
-e option). The CR is 6290529: format displays slice 7 after converting disk to EFI label.
In a shared web browser, show students where much more of this information is available:
http://docs.sun.com/app/docs/coll/47.22?q=EFI+labels (The Solaris 9 9/04 System Administrator

Collection.)

Reconfiguring Devices
/devices and /dev Directory Link Changes

The behavior of the devfsadm command in the Solaris 10 OS has changed
with respect to the /devices directory and the links in the /dev directory.
The devfsadm command attempts to load every driver in the system and
attach all possible device instances. It then creates symbolic links in the
/devices directory and the logical links in the /dev directory to the
kernel maintained device files. In addition to managing these directories,
the devfsadm command also maintains the /etc/path_to_inst file.
Following is captured interaction on a sytem where the device

configuration was changed and the devfsadm command used to
implement the new configuration.
The first example shows 2 disk devices on a system before a new disk
device is added:
# cd /devices/pci@1f,0/pci@1,1/scsi@2
# ls -l
total 4
drwxr-xr-x 2 root sys 512 Jan 31 17:18 sd@0,0

brw-r----- 1 root sys 32, 16 Jan 31 17:18 sd@0,0:a
crw-r----- 1 root sys 32, 16 Feb 3 09:54 sd@0,0:a,raw
brw-r----- 1 root sys 32, 17 Feb 3 09:39 sd@0,0:b
crw-r----- 1 root sys 32, 17 Feb 3 09:54 sd@0,0:b,raw
...
brw-r----- 1 root sys 32, 23 Feb 3 09:54 sd@0,0:h
crw-r----- 1 root sys 32, 23 Feb 3 09:54 sd@0,0:h,raw
...
drwxr-xr-x 2 root sys 512 Jan 31 17:18 sd@1,0
brw-r----- 1 root sys 32, 0 Feb 3 09:54 sd@1,0:a
crw-r----- 1 root sys 32, 0 Feb 3 09:54 sd@1,0:a,raw
brw-r----- 1 root sys 32, 1 Feb 3 09:54 sd@1,0:b
crw-r----- 1 root sys 32, 1 Feb 3 09:54 sd@1,0:b,raw
...
brw-r----- 1 root sys 32, 7 Feb 3 09:54 sd@1,0:h
crw-r----- 1 root sys 32, 7 Feb 3 09:54 sd@1,0:h,raw
#

The next example shows the links in support of the current configuration
and above output:
# cd /dev/dsk
# ls -l
total 48
...
lrwxrwxrwx 1 root root 46 Jan 31 17:17 c0t0d0s0 ->
../../devices/pci@1f,0/pci@1,1/scsi@2/sd@0,0:a
../../devices/pci@1f,0/pci@1,1/scsi@2/sd@0,0:b
...
../../devices/pci@1f,0/pci@1,1/scsi@2/sd@0,0:h
...
...
The following example shows the corresponding existing entries in the

/etc/path_to_inst file:
# more /etc/path_to_inst
...
"/pci@1f,0/pci@1,1/scsi@2/sd@0,0" 2 "sd"
Another disk device was added at address 3 and turned on. Following is
the execution of the devfsadm command to implement the new device
configuration:
# devfsadm -v
devfsadm[1678]: verbose: symlink /dev/dsk/c0t3d0s0 ->
../../devices/pci@1f,0/pci@1,1/scsi@2/sd@3,0:c
../../devices/pci@1f,0/pci@1,1/scsi@2/sd@3,0:d
../../devices/pci@1f,0/pci@1,1/scsi@2/sd@3,0:e


../../devices/pci@1f,0/pci@1,1/scsi@2/sd@3,0:f
../../devices/pci@1f,0/pci@1,1/scsi@2/sd@3,0:g
devfsadm[1678]: verbose: symlink /dev/rdsk/c0t3d0s0 ->
../../devices/pci@1f,0/pci@1,1/scsi@2/sd@3,0:a,raw
../../devices/pci@1f,0/pci@1,1/scsi@2/sd@3,0:b,raw
../../devices/pci@1f,0/pci@1,1/scsi@2/sd@3,0:c,raw
../../devices/pci@1f,0/pci@1,1/scsi@2/sd@3,0:d,raw
../../devices/pci@1f,0/pci@1,1/scsi@2/sd@3,0:e,raw
../../devices/pci@1f,0/pci@1,1/scsi@2/sd@3,0:f,raw
../../devices/pci@1f,0/pci@1,1/scsi@2/sd@3,0:g,raw
../../devices/pci@1f,0/pci@1,1/scsi@2/sd@3,0:h,raw
The next example displays the new links to the devices under the
/dev/dsk directory:
# cd /dev/dsk
# ls -l
total 64
...
lrwxrwxrwx 1 root other 46 Feb 3 10:17 c0t3d0s0 ->
../../devices/pci@1f,0/pci@1,1/scsi@2/sd@3,0:c
../../devices/pci@1f,0/pci@1,1/scsi@2/sd@3,0:d
../../devices/pci@1f,0/pci@1,1/scsi@2/sd@3,0:e
../../devices/pci@1f,0/pci@1,1/scsi@2/sd@3,0:f
../../devices/pci@1f,0/pci@1,1/scsi@2/sd@3,0:g

The final example shows the new entry made to the path_to_inst file for
the disk device at address 3:
# cat /etc/path_to_inst

Module 4
Managing the Solaris OS File System
Objectives
● Identify changes related to pseudo file systems
● Describe features of the Multiterabyte UFS
● Describe changes related to logging in UFS
● Describe the default behaviour and output of the mount command
with respect to logging in the UFS
● Describe the meaning of the devices flag of the mount command
4-1
Objectives
Relevance
Discussion – The following questions are relevant to understanding file

system changes in the Solaris 10 OS:
!
?
● What are the new pseudo file systems implemented in the Solaris 10
OS?
● How has the size of the UFS file system changed in the Solaris 10
OS?
● What is the default setting for logging in the UFS?
● How can you tell if logging is enabled for mounted UFS file systems?


● System Administration Guide: Devices and File Systems, PN 817-6960
Managing the Solaris OS File System 4-3

Pseudo File Systems
Pseudo File Systems

Pseudo file systems are memory based. These file systems provide for
better system performance, in addition to providing access to kernel
information and facilities. Pseudo file systems new in the Solaris 10 OS
include:
● objfs – The kernel object file system. This file system is used by the
kernel to store details relating to the modules currently loaded by the
kernel. The object file system is used for the /system/object
directory.
● devfs – The device file system is used to manage the namespace of
all devices on the system. This file system is used for the /devices
directory.
● ctfs – The contract file system is associated with the
/system/contract directory. This is used by the Service
Management Facility to track the processes which compose a service,
so that a failure in a part of a multi-process service can be identified
as a failure of that service.
To see the file system types currently in use, have the students issue the mount -p command.
Pseudo File Systems in the /etc/vfstab File

This section contains a number of command examples and output. Engage the students and keep the
training interactive by having them execute them on a lab system in a shared window for all to see.
The /etc/vfstab file in the Solaris 10 OS shows the directives and

specifications for the mounting of these new files systems (bolded).
# cat /etc/vfstab
#device device mount FS fsck mount mount
#to mount to fsck point type pass at boot options
#
fd - /dev/fd fd - no -
/proc - /proc proc - no -
/dev/dsk/c0t0d0s1 - - swap - no -
/dev/dsk/c0t0d0s0 /dev/rdsk/c0t0d0s0 / ufs 1 no -
/dev/dsk/c0t0d0s6 /dev/rdsk/c0t0d0s6 /usr ufs 1 no -
/dev/dsk/c0t0d0s3 /dev/rdsk/c0t0d0s3 /var ufs 1 no -
/dev/dsk/c0t0d0s7 /dev/rdsk/c0t0d0s7 /export/home ufs 2 yes -
/devices - /devices devfs - no -
ctfs - /system/contract ctfs - no -
objfs - /system/object objfs - no -
swap - /tmp tmpfs - yes -
#

Multiterabyte UFS File Systems

Multiterabyte UFS file system support is available only for systems that
run a 64-bit kernel. This feature is new in the Solaris 9 8/03 release.
The Solaris 9 8/03 release provides support for multiterabyte UFS file
systems on systems that run a 64-bit Solaris kernel. Previously, UFS file
systems were limited to approximately 1 terabyte (Tbyte) on both 64-bit
systems and 32-bit systems. All UFS file system commands and utilities
have been updated to support multiterabyte UFS You can initially create a
UFS file system that is less than one Tbyte.
You can specify that the file system can eventually be grown to a
multiterabyte file system by using the newfs -T command. This
command sets the inode and fragment density to scale appropriately for a
multiterabyte file system.
Support for a multiterabyte UFS file system assumes the availability of

multiterabyte LUNs. These LUNS are provided as Solaris Volume
Manager or Veritas VxVM volumes, or as physical disks that are greater
than one Tbyte.
Features of multiterabyte UFS file systems include the following:

● You can create a UFS file system to a maximum of 16 Tbytes in size.
● You can create a file system that is less than 16 Tbytes, which can
later be increased in size to a maximum of 16 Tbytes.
● Multiterabyte file systems can be created on physical disks, Solaris
Volume Managerís logical volumes, and Veritas’s VxVM logical
volumes.
● UFS logging is enabled by default. Multiterabyte file systems benefit
from the performance improvements of having UFS logging enabled.
Multiterabyte file systems also benefit from the availability of
logging because the fsck command might not have to be run when
logging is enabled.
Limitations of multiterabyte UFS file systems include the following:

● You cannot mount a file system that is greater than 1 Tbyte on a
system that runs a 32-bit Solaris kernel.
● You cannot boot from a file system that is greater than 1 Tbyte. This
limitation means that you cannot put a root (/) file system on a
multiterabyte file system.

● There is no support for individual files greater than 1 Tbyte.

● The maximum number of files per terabyte of UFS file system is 1
million. This limit is intended to reduce the time it takes to check the
file system with the fsck command.
● The maximum quota that you can set on a multiterabyte UFS file
system is 2 Tbytes of 1024 byte blocks.
● Using the fssnap command to create a snapshot of a multiterabyte
UFS file system is not currently supported.
UFS Logging Enabled by Default

This feature was introducted in the Solaris 9 9/04 release.
Logging is now enabled by default for all UFS file systems except under
the following conditions:
● When logging is explicitly disabled
● If insufficient file system space exists for the log
In Solaris releases prior to Solaris 9 9/04, you had to enable UFS logging
explicitly.
UFS logging packages into a transaction the multiple metadata changes

that compose a complete UFS operation. Sets of transactions are recorded
in an on-disk log, and then applied to the actual UFS file systemís
metadata.
UFS logging provides two advantages:

● If the file system is already consistent because of the transaction log,
you might not have to run the fsck command after a system crash or
an unclean shutdown.
● Starting in the Solaris 9 12/02 release, the performance of UFS
logging improves or exceeds the level of performance of nonlogging
file systems. This improvement can occur because a file system with
logging enabled converts multiple updates to the same data into
single updates. This capability reduces the number of overhead disk
operations that are required.

Logging and the /etc/vfstab File

In the Solaris 9 OS, you use the logging directive in the mount options
column of the /etc/vfstab file if a file system was to be mounted with
logging enabled. For example:
# cat /etc/vfstab
#device device mount FS fsck mount mount
#to mount to fsck point type pass at boot options
#
...
/dev/dsk/c1t0d0s7 /dev/rdsk/c1t0d0s7 /database ufs 1 yes logging
...
In the Solaris 10 OS, because logging is enabled by default for UFS file
systems, the directive is no longer needed.
The nologging mount command option still is supported.

New mount Command Flags

Since the Solaris 9 9/04 release, new flags now appear in the output of the
mount command.
logging flag
Since the Solaris 9 9/04 release, logging is enabled by default for all UFS
file systems. The mount command output shows the logging flag as the
default. If logging is disabled, the nologging flag appears.
devices flag
Also introducted at that time was the devices flag which is the default
value (as opposed to nodevices). The devices flag indicates that the
opening of device-special files is allowed.
The following mount command output shows these flags bolded:

# mount
/ on /dev/dsk/c0t0d0s0
read/write/setuid/devices/intr/largefiles/logging/xattr/onerror=panic/dev=22000
08 on Sun Oct 24 08:57:24 2004
/devices on /devices read/write/setuid/devices/dev=4a80000 on Sun Oct 24
08:57:00 2004
/system/contract on ctfs read/write/setuid/devices/dev=4ac0001 on Sun Oct 24
08:57:00 2004
/proc on proc read/write/setuid/devices/dev=4b00000 on Sun Oct 24 08:57:00 2004
/etc/mnttab on mnttab read/write/setuid/devices/dev=4b40001 on Sun Oct 24
08:57:00 2004
/etc/svc/volatile on swap read/write/setuid/devices/xattr/dev=4b80001 on Sun
Oct 24 08:57:00 2004
/system/object on objfs read/write/setuid/devices/dev=4bc0001 on Sun Oct 24
08:57:00 2004
/usr on /dev/dsk/c0t0d0s6
0e on Sun Oct 24 08:57:25 2004
/dev/fd on fd read/write/setuid/devices/dev=4d40001 on Sun Oct 24 08:57:25 2004
/var on /dev/dsk/c0t0d0s3
0b on Sun Oct 24 08:57:27 2004
/var/run on swap read/write/setuid/devices/xattr/dev=4b80002 on Sun Oct 24
08:57:27 2004
/tmp on swap read/write/setuid/devices/xattr/dev=4b80003 on Sun Oct 24 08:57:27
2004

/export/home on /dev/dsk/c0t0d0s7
0f on Sun Oct 24 08:57:41 2004
There exists a bug with the umountall command (#4687955) which concerns a number of options to the
umountall command not working. As of the writing of this course, this fix has been delivered and scheduled
to release with build 22 of the Solaris 10 OS.

Module 5
Installing the Solaris OS
Objectives
● Describe the installation methods available for the Solaris 10 OS
● State the installation requirements for the Solaris 10 OS
● Describe additional software groups introduced in the Solaris 10 OS
5-1
Objectives
Relevance
Discussion – The following questions are relevant to understanding how

installation works in the new Solaris 10 OS:
!
?
● What are the various installation methods available for installing the
Solaris 10 OS.
● How differently does the Solaris 10 OS install than prior releases?


● The How To Guides at www.sun.com:
(http://www.sun.com/software/solaris/reference_resources.jsp#ho
wto)
Installing the Solaris OS 5-3

Installation Methods
There are two ways to install the Solaris 10 OS on your system,
suninstall and Flash installation.
Solaris 10 OS Installation and Upgrade Options

There are a number of different ways the installation can take place:
● Solaris installation Graphical User Interface (GUI)
● Solaris installation Command Line Interpreter (CLI)
● Solaris Custom JumpStart™ software (JumpStart) installation
● Solaris Flash Archives
● Solaris WAN boot installation
● Solaris Upgrade method
Note – The Solaris 10 OS contains a new GUI interface for installation.

The older OpenWindows based GUI of Solaris 8 releases is no longer
used. Neither is the Tab Window Manager (TWM) based GUI used in the
Solaris 9 OS. Also, the Webstart method used for Solaris 8 OS installations
is no longer used.
Solaris Installation Command Line Interpreter (CLI)

Hosts which do not have a graphical screen cannot run the GUI
installation. Starting the installation with the nowin argument allows all
the questions and answers to be completed in a text-only environment.
Options are provided in menu format with the spacebar being used to
select options and F2, (or the equivalent escape key sequence), being used
to accept selected options.
● 64-127 Mbytes starts with nowin
● 128-383 Mbytes starts a GUI window with a text-based install
running in it
● 384-511 Mbytes starts up the GUI interface
● 512 Mbytes and higher starts the installation kiosk

Solaris WAN Boot

The WAN boot installation method enables you to boot and install
software over a wide area network (WAN) by using HTTP/HTTPS. 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 HTTPS connection by configuring your
systems to use digital certificates.
Wan Boot is covered in more detail (along with a lab exercise) at the end of the course.

Installation Requirements for the Solaris 10 OS

This section covers hardware and software requirements for Solaris 10 OS
installation.
Solaris 10 OS Hardware Requirements for Installation

A Solaris 10 OS installation requires the following:
● 256 Mbytes of memory (512 Mbytes recommended)
● At least 5 Gbytes of disk space
● Access to a CD-ROM/DVD drive or an installation server
Table 5-1 and Table 5-2 on page 5-7 show additional details about
memory, swap, and processor requirements for the Solaris 10 OS
installation.
Table 5-1 SPARC: Memory, Swap, and Processor Recommendations
Size
Memory to 256 MB is the recommended size. 128 MB is the

install or minimum size.
upgrade
Some optional installation features are enabled only
when sufficient memory is present. For example, if
you install from a DVD with insufficient memory, you
install through the Solaris installation program's text
installer, not through the GUI.
Swap area 512 MB is the default size.
You might need to customize the swap space. Swap
space is based on the size of the system's hard disk.
Processor 200–MHz or faster processor is required.
requirements

Table 5-2 x86: Memory, Swap, and Processor Recommendations
Size
Memory to Starting with the Solaris 10 1/06 release, 512 MB is the

install or recommended size. 256 MB is the minimum size.
upgrade
For the Solaris 10 3/05 release, 256 MB is the
recommended size. 128 MB is the minimum size.
Some optional installation features are enabled only

when sufficient memory is present. For example, if
you install from a DVD with insufficient memory, you
install through the Solaris installation program's text
installer, not through the GUI.
Swap area 512 MB is the default size.
You might need to customize the swap space. Swap

space is based on the size of the system's hard disk.
Processor 120–MHz or faster processor is recommended.
requirements Hardware floating-point support is required.
Memory Requirements for Display Options During

Installation
You can choose to install the software with a GUI or with or without a
windowing environment. If there is sufficient memory, the GUI is
displayed by default. Other environments are displayed by default if
memory is insufficient for the GUI. 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, it automatically displays in a
console-based environment.The amount of memory in the system
determines the display options during installation.

Table 5-3 and Table 5-4 describe SPARC and x86 platform memory
requirements for display options.
Table 5-3 SPARC: Memory Requirements for Display Options
Size
128–383 MB Text-based Contains no graphics, but provides a window and the

ability to open other windows.
If you install by using the text boot option and the

system has enough memory, you are installing in a
windowing environment. If you are installing
remotely through a tip line or using the nowin boot
option, you are limited to the console-based
installation.
384 MB or GUI-based Provides windows, pull-down menus, buttons,
greater scrollbars, and iconic images.
Table 5-4 x86: Memory Requirements for Display Options
Size
Starting with the Text-based Contains no graphics, but provides a window

Solaris 10 1/06 and the ability to open other windows.
release: 256–511 MB
If you install by using the text boot option and
For the Solaris 10 the system has enough memory, you are
3/05 release: 128–383 installing in a windowing environment. If you
MB are installing remotely through a tip line or using
the nowin boot option, you are limited to the
console-based installation.
Starting with the GUI-based Provides windows, pull-down menus, buttons,
Solaris 10 1/06 scrollbars, and iconic images.
release: 512 MB
For the Solaris 10

3/05 release: 384 MB
LVC Ref: http://docs.sun.com/app/docs/doc/817-0544, chapter 1

Installation Media
The Solaris 10 OS is available on a set of CD-ROMs or all on a single
DVD-ROM. Following are the contents of the CD-ROM set.
● Solaris 10 OS Software 1 – This CD is the only bootable CD. From
this CD, you can access both the Solaris OS installation graphical
user interface (GUI) and the console-based installation.
● Solaris 10 OS Software 2 - This CD contains Solaris OS packages
which the software prompts you to install if necessary.
which the software prompts you to install if necessary.
which the software prompts you to install if necessary and
ExtraValue software.
● Solaris 10 OS Languages CD - This CD contains translated message
files and other software in languages other than English.
Solaris OS Software Groups

Software groups are collections of Solaris OS software packages. Each
software group includes support for different functions and hardware
drivers. The Solaris 10 OS is made up of seven software groups:
● Minimal Core Metacluster (new in the Solaris 10 OS)
● Reduced Networking Support software group (new in the Solaris 10
OS)
● Core System Support software group
● End User Solaris software group
● Developer Solaris software group
● Entire Solaris software group
● Entire Solaris software group plus Original Equipment
Manufacturers (OEM) support
Minimal Core Metacluster (SUNWCmreq)
This is a new metacluster. The metacluster SUNWCmreq is a hidden

metacluster. It allows you to create a minimal core metacluster by
deselecting packages from the core metacluster.

Reduced Network Support Software Group (SUNWCrnet)
This is a new metacluster. This group contains the minimum software that
is required to boot and run a Solaris system with limited network service
support. The Reduced Networking 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.
A system installed with the Reduced Networking software group could,

for example, be used as a thin-client host in a network.
Specific Configuration Changes During Text-Based

Solaris Installation
Following are new prompts encountered during the CLI installation of the
Solaris 10 OS.
● If your system has more than one network interface, you are
prompted to select each network interface that you want to
configure, and select which network interface you want to be your
primary interface.
● The Set the Default Route window now appears. In this window, you
can let the operating system try to find a default route, you can
specify one or you can select none.
● A license agreement window now displays that must be scrolled
through and explicitly accepted.
● A choice of which locale to use is presented.
● There might be extra products on the installation media that you
have an opportunity to select for installation.
● The following description displays concerning NFS version 4:
This system is configured with NFS version 4, which uses a domain
name that is automatically derived from the system’s name services.
The derived domain name is sufficient for most configurations. In a
few cases, mounts that cross different domains might cause files to
be owned by "nobody" due to the lack of a common domain name.
Do you need to override the system’s default NFS version 4 domain

name (yes/no) ? [no] :

The Solaris 10 OS supports versions 2, 3, and 4 NFS simultaneously.

The default is to use NFSv4 software when sharing a directory or
accessing a shared file. Version-related checks are applied whenever
a client host attempts to access a server’s file share. If all hosts in the
network are installed with Solaris 10 OS, then all hosts should, by
default, use the NFSv4 protocols.
● You no longer get prompted to install the Solaris 64-bit packages
because only 64 bit is supported for Sparc based systems.
x86 still supports 32 bit Solaris for platforms that are only 32 bit
capable.
Partitioning and File Systems
Be default, in the Solaris 10 OS, the installation methods create only the
root file sysem, the /export/home file system and a swap partition.

Solaris x86/x64 Installation and GRUB

Solaris 10 Update 1 introduces the use of the GRand Unified Bootloader
(GRUB) open source bootloader version .95. (The Device Conguration
Assistant and associated interactive shell are no longer present.) The
Solaris kernel is fully compliant with Multiboot Specification 2 and
therefore can be booted with GRUB which implements this specification.
Benefits of using GRUB include:

● Booting and installing from USB DVD drives is now supported.
● Solaris can coexist with other operating systems on the same
machine.
● Deploying Solaris via the network is simplied, particularly in the
area of DHCP server setup.
● Developers no longer need to deal with realmode drivers, which
were part of the old Solaris boot loader.
● Independent Hardware Vendors (IHVs) can deliver drivers at install
times via CD/DVD.
● By adopting a boot loader developed by the open source community,
existing experience can be leveraged.
Editting the GRUB Menu to Modify Boot Behavior
The GRUB menu displays after the system boots and the memory test and
hardware detection phase is completed.
GNU GRUB version 0.95 (631K lower / 2095488K upper memory)
+---------------------------------------------------------------------+
| Solaris
| Solaris Serial Console ttya
| Solaris Serial Console ttyb (for lx50, v60x and v65x)
|
|
+---------------------------------------------------------------------+
Use the ^ and v keys to select which entry is highlighted.
Press enter to boot the selected OS, 'e' to edit the
commands before booting, or 'c' for a command-line.

Typing the e command interrupts the boot procedure and initiates a

GRUB edit session. A list of entries that can be editting displays.
GNU GRUB version 0.95 (631K lower / 2095488K upper memory)
+---------------------------------------------------------------------+
| root (hd0,2,a)
| kernel /platform/i86pc/multiboot
| module /platform/i86pc/boot_archive
|
|
+---------------------------------------------------------------------+
Use the ^ and v keys to select which entry is highlighted.
Press 'b' to boot, 'e' to edit the selected command in the
boot sequence, 'c' for a command-line, 'o' to open a new line
after ('O' for before) the selected line, 'd' to remove the
selected line, or escape to go back to the main menu.
Use the up and down arrow keys to select a line for editting and type the
e command again to start editting that entry. After modifying the entry,
type Enter to save your changes and return to the GRUB menu or enter
ESC to return to the main GRUB boot selection menu without saving your
changes.
The module command entry references the boot archive. The boot archive
is a collection of core kernel modules and configuration files packed in
either ufs or isofs format. At boot time, GRUB loads the boot archive
into system memory. The kernel can now initialize itself from data and
text in the boot archive without performing I/O to the root device.
Once the kernel gains sufficient I/O capability, it mounts the root
filesystem on the real root device as specified by the bootpath property.
At this point, the boot archive loaded by GRUB is discarded from
memory.
The contents of the boot archive are specified in the

/boot/solaris/filelist.ramdisk file. When the system shuts down it
checks for updates to the root filesystem and updates the boot archive
when necessary. The system may manually update the boot archive prior
to system shutdown by running the bootadm(1M) command.

Using the kernel Command
The kernel command (kernel(1M)) entry boots the Solaris kernel.

Various options can be used with the kernel command. At installation
time default boot parameters are store in the
/boot/solaris/bootenv.rc file. When you use GRUB to edit this line
changes are made to the contents of this file.
The following kernel command line will boot a 64-bit capable x86 system
with a 32-bit kernel:
grub edit> kernel /platform/i86pc/multiboot kernel/unix
with a 32-bit kernel in single user mode:
grub edit> kernel /platform/i86pc/multiboot kernel/unix -s
The following kernel command line will set the console property to ttya:
grub edit> kernel /platform/i86pc/multiboot -B console=ttya
If the property value contains commas, it should be quoted as the

following console high speed example shows:
grub edit> kernel /platform/i86pc/multiboot /

-B console=ttya,ttya-mode="115200,8,n,1,-"
with a 32-bit kernel with the kernel debugger enabled:
grub edit> kernel /platform/i86pc/multiboot kernel/unix -k

Editing the menu.lst File
When you edit the GRUB menu during a GRUB edit session the
/boot/grub/menu.lst file is changed. You can manually modify this file
to effect the GRUB menu. For example to enable a fail-safe boot of Solaris
add the following lines to the /boot/grub/menu.lst file:
title Solaris fail-safe single user
root (hd0,1,a)
kernel /platform/i86pc/multiboot -B console=ttya -s
module /boot/x86.miniroot-safe
Note – The device/partition/slice specifications need to match your

particular system.
Edit the /boot/grub/menu.lst file directly to add entries for booting

other operating systems that are installed on the system. For examples,
assume the following operating systems are installed in the following
locations:
fdisk partition 0: Windows

fdisk partition 1: Linux
fdisk partition 2:
slice 0 Solaris 9
slice 3 Solaris 10 Update 1
Tell the students that GRUB starts counting partitions (not fdisk) at 0 and that GRUB sees the first disk a hd0
regardless of type.
Caution – It is possible to influence a system’s boot behavior by directly

editing the menu.lst file but it is not recommended. Changes would not be
preserved during a system upgrade. After upgrading, the changes would
need to be reapplied.
Edit the GRUB menu outside of that altered by the bootadm command so
that it looks like the following:
#---------- ADDED BY BOOTADM - DO NOT EDIT ----------

title Solaris 10 Update 1
root (hd0,2,d)
kernel /platform/i86pc/multiboot
module /platform/i86pc/boot_archive
#---------------------END BOOTADM--------------------
title Solaris 9
root (hd0,2,a)

chainloader +1
makeactive
title Linux
root (hd0,1)
kernel <from Linux's GRUB menu...>
initrd <from Linux's GRUB menu...>
title Windows
root (hd0,0)
chainloader +1
Note – Note that the Solaris fdisk partition must be the active partition.
Do not put use the makeactive directive under the Windows menu
otherwise the system will always boot Windows.
If Linux installed GRUB on the master boot block, you will not be able to
get to Solaris even if you make Solaris the active partition. In this case,
you can chainload from the Linux GRUB by modifying the menu on
Linux.
If students want to see a more complete writeup on the full x86/x64 installation, share a browser session for
all to see and examine the how to guild at www.sun.com:
http://www.sun.com/software/solaris/howtoguides/installationhowto.jsp
If you are teaching this class as an LVC, engage a student by having them do the above.

Influencing Boot Behavior

The boot behavior in the Solaris 10 Update 1 OS can be influenced or
changed in the following ways:
● Using the eeprom command
This method is recommended because changes made persist across
boot sessions and are preserved during a system upgrade.
● Using the kernel command
This method overrides any changes made by the eeprom command
method but only for the current boot session. Changes made using
the kernel command do not persist across system boots. The
kernel command is used while in the edit mode of an interrupted
GRUB boot.
● Direct editing of the menu.lst file
It is possible to influence a system’s boot behavior by editing the

menu.lst file but it is not recommended because changes would not
be preserved during a system upgrade. After upgrading, the changes
would need to be reapplied.
Using the eeprom Command
The eeprom command is used to assign a different value to a standard set

of properties. These values, which are the equivalent to the SPARC
OpenBoot PROM NVRAM variables, are stored in the
/boot/solaris/bootenv.rc file. Changes that are made to the Solaris
boot behavior by using the eeprom command persist over each system
reboot.
The following eeprom command displays the current values stored:

# eeprom
kbd-type=US-English
ata-dma-enabled=1
atapi-cd-dma-enabled=0
ttyb-rts-dtr-off=false
ttyb-ignore-cd=true
ttya-rts-dtr-off=false
ttya-ignore-cd=true
ttyb-mode=9600,8,n,1,-
ttya-mode=9600,8,n,1,-
lba-access-ok=1

prealloc-chunk-size=0x2000
bootpath=/pci@0,0/pci-ide@1f,1/ide@0/cmdk@0,0:a
console=ttya
The following eeprom commands change the number of megabytes to test

during power on self test from the current value to 5 and then back again:
# prtconf | grep Memory
Memory size: 1024 Megabytes
# eeprom selftest-#megs=5
# eeprom selftest-#megs
selftest-#megs=5
# eeprom selftest-#megs=1024
# eeprom selftest-#megs
selftest-#megs=1024
Values are kept in the /boot/solaris/bootenv.rc file.

# cat /boot/solaris/bootenv.rc
#
# Copyright 2005 Sun Microsystems, Inc. All rights
reserved.
#
#ident "@(#)bootenv.rc 1.32 05/09/01 SMI"

#
# bootenv.rc -- boot "environment variables"
#
setprop kbd-type 'US-English'
setprop ata-dma-enabled '1'
setprop atapi-cd-dma-enabled '0'
setprop ttyb-rts-dtr-off 'false'
setprop ttyb-ignore-cd 'true'
setprop ttya-rts-dtr-off 'false'
setprop ttya-ignore-cd 'true'
setprop ttyb-mode '9600,8,n,1,-'
setprop ttya-mode '9600,8,n,1,-'
setprop lba-access-ok '1'
setprop prealloc-chunk-size '0x2000'
setprop bootpath '/pci@0,0/pci-
ide@1f,1/ide@0/cmdk@0,0:a'

setprop console 'ttya'

setprop selftest-#megs '1024'
Note – See the eeprom(1M) man page for more information.

Module 6
Introducing the Fundamentals of Package

and Patch Administration
Objectives
The new terminology for patches is updates. Throughout this module the terms are used interchangably.

● Describe how signed packages and patches are implemented
● Implement patch management using the Sun™ Update Connection
Services including the Sun™ Update Manager application, the
smpatch command line, and the Sun Update Connection hosted Web
application
6-1
Objectives
Relevance
Discussion – The following questions are relevant to understanding patch

or update management and package administration:
!
? ● What technology is available for securing the transfer of patches and
packages obtained from Sun?
● What solutions exist for managing many patches and updates for
hundreds of Sun systems?


● Application Packaging Developer’s Guide (Solaris 9 Update 5)
● Adding and Removing Signed Packages (Task Map) in the System
Administration Guide: Basic Administration, PN 817-1985
● Sun Update Connection 1.0 Administration Guide, PN 835-0616
● Sun Update Manager 1.0 Administration Guide, PN 835-0615
● White Paper: Patch Management Solutions for the Solaris 10
Operating System Sun Update Connection, November 2005
The Administration Guides and White Paper are in the /opt/ses/docs directory on each system if the
student bundle for this course was installed.
Introducing the Fundamentals of Package and Patch Administration 6-3

Longer Package Names
Longer Package Names

This feature was introduced in the Solaris 9 9/02 release.
The pkgmk utility was enhanced to create packages with names up to 32

characters in length.
See the pkgmk(1) and pkgadd(1M) man pages.

Signed Packages and Patches

This feature was introduced in the Solaris 9 12/03 release.
In the Solaris 8 release, the patchadd command could be used only for
unsigned patches. Since Solaris 9 12/03 release, it can be used for both
unsigned and signed patches. Implementing signed patches requires that
the keystore is set up properly.
This feature enables you to securely download Solaris packages and

patches that include a digital signature by using the updated pkgadd
and patchadd commands. A package or a patch with a valid digital
signature ensures that the package or patch has not been modified after
the signature was applied to the package or patch. In previous Solaris
releases, you could only add signed patches to your system if you used
the Solaris patch management tools with PatchPro 2.1.
Additional software management features introduced include the

following:
● You can add a digital signature to a package with the updated
pkgtrans command.
Note – For information about creating a signed package consult the

documentation listed in the Additional Resources section at the beginning
of this module.
● You can download a package or patch from an HTTP or an HTTPS

server.
A signed package is identical to an unsigned package except for the

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 add a package or patch with digital signatures to your
system, you must set up a keystore with trusted certificates that are used
to identify that the digital signature on the package or patch is valid.

Note – For information about setting up the package keystore and adding
signed packages or patches to your system, see the Adding and Removing
Signed Packages (Task Map) in the System Administration Guide: Basic
Administration.
Take this opportunity to engage the students by selecting someone to browse to docs.sun.com for additional
information about signed patches and packages. Project the navigation session so all students can watch.
Following is a suggested navigation to the start of the detailed information:
12. At http://docs.sun.com/ search book titles only for Basic

Administration
13. When the search results display, Select the Solaris 10 version of the
book
14. Select Chapter 16 (Managing Software (overview).
15. Select Overview of Software Packages Signed Packages, Patches, and
Updates
16. Navigate from there and discuss areas of interest about the keystore,
the CLI task map, the use of pkgadd or the Application Packaging
Developer’s Guide for information about creating signed packages.

Solaris 10 OS Patch Access Policy
Solaris 10 OS Patch Access Policy

Display a browser for all to see and go to the more complete policy table at:
http://www.sun.com/service/sunconnection/solaris10patches.html
Go over the details of the table, stressing the key points made in the bullet list that follows.
If you are teaching an LVC, select a student to display the table cited above for all to see while you go over
the key points.
Following is a list of key points regarding the new Solaris 10 OS patch

access policy:
● A service plan is not required for security, data integrity or hardware
driver updates. Other patches, including patch clusters, require a
service plan.
● A Sun Online Account is required for any patches obtained using the
Sun Update Connection.
● The Solaris 10 Patch Manager and SunSolve still support anonymous
access but only for security and hardware driver updates. SunSolve
access to other updates requires a service plan and a Sun Online
Account.

Introducing the Sun Update Connection

Much of the information that follows was taken from the very informative white paper: Patch Management
Solutions for the Solaris 10 Operating System Sun Update Connection, November 2005.
The web URLs for the resources listed in the Additional Resources section of this module are:
Sun Update Manager 1.0 Administration Guide:

http://docs.sun.com/app/docs?q=update+manager&s=t
Sun Update Connection 1.0 Administration Guide:

http://docs.sun.com/app/docs?q=update+connection&p=coll%2F1320.2&s=t.
White Paper: Patch Management Solutions for the Solaris 10 Operating System Sun Update Connection,
November 2005:
http://www.sun.com/service/sunupdate/patchmgtsolaris10.pdf
Copies of these resources are also in the /opt/ses/docs directory.
Sun Update Connection is an automated and proactive approach to patch

management needed to deliver the right content to the right systems in a
quicker, less expensive, and more accurate way. Sun Update Connection
makes it easy for you to stay up-to-date and secure with the latest
software updates from Sun. It builds on previous patch management tools
from Sun and provides an easy to use Graphical User Interface (GUI) as
well as a Command Line Interface (CLI). All aspects of patch management
are integrated into a seamless architecture that provides:
● Notifications to let administrators know when new updates become
available for their systems
● Automated procedures that greatly simplify the task of keeping
systems current
● Fast intelligent software dependency checks so that updates are
automatically deployed along with all dependent updates that are
prerequisites
● Optional local caching of updates to help minimize network traffic
and enhance security for the update process
● A Web hosted service that provides a centralized view of connected
systems and enables consistency in applying updates across multiple
systems
Project a browser session for the entire class to view. Go to: http://www.sun.com/service/sunupdate/
and start the 4 minute overview demo of Sun Update Connection linked on that page. This demo will
introduce the students at a high level to this new service. You will need the flash pluggin for your Mozilla
browser. Check that it has been installed and configured when the classroom was installed.

The product referenced as Sun UC Client (SunUC Client) includes the Sun Update Manager GUI, the
smpatch CLI and the patchpro analysis engine.
Administering Patches
A new set of tools and framework for administering patches (now called
software updates) was introduced in the Solaris 10 OS. This set of tools
and framework is collectively called the Sun Update Connection.
The Sun Update Connection tools include the following:

● Sun Update Manager graphical user interface (GUI)
● Sun Update Connection Web application
● Sun Update Manager command-line interface (smpatch)
This new set of tools must be added to a system installed with Solaris 10 FCS but now is all bundled in the
Solaris 10 01/06 (update 1) release.
Sun Update Connection 1.0.x is designed for Solaris 10 systems. Continue

to use Sun Patch Manager 2.0 to perform update-management tasks on
your Solaris 8 and Solaris 9 systems.

Sun Update Connection Modes

The following section provides detail about the two different modes in
which you can interact with Sun Update Connection. Briefly, these modes
are:
● Local management of individual systems using the Sun Update
Manager or the smpatch CLI
● Remote and centralized management of multiple systems using the
Sun Update Connection Web application
Locally Managing Updates for Individual Systems
You can maintain your own updates to the Solaris 10 OS by establishing a

connection to Sun Update Connection and then downloading and
installing the appropriate updates based on the analysis of your system.
Sun Update Connection client software can be installed on the Solaris host
system, enabling access to the Sun Update Connection servers hosted at
Sun. You will then be automatically notified via a Java Desktop
notification icon whenever relevant updates are available. Clicking on the
desktop icon will launch the Sun Update Manager application, a graphical
environment for managing patches on the local system. If you either don't
run a graphical environment on your system or just prefer using
command line tools, the smpatch command provides the same patch
management capabilities using fully scriptable, text oriented commands
to interact with Sun Update Connection. When using the smpatch
command interface, you can also implement your own custom scripts to
manage updates for multiple systems using Sun Update Connection
technology.

Figure Figure 6-1 shows that this local update approach enables each
system to interact with Sun Update Connection independently of other
systems. Multiple systems can simultaneously interact with Sun Update
Connection.
Customer Business Applications
and Infrastructure
Customer
Firewall Sun Update Manager Client
or smpatch CLI
System A
Sun
Update Sun Update Manager Client
Connection or smpatch CLI
System B
Sun Update Manager Client

or smpatch CLI
System C
Figure 6-1 Sun Update Manager or the smpatch CLI
Sun Update Manager
Sun Update Manager is a successor to the Solaris Patch Manager

application which was first introduced for the Solaris 8 OS and is now
integrated into the Solaris 10 OS distribution. It incorporates an updated
version of the PatchPro analysis engine and a new user interface that
enables users to perform the following primary tasks with point and click
menus to:
● Analyze system to check for available updates
● View a list of updates currently available and applicable for the
system
● View details about a specific update
● Install selected updates

As Figure 6-2 shows, the Sun Update Manager will present a list of all
current patches available from Sun that are applicable to that particular
Solaris 10 system. The Available Updates tab provides important
information about each patch including patch id, a synopsis, the patch
release date, download size, and notice of any special handling
requirements. The Installed Updates tab shows what updates have been
installed.
Use the following command to start the Sun Update Manager:

# /usr/bin/updatemanager
Note – You can also start the Sun Update Manager by clicking the desktop
notification icon on your Java Desktop.
Not shown here is the process for obtaining a Sun Online Account and the procedure for registering the
system. These steps would need to be done first, and the Check for Updates button clicked, before you would
see the updates listed as in Figure 6-2. These details for registering a system will be presented later in the
module.
Figure 6-2 Sun Update Manager Showing Available Updates

When you elect to install updates, you are asked to approve any
dependencies so that all required patches are installed together in the
proper order. After dependencies are approved, all updates except those
which require special handling are automatically applied in real time. For
updates that require a system restart, or which must be applied while the
system is in single user mode, installation is deferred until the system is
restarted by the user.
These deferred updates are then automatically applied during the next
system restart.
Sun Update Manager also includes a complete history of updates installed

on the system and provides an efficient method for uninstalling updates
should that be necessary.
smpatch Command Line Interface
The smpatch command line interface (CLI) for Sun Update Connection is
built into the Solaris 10 OS and is an updated version of the smpatch CLI
that has been available in earlier distributions of the Solaris OS. If you are
familiar with the Solaris smpatch command you can immediately be
productive using Sun Update Connection. (Note however, that the Solaris
10 OS must be registered with the Sun Update Connection before the
smpatch command will be allowed to connect.)
Registration of systems can be accomplished using the Sun Update

Manager or by using the sconadm command line registration utility.
Note – See the sconadm(1M) man page for details.
The smpatch CLI provides much the same functionality as the Sun
Update Manager GUI including the ability to:
● Analyze and produce a list of recommended patches for a system
using the smpatch update command
● Download one or more patches to a system using the
smpatch download command
Before the 1.0.4 release, this smpatch command would download only the most current revision of the patch.
Starting with the 1.0.4 release, is is possible to download any revision, even back or obsolete revisions.
● Add one or more patches to a system using smpatch add command

● Back out unwanted patches using smpatch remove command

Commands from the smpatch CLI can also be embedded in shell scripts
that address multiple different system in order to increase efficiency by
executing a series of system updates in serial fashion.
Note – Good update management practices dictate that you should not
attempt to use both Sun Update Manager GUI and the smpatch CLI at the
same time. While it is safe to use both interfaces at different times, using
them together can result in synchronization issues wherein data for Sun
Update Manager data can become stale. If this situation does occur, it is
necessary to restart the Sun Update Manager application.
Caching Patches With Sun Update Connection Proxy

Using a proxy is a variation of the first mode being discussed now. It is not the second mode.
If you do not want to connect your systems directly to Sun Update

Connection over the Internet, Sun Update Connection offers a local proxy
server that can be installed and configured within the your secure
environment. Sun Update Connection Proxy acts as a gateway between
locally managed systems and the Sun Update Connection. All network
traffic between Sun Update Connection and internal systems then passes
through the Sun Update Connection Proxy to help protect internal
systems from outside security threats and to aggregate requests from
clients to the Sun Update Connection. This approach can dramatically
reduce the amount of data traffic between the customer site and the Sun
Update Connection.

Figure 6-3 shows a Sun Update Connection proxy in use.

and Infrastructure
Customer
Firewall Sun Update Manager Client
or smpatch CLI
System A
Sun
Sun Update Sun Update Manager Client
Update
Connection or smpatch CLI
Connection
Proxy
System B
Sun Update Manager Client

or smpatch CLI
System C
Figure 6-3 Sun Update Connection Proxy
The Sun Update Connection Proxy is a caching proxy server that acts as
an intermediary between Sun Update Connection client systems and the
Sun Update Connection servers. Client systems can be configured to use
the Proxy as their patch source so that all of their requests for patches and
patch metadata are directed to the Sun Update Connection Proxy. If the
proxy can satisfy a request from data stored in its local cache, it does so. If
it doesn't have the requested patch in its cache, it retrieves the requested
patch, stores it in its cache for future references, and then responds to the
original client request. Once a patch or the current patch metadata is
present in the proxy cache, this data can be accessed by many local clients.
This not only helps to reduce outside network traffic, but can also help
reduce the average time required to apply patches.
The Sun Update Connection Proxy software itself is available as a Solaris

10 patch and can be downloaded from Sun Update Connection or from
SunSolve. After installing the Sun Update Connection Proxy, Sun Update
Manager can be redirected to look for updates on the proxy server rather
than looking to Sun Update Connection as the source for updates.

When using Sun Update Connection Proxy, Sun Update Manager

operates the same way that was discussed earlier except that it now uses
a different location as the source for retrieving patches, metadata, and
analysis modules. The metadata stored on the Sun Update Connection
Proxy is synchronized with Sun Update Connection so that host systems
are always accessing an up-to-date copy of the metadata. This metadata is
transferred to local systems whenever Sun Update Manager is used to
perform an analysis on the host system.
Mode 2 - Managing Remotely with Sun Update Connection

Hosted Web Application
If you need to manage software updates across several systems in a

workgroup environment, the Sun Update Connection offers a Sun-hosted
web-based update management service. The Hosted Web application
enables a system administrator to remotely manage updates for a number
of systems under his or her control. You can register one or more of your
Solaris 10 systems with this hosted service, and then simply point your
Web browser to http://updates.sun.com/ to manage patches for all
registered systems.

Figure 6-4 shows placement and use of the Hosted Web application.

and Infrastructure
Customer
Firewall
Sun
Update
Connection
Web Browser
IT Manager/Sysadmin
Hosted Web
Application
System A
System B
System C
Figure 6-4 The Sun Update Connection Web Hosted Application
The Sun Update Connection Hosted Web application includes all the
features of Sun Update Manager plus the ability to manage many systems
using commands that address multiple systems in a single operation. The
same client software that powers the Sun Update Manager and the
smpatch command is also at the core of this hosted service. The Sun
Update Connection Hosted web application is available to all Solaris 10
systems covered under a service plan.
What is covered by a service plan and what is available without a plan is discussed later in the module. It is
a bit involved to cover here in this overview section.

The hosted web application provides greater efficiency by allowing you to

view update status across many systems and apply updates to multiple
machines with a single command. Rather than analyzing and updating
each system individually, you can simply select several systems as targets
for the same update. This not only saves time, but also can simplify
change management by helping to maintain consistent OS and patch
levels across a group of related systems.
The hosted web application monitors and evaluates all registered systems
for necessary updates. It performs the analysis work in the background so
that you can focus on other tasks. When it’s time to take action, you can
then use the Web-based portal to apply specific updates, or to review
detailed information about the available updates, pending tasks, or the
update history for specific systems.
The Sun Update Connection hosted web application also allows you to
manage with a system-centric view or a patch-centric view. In the system-
centric view, you can drill down to see which updates are needed for a
specific system. In the patch-centric view, you can select a patch and see
which of the systems being managed have a need for that particular
patch. Then, with a single click, the patch can be deployed to all affected
systems.
Use the following URL in a browser to connect with the Sun Update
Manager Host Web application:
http://updates.sun.com/

Figure 6-5 shows an example screen of the hosted web application.
Figure 6-5 Sun Update Connection Hosted Web Application

Using Sun Update Manager

This section presents a simple tour of using the Sun Update Manager. If your environment permits you may
choose to do a live demonstration of the tool on your own. If you decide to do this, be sure to cover the same
points that this paper tour discusses.
If you are teaching an LVC, you may want to engage a student by selecting one to drive the demo with your
direction.
This section presents a simple tour through some of the screens and tasks
you perform using the Sun Update Manager.
Establishing a Sun Online Account

A Sun Online Account is required for using the Sun Update Connection
services regardless of the mode of connection you choose.
There is no charge for establishing such an account. Start at:

http://www.sun.com/
and click on the My Sun link. From there you can create a new account.
Note – You might already have a Sun Online Account if you registered for
an account with programs such as Java Developer Connection, Online
Support Center (OSC), MySun, SunSolve, or SunStore.
Obtain a Sun Service Plan (Optional)

A Sun Service Plan is optional. Without one you will get security and
hardware driver updates only. If you want all the other updates available
contact your Sun Service Representative and subscribe to an appropriate
service plan. Obtain a subscription key associated with that plan for use
later when you install and register systems for Sun Update Connection
functionality.

Downloading and Installing the Sun Update

Connection Client Software
If you are running a version of the Solaris OS that precedes the Solaris 10
1/06 release, you will most likely need to download and install the Sun
Update Connection client software. Beginning with the Solaris 10 1/06
Release, the Sun Update Connection client software will be an integral
component of the Solaris distribution and will not need to be installed
separately.
For a system installed with the Solaris 10 OS, the Sun Update Connection
client (1.0.4) software for SPARC systems can be downloaded and
installed as follows:
# smpatch update -i 121118-05
Use the following command for x86 based systems:

Remind students that these patch numbers will change for clients later than 1.0.4 and that any patches that
these depend on will also be applied.
Alternatively, you can get the client from:

● The Sun Download Center - The Sun Update Connection client
software distribution comes bundled with an installer program that
can then be used to the install the client software.
● SunSolve as a patch.
Starting Sun Update Manager For the First Time

Once the Sun Update Manager client is installed on the system to be
managed, click on the Java Desktop notification icon or use the following
command to start it:

After a few moments, while the client loads system information, the
Registration Wizard’s welcome screen displays as shown in Figure 6-6.
Figure 6-6 Sun Update Manager’s Welcome
Registering Systems
Only systems that have been registered with Sun Update Manager can be
managed remotely by the Sun Update Connection services.

After you click the Register to Manage Updates button you will see the
first screen which is shown in Figure 6-7.
Figure 6-7 Sun Update Manager’s Step 1 of 3 Screen
From this Step 1 screen you can do any of the following tasks:
● Configure the system to retrieve updates from a local source.
This option is used to connect this system to a Sun Update
Connection proxy as shown in Figure 6-3. You should have that
proxy server installed and configured before exercising this option
for a connection.
● Configure network proxy settings
If you are connecting this system directly to the Sun Update
Connection servers without using an in-house proxy, you may need
to configure this Sun Update Manager client to use a proxy to access
the Internet.

Explain that this proxy setting is different than the one discussed in the prior bullet. This one is more
analogous to how you set a proxy in a browser. The Sun Update Connection Manager has the same
requirement as a browser accessing the Internet through a company firewall, for example.
● Create a Sun Online Account

If you have already done so, this option can be done to connect to
Sun for setting up this free account.
Assuming you have already established a Sun Online Account, fill in the
username and password and click Next. The screen show in Figure 6-8
will display.
Figure 6-8 Sun Update Manager’s Step 2 of 3

Entering a Sun Subscription Key
On the Registration Wizard’s screen 2 of 3 you either enter your Sun

Subscription Key or, chose to procede without one. You can also purchase
one from this screen or do this later. After reading and accepting the
service level agreement, click Next. The screen shown in Figure 6-9 will
display.
Figure 6-9 Sun Update Manager’s Step 3 of 3
This step 3 of 3 screen is where you register your local system. Its name is
filled in by default. (You can also override this filled in value to register an
alias name for your system; Sun Update Connection Services will then
know your system by that alias.) If you click the links for either of the
demonstrations your browser will be sent to the main Sun Microsystems
web site for animations.

Select the option to manage your local system using remote Sun Update
Connection services and click the Finish button. The screen shown in
Figure 6-10 might display.
Figure 6-10 Sun Update Manager Showing Internet Connection Failure
Configure a Network Proxy
This failure message displays in this case because when the Sun Update
Manager client attempted to send system information out to the Internet
to the Sun Update Connection services web site, it didn’t have the
necessary proxy information to pass through a corporate firewall. You can
click the link to configure a proxy or decide that you will use the services
of an internal installed Sun Update Connection Proxy and therefore not
need a proxy setting for the Sun Update Manager client.

For this example, we will need to configure a proxy for the local Sun
Update Manager client to use for access to the Internet. After that link is
clicked, the screeen shown in Figure 6-11 displays.
Figure 6-11 Sun Update Manager - Configuring a Network Proxy
Place a checkmark at Enable Network Proxy, fill in the proxy hostname or

IP address and the port. If proxy authentication is needed, fill in that
information and then click OK. You will be returned to the previous
screen 3 of 3 (Figure 6-9). Again, click the Finish button.

After a storing system information progress bar finishes, you will see the
screen shown in Figure 6-12.
Figure 6-12 Sun Update Manager - Registration Complete
After registration of your local system completes you can either close the
window and start management of your system using the Sun Update
Manager or use the link to launch Sun Update Services which would
launch a browser and direct you to the Sun Update Connection Hosted
Web application for management of all your registered systems.

In this example scenario you close the registration complete window and
use the Sun Update Manager client application for update management.
That interface looks like that shown in Figure 6-13.
Figure 6-13 Sun Update Manager Showing Available Updates
This is the main window from which you manage updates for your local
system. You can use this GUI to perform the following tasks:
● Analyze your system
● Apply updates you select
● Remove updates
● Configure your update management environment

Installing Updates With the Sun Update Manager

Updates for the registered system on which the Sun Update Manager is
launched will appear on the Available Updates tab and is shown in
Figure 6-14.
Figure 6-14 Sun Update Manager’s Available Updates Listing
You can always use the Check for Updates button to check for available
updates at anytime. If you are using the Java Desktop environment, an
icon will alert you when new updates are available.
When you single click an update entry the bottom panel displays typical
information about that update including ID, size, patches obsoleted or in
conflict with the update, a list of files in the update, the bugs addressed,
the x86 version patch number, and so on.
Entries marked with the Download Only icon will not automatically
install after you click the Install Item Now Button. For such updates you
need to read the update’s readme file for instructions required for a
manual installation.
Updates marked with the Restart Required icon will also not install after
pressing the Install Item button. They will download but will be installed
only on the next system restart. Updates in this state (after download but
before install) will appear in the Updates Available tab of the Sun Update
Manager with a dash (-) in the first column.

After you click checkmarks next to the updates of interest, click the Install
Item Now to download and install. An analysis of your system will be
performed, the update(s) downloaded and, those able to be installed will
be installed. If an update has dependencies on other updates, they also
will be downloaded and installed. A notice will display with the status of
the operation when it completes.
The screen in Figure 6-15 shows the Installed Updates tab of the Sun
Update Manager.
Figure 6-15 Sun Update Manager - Installed Updates
From this screen you can select an updates that you want to uninstall.
Once you do so, the Uninstall Selected Update button becomes available
for use.

Setting Sun Update Manager Client Preferences
Setting Sun Update Manager Client Preferences

A Preferences submenu is available from the File menu. The following
preferences and configurations can be accomplished in these Preferences
dialogues:
● Update the source of your updates (either from a Sun Source or from
a local source, like a CD or a local Sun Update Manager Proxy you
have established).
● The Sun Update Manager Client’s network proxy hostname, IP
address and authentication details.
● Directory where updates will be downloaded. (Default is
/var/sadm/spool.)
● Backout data directory setting (used during update backouts).
● Enabling the new update available notification icon for your Java
Desktop. (Not available for CDE.)
● Enabling daily automatic update analysis (as a background task).
This is recommended.
From the file menu you can also purchase a subscription and receive a
Subscription Key for access to, and management of, patches beyond
security and hardware driver updates. (You use your Sun Online Account
credentials to do this.)
From the file menu you can also launch a browser for update
management using the Sun Update Connection web application.
So far we have been managing updates to a local system using a locally installed Sun Update Manager
client. The next section looks at setting up a Sun Update Manager Proxy for more efficient management of a
number of systems.

Sun Update Connection Proxy

The Sun Update Connection Proxy was previously called local patch server.
By using a Sun Update Connection Proxy on your intranet, you can serve
updates to your local systems and minimize the Internet traffic between
your systems and the Sun update server. This type of proxy caches any
updates that are downloaded from its update source.
The Sun Update Connection Proxy obtains updates from its source of
updates on a per-request basis. You do not need to stock your proxy with
updates before you use it.
This proxy supports client systems that use the Sun Update Connection
1.0 software and the Sun Patch Manager 2.0 software.
Note – The system that you choose to act as the Sun Update Connection
Proxy must be running at least Solaris 10 and have at least the Developer
Solaris Software Group installed. This system must also have the Sun
Update Manager 1.0 software installed.
Registration
If you locally manage a system that is a client of a Sun Update Connection
Proxy on your intranet, you do not need to register the client system. You
must register the system that acts as the proxy. If, however, your client
system is also remotely managed directly by the Sun Update Connection
services (in the context of the web application or its own local Sun Update
Manager client software, for example), the client system must be
registered.
Obtaining, Installing and Initially Configuring the Sun

Update Connection Proxy
The Sun Update Connection Proxy is an optional feature that you can
obtain at no charge if you have a Sun Service Plan. For information about
obtaining a Sun Service Plan, go to Solaris Operating System Software
Support at http://www.sun.com/service/support/software/solaris/ and
select the appropriate level of service.

If you already have a service plan and the Sun Update Manager client
installed, you can use this manager to obtain and install the update which
is the Sun Update Connection Proxy.
Use the following command to verify that required packages are on your
system:
# pkginfo | grep SUNWpsvr
system SUNWpsvrr Patch Server Deployment (Root)
system SUNWpsvru Patch Server Deployment (Usr)
If these packages are not installed, add them before continuing.
Setting a Network Proxy (Optional)
Set the network proxy for the Sun Update Connection Proxy by typing the
following command with your specific network proxy and port
information:
# patchsvr setup -x network_proxy:port
Setting a Source of Updates
By default the update source for the Sun Update Connection Proxy is the
Sun update server. You can change it to another source if your update
strategy requires it. For example, you can implement a chain of proxies,
each one using another earlier in the chain as its source.
To specify the next update server in a chain of Sun Update Connection

Proxies, type the following command, specifying the server name and
port (3816) of the upstream proxy:
# patchsvr setup -p http://server-name:port/solaris/
To specify the Sun update server, which is the default, type the following
command:
# patchsvr setup -p https://getupdates.sun.com/solaris/
Remind students that in an implementation of chained proxies, only the most upstream one typically needs to
have its network proxy configured since it is the only one that would need access to the Internet to reach the
Sun update server.

Starting the Proxy Service
The following command will start the proxy server:

# patchsvr start
The following command will configure the proxy server to start on

subsequent system boots:
# patchsvr enable

Configuring Clients to Use the Sun Update Connection Proxy
Configuring Clients to Use the Sun Update Connection

Proxy
Client systems that connect to a Sun Update Connection Proxy run the
Sun Update Manager client software configured to receive updates from
the proxy. Client systems only need to be registered with the Sun Update
Connection Services if they will also be managed by those services using
the Sun Update Connection web applications or a locally installed Sun
Update Manager client. If they will only be managed locally, using the
updates stored on the proxy, they do not need to be registered.
Refer students to Figure 6-3 and Figure 6-4 to help explain this.
This will be the case for the short scenario which follows. The assumption is that the Sun Update Connection
Proxy has already be setup up, registered and configured to reach the Sun update server (via a network
proxy setting) on another system and it already has retrieve a store of update information. Provide this
context for the students.
Install and start the Sun Update Manager on the client by typing the
following command:
When the Registration Wizard Welcome screen displays, click the Apply
Updates Manually button (Figure 6-6).
On the Apply Updates Manually screen, click the link labelled, Set up the
Sun Update Manager Service. The Registration Wizard screen 1 of 3 will
display (Figure 6-7).

Configuring Clients to Use the Sun Update Connection Proxy
On the Registration Wizard screen 1 of 3, click the link labelled,

“Configure the system to retrieve updates from a local source.” The screen
shown in Figure 6-16 will display prompting you for the URL of that
update source.
Figure 6-16 Sun Update Manager - Use a Local Source for Updates
Supply a URL like the following using your specific proxy host name:
http://proxy-hostname:3816/solaris/
Tell students that they just supply the proxy-hostname. The port number and solaris directory name
shown should be used.
Click the Finish button at the bottom of the screen. The Sun Update
Manager will then automatically analyze the client system, contact the
proxy, and retrieve a list of the available updates appropriate for the
client. Management of the client can begin at that point.
No different than what was discussed earlier in the module.

Patch Admininstration From the Command Line (CLI)

The new terminology for patches is updates. Throughout this module the terms are used interchangably.
Note – Do not use the Sun Update Manager GUI, the smpatch command,
and the patchadd command simultaneously to manage updates on your
system. While the Update Manager GUI is running, changes made by
smpatch and patchadd might not be reflected correctly in Update
Manager.
It is possible to use one tool for some tasks, finish with that tool, and then startup another to do other tasks.
It is the simultaneous use and latency in each tool’s updated knowledge of system state that can be
problematic.
An update (previously known as a patch) contains a collection of files and

directories. This collection replaces existing files and directories that
prevent proper execution of the software. Some updates contain product
enhancements.
A Solaris OS update types include:

● Standard updates – Updates that fix specific problems with the
Solaris OS and other Sun hardware and software products.
● Recommended patches – Solaris OS updates that fix problems that
might occur on a large percentage of systems.
● Update clusters – A group of standard, recommended, or security
updates that have been bundled into a single archive for easy
downloading and installation.
Note – In previous versions of the Solaris OS, maintenance updates were

also available. These were sets of patches that had been tested together
and packaged for one-step installation. Maintenance updates were
available to service contract customers. Maintainance updates are now
replaced by the Solaris OS distributions of the Solaris Express Program.
Such updates to the Solaris OS are free for download and are available on
a monthly schedule. See the following URL for details about the Solaris
Express program:
http://www.sun.com/software/solaris/solaris-express/

An update is distributed as a directory that is identified by a unique

number. The number assigned to an update includes the update base code
first, a hyphen, and a number that represents the update revision number.
For example, an update directory named 105050-01, indicates that
105050 is the base code and 01 is the revision number.
Prior to the Solaris 9 OS updates were in zip format, for example,

105050-01.zip. Now they are in jar format, for example, 105050-
01.jar.
Note – Not all updates available from Sun Microsystems must be

installed. Only install the recommended updates, security updates, and
those required to fix problems specific to your site.

Using the smpatch Command

The smpatch command (and its subcommands) are the preferred
commands to use now for update/patch management using the CLI.
Other older commands, like patchadd, still work (and is actually called by smpatch) but have students get
into the habit of using the smpatch command.
Starting with the Solaris 9 OS, the smpatch command was available in
two modes - local mode and remote mode:
● Local mode can only be run on the local system.
This mode can be run while the system is in single-user or multiuser
mode.
● Remote mode can be used to perform tasks on remote systems.
Typically the -n system_name option is added to smpatch
commands to run them on remote systems
By default, smpatch runs in local mode. In local mode none of the

authentication options or options that refer to remote systems are
available. In Solaris 8 only local mode smpatch is available.
If you specify any of the remote or authentication options (except for -L),
remote mode is used.
Tell students that the remote mode, while supported in S9 and the original S10 Patch Manager is not
supported with Sun Update Connection services. The S9 and original S10 version of Patch Manager
optionally operated in remote mode using the CIM/WBEM service but the Update Connection client does not
support this mode of operation. They should use local mode only moving forward.
Phases for Applying Updates

The full sequence for applying an update involves these phases or steps:
1. analyzing your system
2. downloading the necesssary updates
3. applying the updates
You can exercise as much control of the phases as need:

● The smpatch update command will perform all three functions
using one command.

This command requires multiuser mode and will not apply an

update that has the interactive property set. The application of
updates will be governed by the update policy.
Properties and update policy will be discussed later.
● The smpatch analyze and smpatch update commands will

perform all three fuctions using two commands.
If you want to first analyze your system and then download and
apply them in a single subsequent step, first use the
smpatch analyze command followed by the smpatch update
command.
The smpatch analyze command requires multiuser mode.
The smpatch update command will also download any prerequisite
patches.
● The smpatch analyze, smpatch download, and smpatch add
commands will perform all three fuctions using three commands.
If you want to analyze your system, download the updates and add
them to your system in three separate steps, first use the
smpatch analyze command followed by the smpatch download
command followed by the smpatch add command.
The smpatch add command can be used in single user mode or
multiuser mode. The smpatch add command will not consult the
update policy.
Example Commands
Applying an Update In Three Steps
Using the three commands allows greater control and flexibility when
applying a patch.
1. Assume that you want to have the latest update(s) for the devfsadm
command. The following command will analyze your local system
and determine the appropriate, available updates for it. (It will not
download or apply them.) The command will write the list to the file
plist. You can then look in the plist file for updates involving
devfsadm.
# smpatch analyze > plist
# vi plist
120199-04 SunOS 5.10: sysidtool Patch
119252-09 SunOS 5.10: System Administration Applications Patch

...
119984-03 SunOS 5.10: devfsadm patch
119685-05 SunOS 5.10: svc.startd patch
119681-06 SunOS 5.10: wanboot patch
121268-01 SunOS 5.10: tmpfs patch
...

The patchadd -p command shows what updates have been applied to

the system. Use it to verify that the devfsadm update you found in the
plist file isn’t already on the system:
# patchadd -p | grep 119984
Patch: 119984-01 Obsoletes: Requires: Incompatibles: Packages: SUNWcsu
There is an ealier version of this update on the system but not the newly
available -03 version.
Note – You can still use the showrev -p command to accomplish the
same thing and it executes more quickly.
2. The following command will download (but not apply) the new
update for the devfsadm command:
# smpatch download -i 119984-03
com.sun.patchpro.util.Percentage@57ae58
119984-03 has been validated.
The update has been downloaded to the downloaded area and validated.
By default, this directory is /var/sadm/spool. If it had been changed
from the default, you could query the system with the smpatch get
command to learn the new value. The following example shows that the
default is still in effect.
# smpatch get | grep download
patchpro.download.directory - /var/sadm/spool
The will a more complete treatment of properties later in the module. Just point out that if the default location
had been changed, it would have appeared in the second column of the output shown above where a hyphen
now appears.
The following commands show the update has been downloaded as the
*.jar file:
# cd /var/sadm/spool ; ls
119984-03.jar
...
Remind students that if this update had an prerequisite updates, they also would have been downloaded.
3. Apply or install this update using the following smpatch add

command:
# smpatch add -i 119984-03
add patch 119984-03
Validating patches...

Loading patches installed on the system...

Done!
Loading patches requested to install.
Done!
Checking patches that you specified for installation.
Done!
Approved patches will be installed in this order:
119984-03
Patch 119984-03 has been successfully installed.
Remind the students that smpatch add behaves differently than the smpatch update command. The former
does not consult the update policy This will be examined more thoroughly later in the module.
Verify that the patch is installed on your system using this command:
# patchadd -p | grep 119984-03
Patch: 119984-03 Obsoletes: Requires: Incompatibles: Packages: SUNWcsu
A subsequent analysis of this system will no longer show this update as

appropriate:
# smpatch analyze | grep 119984-03
#
An update is easily removed (backed out). The following command does

this for the update just applied:
# smpatch remove -i 119984-03
remove patch 119984-03
Transition old-style patching.
Patch 119984-03 has been backed out.
Tell students that after the installation and after the remove the patch itself remains in the spool area.
An analysis now shows that this update is once again appropriate and
available for this system:
119984-03 SunOS 5.10: devfsadm patch
Applying an Update In One Step
Use the smpatch update to analyze your system, download and apply
the update in one step. For example this FMA (Fault Management
Architecture) recommended update can be applied to the system with this
command:


com.sun.patchpro.util.Percentage@775121
Installing patches from /var/sadm/spool...
119578-15 has been applied.
/var/sadm/spool/patchpro_dnld_2006.02.14@13:48:56:MST.txt has been moved to
/var/sadm/spool/patchproSequester/patchpro_dnld_2006.02.14@13:48:56:MST.txt

Configuring the Patch Management Environment

The smpatch get, smpatch set and smpatch unset commands are
used to configure the patch management environment:
● smpatch get displays the current settings for environment
parameters
● smpatch set changes values for environment parameters. The new
values are not validated in anyway so verify the intended changes.
● smpatch unset enables the default values for environment
parameters
Use the following command to display the current environment

parameter values:
# smpatch get
patchpro.backout.directory - ""
patchpro.install.types - rebootafter:reconfigafter:standard
patchpro.patch.source http://192.168.201.1:3816/solaris/ https://getupdates.sun.com/solaris/
patchpro.patchset - current
patchpro.proxy.host - ""
patchpro.proxy.passwd **** ****
patchpro.proxy.port - 8080
patchpro.proxy.user - ""
Note – The smpatch(1M) man page contains a detailed description of the

environment parameters.
Explain that the first column is the environment parameter or property, the second column contains values
changed by the smpatch set command and the third column is the default value for that parameter. In the
above output the patchpro.patch.source parameter has been changed from its default of
https://getupdates.sun.com/solaris/. On this particular system (and earlier in the module), the Sun
Update Manager was used to set this value to a Sun Update Manager Proxy.)
Display a system for all students to see and display the smpatch man page for a description of the
environment parameters.
If you are teaching an LVC, engage a student to do this same thing as you discuss the parameters.
The following smpatch set and get commands will set a new value for
the update source. (This is typically what you would do to direct your
local client to a new update proxy server.)
# smpatch set patchpro.patch.source=http://newproxy.apex.com:3816/solaris/
# smpatch get

patchpro.patch.source http://newproxy.apex.com:3816/solaris/ https://getupdates.sun.com/solaris/
You can also set the source of updates to a local or remote directory as the
following examples illustrate:
# smpatch set patchpro.patch.source=file:/net/sys-04/export/updates
# smpatch set patchpro.patch.source=file:/local/updates
# smpatch set patchpro.patch.source=file:/cdrom/cdrom0
The following command sets the patchpro.patch.source parameter

back to the default value:
# smpatch unset patchpro.patch.source
# smpatch get
patchpro.patch.source - https://getupdates.sun.com/solaris/
You can configure an update set which defines a subset of updates that
commands will work with. For example, the following commands will
result in an analysis only on recommended updates:
# smpatch set patchpro.patchset=recommended
# smpatch analyze
Using the Update Policy for Applying Updates

The patchpro.install.types property defines the update policy in
effect for the update management environment.
When you apply patches using the smpatch update command the
update policy is consulted before an update is actually applied.

The following are the types of updates that are applied to the system:
● Standard updates that are applied immediately and require no
system restart
● Updates that require a system restart
● Updates that must be manually applied
If you use the smpatch update command to update your system, you get
the benefit of the guidelines established by update/patch developers in
how best to apply the update. However, you can customize the policy for
applying updates using the patchpro.install.types parameter.
Be sure students understand the ramifications and responsibilities associated with customizing the default
policy.
Table 6-1 shows the correspondence between the

patchpro.install.types parameter values and the Sun Update
Manager icons shown on the Available Updates tab in the GUI. It also
describes the value and if it is part of the default update policy.
Table 6-1 Install Type Parameter Values and Sun Update Manager GUI Icons
patchpro. Sun
install. Update
Description
types Manager
value GUI Icon
standard Standard A default. Can be applied in multiuser mode and

visible immediately unless the application being
updated is running while the update is applied. In
this case, the effects of the update are visible after the
affected application is restarted.
rebootafter Restart A default. Effects not visible until system reboot.
Required
reconfigafter Restart A default. Effects not visible until a reconfiguration
Required reboot (boot -r). See the boot(1M) man page.
rebootimmediate Restart System becomes unstable (unpredictable behavior or
Required possible data loss) until system reboot.
reconfigimmediate Restart System becomes unstable (unpredictable behavior or
Required possible data loss) until system reconfiguration reboot
(boot -r).

Table 6-1 Install Type Parameter Values and Sun Update Manager GUI Icons
patchpro. Sun
install. Update
Description
types Manager
value GUI Icon
singleuser Restart Do not apply this update in multiuser mode. You
Required must apply this update on a quiet system with no
network traffic and with extremely restricted I/O
activity.
interactive Download Only downloaded to your system and must be
Only applied manually according to the instructions in the
update’s README file.

The default value for this parameter is shown with this smpatch get
command:
# smpatch get patchpro.install.types
Per Update Policy Value
Each update has properties associated with it. The PATCH_PROPERTIES

values are the install types for the update. You can learn these values with
the following command sequence if the update is downloaded in the
spool area of your system:
# cd /var/sadm/spool
# jar xvf 119578-15.jar 119578-15/patchinfo
inflated: 119578-15/patchinfo
# cat 119578-15/patchinfo
PATCHINFOVERSION="1.0"
PATCHID=119578-15
PATCH_CORRECTS='BaseOS.SolarisCore-5.10 BaseOS.SolarisFaultMgmt-5.10'
PATCH_ARCH='sparc'
PATCH_OS='SunOS'
PATCH_OSRELEASE='5.10'
PATCH_PROPERTIES='rebootafter clientroot clientusr'
PATCH_OBSOLETES="119330-01 119331-01 119559-01 119576-01 120635-02"
Remind students that the above example was for the FMA patch applied with the smpatch update command
earlier in the module. The update policy permitted this update to be applied at that time. Will the effects of
this update be visible immediately?
The patchinfo file is included in the collection of files in an update. It

contains more metadata than just the PATCH_PROPERTIES value.
Example of Using the Update Policy

It is good practice to always use the Update Policy when adding patches,
otherwise you might miss an important patch property such as immediate
reboot or a prerequisite patch.
Explain to the students that before using the smpatch update command, which consults the update policy,
the smpatch add command will be used to see the potential danger of not consulting the policy.

Not Using the smpatch update command
Analyze your system and learn if any updates involving wanboot are
appropriate and available:
# smpatch analyze | grep wanboot
Determine if any prior versions of the wanboot update are already on the
system:
Patch: 119681-05 Obsoletes: Requires: Incompatibles: Packages: SUNWcakr
Only the earlier 05 version of this update is already installed.
Download, but do not apply, the newer wanboot update:

# smpatch download -i 119681-06
Apply the patch using the smpatch add command:

add patch 119681-06
...
Done!
Done!
Done!
119681-06
Be sure to point out that this update has been applied.
Verify that the patch is installed on your system:

Yes, it has been installed.

A subsequent analysis of this system will no longer show this update as

appropriate:
#
Makes sense. It is no longer listed as available/appropriate since it is already installed on the system.
Especially when you use the smpatch add command it is always a good
practice to read information about the update. Go to the download spool
area and see what information there is about this update:
# cd /var/sadm/spool ; ls
119681-06.jar
cache
patchpro_dnld_2006.02.13@10:10:29:MST.txt
# cat *.txt
This patch bundle was generated by PatchPro.
Please refer to the README file within each patch for installation
instructions. To properly patch your system, the following patches
should be installed in the listed order:
1) 119681-06 !!! IMMEDIATE REBOOT !!!
The *.txt and other readme files often contain important information. In
this case the warning to immediately reboot implies that the
PATCH_PROPERTIES value for install type is either reconfigimmediate
or rebootimmediate.
When a requested patch has prerequisite patches, the order for applying them is also in this file.
The following commmand sequence will display the install type value for
this update:
# jar xvf 119681-06.jar 119681-06/patchinfo
inflated: 119681-06/patchinfo
# grep PROP 119681-06/patchinfo
PATCH_PROPERTIES='reconfigimmediate clientroot'
Impress upon the students that using the smpatch add command implies the responsibility of reading the
information that is included with the update.
A reconfiguration reboot (boot -r) should be done on this system to

render it stable again.

Note – The /var/adm/messages file identifies problems that are found

when applying a patch to a system.
Using the smpatch update Command
The smpatch update command will analyze your system, download the
update and apply it in one step. It also provides safeguards that are not
available with smpatch add because it consults the update policy.
The smpatch update command also is knowledgable about update

dependencies and applies any dependencies for the updates you specify.
com.sun.patchpro.util.Percentage@96ad7c
Installing patches from /var/sadm/spool...
NOTICE: Patch 119681-06 cannot be installed until the next system shutdown.
ID's of the updates that are disallowed by installation policy have been
written to file
/var/sadm/spool/disallowed_patch_list
One or more updates that you installed requires a system shutdown to activate it. To
initiate the system shutdown, you must use one of the following commands:
o Power down the system - init 0 or shutdown -i 0
o Drop to the firmware prompt - init 5 or shutdown -i 5
o Restart the system - init 6 or shutdown -i 6
Recall that smpatch add command informs you about the required reboot
in the *.txt in the download spool area. smpatch update, on the other
hand, displayed this to standard out, creates a disallowed_patch_list
and gave instructions about the reboot.
# cat /var/sadm/spool/disallowed_patch_list
119681-06
Part of the smpatch update command applies the updates. Updates that
cannot be applied for some reason are listed in the
disallowed_patch_list. Typically you attend to updates listed in this
file manually.

Verify that the only version of this update installed on the system is the
prior version (05):
A subsequent analysis of the system still shows that this patch is available
and still appropriate for this system. It is in the spooled area awaiting
installation and a system reboot.
Manually add the patch:

Done!
Architecture for package SUNWcakr from directory SUNWcakr.v in patch
119681-06 differs from the package installed on the system.
Architecture for package SUNWcakr from directory SUNWcakr.us in patch
119681-06 differs from the package installed on the system.
Done!
Done!
119681-06
Verify that it is installed:

Analyze the system to show that it is no longer appropriate and available::

#
Since this update is marked as reconfigimmediate, reboot the system

with the -r option:
ok boot -r
...

Remove this update’s entry in the disallowed_patch_list file so you

know you are finished administering this update:
# cat /var/sadm/spool/disallowed_patch_list
#
Be sure students understand the advantages of using smpatch update over the add commands:
consultation of update policy and accommodation of update dependencies.

Working With Multiple Updates

Many of the smpatch subcommands can be appied to multiple updates.
Following are some examples:
Multiple instances of the -i option are permitted if you just have a few
updates to apply:
# smpatch update -i 118927-02 -i 118822-15 -i 119681-06
A list of update IDs can be listing in a file, one per line, and referenced
using the -x idlist= option:
# smpatch update -x idlist=/var/sadm/spool/disallowed_patch_list
Note – If you specify particular patches by using the -i or -x idlist=

options, the list is augmented with patches on which they depend before
the update occurs.
The following example shows how to create a list of patches that you
actually want to apply from the larger list available and appropriate. It
also resolves the dependencies for the updates you want to apply.
Generate the full list of updates available and appropriate for your
system:
# smpatch analyze > my.list
Edit my.list and remove the ones you are not interested in:
# vi my.list
...
Analyze just the ones that are left and resolve dependencies:
# smpatch analyze -x idlist=my.list > /tmp/justdothese.list
Apply the updates:

# smpatch update -x -dlist=/tmp/justdothese.txt
Display Acrobat Reader for all to see. Open the Sun Update Manager 1.0 Administration Guide and go to
page 15 (Update List Operations). Discuss these examples with the class.
If you are teaching an LVC, engage a student to display this page for the class.

Working With Multiple Systems

The -n and -x mlist= options can be used with the smpatch
subcommands to extend functionality to managing updates on remote
systems.
The following command performs an analysis of a remote system called

sys-02:
sys-01> smpatch analyze -n sys-02 > sys-02.analysis.txt
The following command can be used to add a couple of updates to sys-

02 and sys-03:
sys-01> smpatch add -i 121693-02 -i 118822-25 -n sys-02 -n sys-03
If there are number of remote systems the -x mlist= option would be a

more convenient way to add updates:
sys-01> smpatch add -i 121693-02 -i 118822-25 -x mlist=/syslist.txt
The syslist.txt file contains a list of systems, one per line.
Note – Update sets or collections can also be established and the

management environment configured to use them. See the smpatch(1M)
man page for details.
Authorization and Authentication

The root user certainly can manage updates. You can designate non root
users for these tasks by having them assume a role that includes the
Software Installation profile or the solaris.admin.patchmgr.*
authorization.
The following command shows a smpatch get command on the remote

system sys-04 requiring assumption of the role (-r) called patchman:
sys-01> smpatch get -r patchman -n sys-04
Note – This delegation feature is not possible with the Sun Update
Manager GUI client application.

You can also require authentication for management tasks by establishing

a username and password:
# smpatch set patchpro.sun.user=user-name
# smpatch set patchpro.sun.passwd
Sun User Password: password
Management commands then would require use of the -u (username) and

-p (password) option. (A prompt for a password would be invoked if the
-p option were not on the command line.)

Installing Patch Clusters

A patch or update cluster provides a selected set of updates for a
designated Solaris OS level and is conveniently wrapped for one-step
installation. Patch clusters are usually a set of recommended or security
updates.
You should not install cluster patches on systems with limited disk space.
Consult the cluster README file for details on this and other important
requirements like if installation should be done in single-user mode. Often
each package or patch included in the cluster has its own README file.
These files will contain important installation considerations.
By default, the cluster installation procedure saves the base objects being
patched. Prior to installing the patches, the cluster installation script first
determines if enough system disk space is available to save the base
packages and terminates if not enough space is available.
You can override the save feature by using the -nosave option when you
are executing the cluster installation script. If you use the -nosave option,
you will not be able to back out individual patches if the need arises.
You can remove individual patches that were installed by the patch
cluster by using the patchrm command. The README file is located in the
specific patch directory under the /var/sadm/spool directory after the
patch has been installed. To install a patch cluster, perform the following
steps:
1. Be sure the patch cluster has been unzipped and extracted.
2. Decide on which method to use to install the cluster—the
recommended default save option or the -nosave option.
3. Change to the directory that contains the patch cluster (this is
typically the top level directory extracted from the achive file). Read
the CLUSTER_README file, which contains information about the
bundled set of patches, including:
● Cluster description
● Patches included
● Important notes and warnings
● Save and backout options
● Special install instructions
● Special patch circumstances

● Any notices and other recommendations

Also examine any individual README files that might have been
included below the cluster update component packages.
# cd /var/sadm/spool/clusters/J2SE_Solaris_10_Recommended
# ls
117461-08 119578-16 copyright patch_order
118822-27 CLUSTER_README install_cluster
# ls -l 117461-08/*READ* 118822-27/*READ* 119578-16/*READ*

-rw-r--r-- 1 root root 9333 Dec 8 10:31 117461-08/README.117461-08
-rw-r--r-- 1 root root 85142 Feb 6 11:34 118822-27/README.118822-27
-rw-r--r-- 1 root root 9730 Feb 13 12:51 119578-16/README.119578-16
Tell students that in this example, the J2SE_Solaris_10_Recommended cluster contains three update/patch
components: 117461-08, 118822-27, and 119578-16, each of which have their own README files.
4. Run the install_cluster script.

The README file recommends running the script in singleuser
mode.
# init S
....
# ./install_cluster
Patch cluster install script for J2SE Solaris 10 Recommended Patch
Cluster
*WARNING* SYSTEMS WITH LIMITED DISK SPACE SHOULD *NOT* INSTALL PATCHES:
With or without using the save option, the patch installation process
will still require some amount of disk space for installation and
administrative tasks in the /, /usr, /var, or /opt partitions where
patches are typically installed. The exact amount of space will
depend on the machine's architecture, software packages already
installed, and the difference in the patched objects size. To be
safe, it is not recommended that a patch cluster be installed on a
system with less than 4 MBytes of available space in each of these
partitions. Running out of disk space during installation may result
in only partially loaded patches. Check and be sure adequate disk space
is available before continuing.
Are you ready to continue with install? [y/n]: y

Determining if sufficient save space exists...
Sufficient save space exists, continuing...
Installing patches located in patch_order file in
/var/sadm/spool/clusters/J2SE_Solaris_10_Recommended

Using /var/sadm/spool/clusters/J2SE_Solaris_10_Recommended/patch_order
file for
patch installation sequence
Installing 119578-16...
Installation of 119578-16 succeeded. Return code 0.
Installation of 118822-27 succeeded. Return code 0.
Installation of 117461-08 failed. Return code 1.
The following patches were able to be installed:

119578-16
118822-27
ERROR: The following patches were not able to be installed:

117461-08
For more installation messages refer to the installation logfile:

/var/sadm/install_data/J2SE_Solaris_10_Recommended_Patch_Cluster_log
Use '/usr/bin/showrev -p' to verify installed patch-ids.

Refer to individual patch README files for more patch detail.
Rebooting the system is usually necessary after installation.
As suggested by the install_cluster script output, verify what

installed:
# showrev -p | grep 119578-16
Patch: 119578-16 Obsoletes: 119330-01, 119331-01, 119559-01, 119576-01
....
Patch: 118822-27 Obsoletes: 118548-01, 118550-04, 119719-01,
...
Patch: 117461-08 Obsoletes: Requires: Incompatibles: Packages:
...
The showrev -p command shows that 117461-08 is installed but the

the output from the install_cluster script said it didn’t install it.
5. Reviewing the log provides information about why the updates
listed above were not able to be installed.
# more /var/sadm/install_data/J2SE_Solaris_10_Recommended_Patch_Cluster_log
*** Install J2SE Solaris 10 Recommended Patch Cluster begins ***
*** Thu Feb 16 09:10:49 MST 2006 ***
*** PATCHDIR = /var/sadm/spool/clusters/J2SE_Solaris_10_Recommended ***

...

119578-16
Checking installed patches...

Executing prepatch script...
Temporarily disabling fmd(1M)
Verifying sufficient filesystem capacity (dry run method)...
Installing patch packages...

See /var/sadm/patch/119578-16/log for details
Executing postpatch script...
Re-enabling fmd(1M)
Patch packages installed:

FJSVfmd
SUNWckr
...
...

118822-27


See /var/sadm/patch/118822-27/log for details
Executing postpatch script...

FJSVhea
FJSVpiclu
...

...
The following requested patches are already installed on the system

Requested to install patch 117461-08 is already installed on the
system.
No patches to check dependency.
Point out (bolded) that the log file tells us the reason why the install script did not install 117461-08 and the
showrev -p command showed that it was installed.
6. Revisit each individual update README file to determine if any

additional steps are required to fully install any individual update.
7. Reboot the system for all patches to take effect.

Further Information
Further Information
Many other tasks can be learned by consulting docs.sun.com. Table 6-2 is
brief listing of other tasks and their URLs on docs.sun.com.
As time and interest permit, display a browser for all to see and visit some of these resources.
If you are teaching an LVC, engage a student by selecting someone to do this.
Table 6-2 Further Resources For Management Tasks
Task URL
How to download http://docs.sun.com/app/docs/doc/817-

and apply an 1985/6mhm8o620?a=view
upddate manually
How to Change the http://docs.sun.com/app/docs/doc/817-
Policy for Applying 1985/6mhm8o61k?a=view
Patches (Command
Line)
How to Import a http://docs.sun.com/app/docs/doc/817-
Trusted Certificate 1985/6mhm8o61u?a=view
to Your Package
Keystore
Patch Manager http://docs.sun.com/app/docs/doc/817-
Troubleshooting 1985/6mhm8o61o?a=view
Also, if of interest, page 13 of 88 in the Sun Update Manager 1.0 Admin Guide contains a table comparing
the Sun Update Manager and the smpatch commands. This and other documents are in the /opt/ses/docs
directory, installed from the student bundle.

Introducing the Sun Update Connection Hosted Web Application
Introducing the Sun Update Connection Hosted Web

Application
The Sun Update Connection Hosted Web application is one way of
implementing update management offered by the Sun Update
Connections Services. Figure 6-4 shows placement and use of the Hosted
Web application.

and Infrastructure
Customer
Firewall
Sun
Update
Connection
Web Browser
IT Manager/Sysadmin
Hosted Web
Application
System A
System B
System C
Figure 6-17 The Sun Update Connection Web Hosted Application
Before you can manage your systems with the Sun Update Connection
services, you must register them using the Sun Update Manager
registration wizard. This includes specifying your intention to remotely
manage updates.
The Sun Update Connection services enable you to remotely manage

updates on all of the registered Solaris 10 systems at one time from one
common web interface.

Introducing the Sun Update Connection Hosted Web Application
The Sun Update Connection services use the system information you provided at system registration time to
determine which updates are appropriate for each of your Solaris 10 systems.
Each of your registered systems check in to the Sun Update Connection

web site or to your Sun Update Connection Proxy at specified intervals.
When the system checks in, any queued jobs for that system are run. A job
is an update-management activity that runs on one or more managed
systems.
Note – Do not use the Sun Update Manager GUI, the Sun Update
Connection Hosted Web application, the smpatch command, and the
patchadd command simultaneously to manage updates on your system.
You can use all these methods, but not simultaneously.

Using the Sun Update Connection Hosted Web Application

After establishing a Sun Online account and registering your system(s),
you log into the Sun Update Connection web site and see the initial
Summary page shown in Figure 6-18.
Figure 6-18 Sun Update Connection Web Application Summary Page
The same registration process, including the required Sun Online account and submission of a subscription
key, discussed from Figure 6-6 to Figure 6-12 applies here before you are able to log in and start
management of registered systems. (However, if this procedure was done during installation of a Sun Update
Manager client, then it would not be required again during initial contact using the web hosted application;
only the very first contact with the Sun Update Connection Services invokes the registration screens.
The four tabs (Summary, Systems, Updates, and Jobs) are the main
categories of management tasks available with this interface. A quick
glance at this Summary screen alerts you to
● The security and recommended updates available

● The number of your systems that are registered and the number that
have not cheched in with the Sun update server
● The status of update jobs including the number that failed and
succeeded
Clicking the System tab brings up the level of detail shown in Figure 6-19.
Figure 6-19 Sun Update Connection Web Application Systems Page
From this Systems page you can see:

● The last check in time, per system
● The available updates, per system
● The job status, per system
● A tally of the jobs added in this connection session (shown as 0 in
this example)
● The same all system job status available on the Summary screen

You can select a system in the left column and then click View Available
Updates to find details on the updates relevant for that system.
Figure 6-20 shows this detail.
Figure 6-20 Sun Update Connection Showing Available Updates for a

Selected System
The Dependencies column quickly tells you the number of dependencies

for the updates selected. In this example, three more updates
(dependencies) would need to be processed for a total of six.
You can click the Type heading (column 2) and order the rows on those
values. This will bring all the security updates to the top of the list
followed by the recommended patches. The non-critical updates would be
at the bottom.

Each Update ID value and each Synopsis string is a link. Clicking one
brings up the detail for that update as shown in Figure 6-21.
Figure 6-21 Sun Update Connection Showing Details for a Selected

Update
This detail is the information typically found in an update README file.
From the Available Updates screen (Figure 6-20) you start the update
process by selecting the updates you want to apply. Once the updates are
selected, click the Apply Updates to schedule the work. Scheduled work
is a job.

Figure 6-22 shows details related to the jobs.
Figure 6-22 Sun Update Connection Required Dependency Details
The required dependencies screen gives you a look at what other updates
are required to support those you explicitly selected. You can cancel if you
need to, otherwise click the Install button to submit the jobs.

Figure 6-23 shows the confirmation screen that displays next.
Figure 6-23 Sun Update Connection Job Confirmation
This confirmation page can be printed for your records. Notice also that
the six jobs show now as Pending in the All Jobs table.
Students may ask about why there are 12 in the figure. This is because there were 6 earlier jobs on this
system before this scenario began.

Clicking the Jobs tab presents details about the jobs for this and other
sessions as shown in Figure 6-24.
Figure 6-24 Sun Update Connection Job Screen Showing Jobs Pending
Before an update job competes the job status is recorded as pending or in

progress. The Systems Affected column in the case of this example is 1
(pod04) but you can easily apply updates to multiple systems. The time
column in the case of Pending jobs is that of the UTC time for the job
submission.
Pending means that the job has been submitted but is waiting in a queue
for the managed system to retrieve it. In progress means that the managed
system has received the job but has not responded back with a success for
failed completion status message.
You can cancel pending jobs.
The default check in interval is set to 2 hours. This can be changed but 2
hours is the minimum possible. If you leave the session open, you will be
disconnected.

Log back in to Sun Update Connection Services to check the status of the
jobs. You may see what is shown in Figure 6-25
Figure 6-25 Sun Update Connection Job Screen Showing Job Success
After logging in and checking the Jobs tab, we see that the six jobs have
succeed. The UTC time shown for Jobs with this status is the time the job
completed. Notice the update of the Job Summary table. The number
shown for Added this Session restarts at 0 when you log out and log back
in.
Overtime, your Jobs tab screen will included many rows of information.
You can archive the older ones by clicking the icon next to the Succeeded
status of each job. Alternatively, you can use the checkbox in column one
to selecte multiple jobs and click the Archive Jobs button.

Leveraging the Systems Affected Function

A typical update scenario involves learning that some recommended
updates have been made available that you want to install on the
appropriate subset of your registered systems. Figure 6-26 shows the
Update tab with updates sorted. This groups the Security updates
together followed by the Recommendate updates. A couple of the
recommended updates have been selected with marks in their
checkboxes.
Figure 6-26 Sun Update Connection Updates Sorted
Each of the selected recommended patches has two dependencies. If you

want to know which systems these patches apply to, click the View
Systems Affected button.

Figure 6-27 shows the screen that displays.
Figure 6-27 Sun Update Connection Showing Systems Affected
The Systems Affected screen lists all the registered systems to which these
updates apply. Following are details to note about the information
displayed on this screen:
● By default, all the left column checkboxes are filled in but you can
deselect full system or any update or any system
● The last column shows any previous versions of the selected updates
that are already installed on any of the systems
● The small triangular twistee next to the update name collapses
nested information
Obviously having a course development environment with only two registered systems does not make a big
impression about this Systems Affected functionality. Remind students how beneficial this would be when
managing hundreds of systems.

After selecting the systems and updates to apply, click the Apply Updates
button to create jobs for the updates. Figure 6-28 shows the next screen
you can expect to see.
Figure 6-28 Sun Update Connection Showing System Dependencies
This dependency screen is similar to the one shown earlier except that the
information is displayed for all systems to be updated. Click on the Install
button on the bottom of this screen (not shown) to schedule the jobs.

Figure 6-29 shows the confirmation page that displays.
Figure 6-29 Sun Update Connection Job Confirmation
The confirmation page shows the number of jobs pending in the all jobs
summary box and also announces the time the jobs are scheduled to
execute so you can log back in at a known time to check that status of the
work.

Module 7
Performing User Administration
Objectives
● Describe the Changes in User Administration between Solaris 8, 9,
and 10
● Perform user Installations, Modifications, and Deletions with new
tools and commands
7-1
Relevance
Relevance
Discussion – The following questions are relevant to understanding what

User Administration is all about:
!
?
● What are the changes in commands for user administration?
● What are the changes in GUI tools for user administration?


● System Administration Guide: Security Services, PN 816-4557
Performing User Administration 7-3


An important system administration task is setting up user accounts for
each user who requires system access. Each user needs a unique account
name, a user identification (UID) number, a home directory, and a login
shell. You also have to determine which groups a user may access.
Managing User Accounts

In the Solaris 8 and 9 Operating Systems, a password was a combination
of 6 to 8 letters, numbers, or special characters. Solaris 10 introduced
better security measures which increased the password to a combination
of up to 256 letters, numbers, or special characters.
The complexity of passwords can also be configured now. This is

discussed in greater detail in the next module, “Performing System
Security”.
The /etc/shadow File
Each entry in the /etc/shadow file contains nine fields. A colon separates
each field.
Following is the format of an entry:

loginID:password:lastchg:min:max:warn:inactive:expire:flag
Prior to Solaris 10, the last field (flag) was not used. In Solaris 10, it is used
to track failed logins. The count is in low order four bits. The remainder is
reserved for future use, set to zero.

Miscellaneous Items
The cron daemon will no longer run cron jobs associated with locked user
accounts. A locked account is no longer considered a valid user account.
Solaris 9 introduced a default failback shell for root if the administrator

changes the root shell in the /etc/passwd file to a non-existent shell. The
default failback shell is /sbin/sh. You can gain access to the failback shell
via single-user mode or by a command line login.
The dtlogin program does not implement the failback shell for root
although you can log in as a normal user and su to root.

Changes in Command-Line Tools

The Solaris OS provides these command-line tools, defined as follows:
● useradd – Adds a new user account on the local system
● usermod – Modifies a user’s account on the local system
● userdel – Deletes a user’s account from the local system
● groupadd – Adds a new group entry to the system
● groupmod – Modifies a group entry on the system
● groupdel – Deletes a group entry from the system
In addition to these standard command-line tools, the Solaris 9 and 10 OS

has a set of command-line tools that accomplish the same tasks. They are
the smuser and smgroup commands.
The smuser command enables you to manage one or more users on the
system with the following set of subcommands:
● add – Adds a new user account
● modify – Modifies a user’s account
● delete – Deletes a user’s account
● list – Lists one or more user entries
The smuser and smgroup commands interact with naming services, can
use autohome functionality, and are better suited for remote management.
Note – The smuser and smgroup commands are the command-line

interface equivalent to the Solaris Management Console range of
operation, and allow you to perform Solaris Management Console actions
in scripts. Therefore, the smuser and smgroup commands have numerous
subcommands and options designed to function across domains and
multiple systems. This module describes only the basic commands.
The smgroup command enables you to manage one or more groups on the
system with the following set of subcommands:
● add – Adds a new group entry
● modify – Modifies a group entry
● delete – Deletes a group entry

● list – Lists one or more group entries
Any subcommand to add, modify, list, or delete users with the smuser
and smgroup commands requires authentication with the Solaris
Management Console server and requires the initialization of the Solaris
Management Console. For example, the following is the command format
for the smuser command:
/usr/sadm/bin/smuser subcommand [auth_args] -- [subcommand_args]
The authorization arguments are all optional. However, if you do not

specify the authorization argument, the system might prompt you for
additional information, such as a password for authentication purposes.
The -- option separates the subcommand-specific options from the

authorization arguments. The -- option must be entered even if an
authorization argument is not specified because it must precede the
subcommand arguments.
The subcommand arguments are quite numerous. For a complete listing

of the subcommands, refer to the smuser man page. It is important to note
that descriptions and other arguments that contain white space must be
enclosed in double quotation marks.
Using the smuser Command
The smuser add Command Format and Options
The following is the command format for the smuser add command:
smuser add [auth_args] -- [subcommand_args]
Table 7-1 shows some of the most common subcommand arguments for
the smuser add command.
Table 7-1 Subcommand Arguments for the smuser add Command
Subcommand
Definition
Argument
-c comment A short description of the login, typically the

user’s name. This string can be up to 256
characters.

Table 7-1 Subcommand Arguments for the smuser add Command

(Continued)
-d directory Specifies the home directory of the new user and is
limited to 1024 characters.
-g group Specifies the new user’s primary group
membership.
-G group Specifies the user’s secondary group membership.
-n login Specifies the user’s login name.
-s shell Specifies the full path name of the user’s login
shell.
-u uid Specifies the user ID of the user you want to add.
If you do not specify this option, the system
assigns the next available unique UID greater than
100.
-x autohome=Y|N Sets the home directory to automount if set to Y.
The following example uses the smuser add command to create an

account for a user named newuser2. It designates the login name as
newuser2, assigns the UID number 500, adds the user to the group other,
creates a home directory in the /export/home directory, and sets
/bin/ksh as the login shell for the user account.
Note – The -x autohome=N option to the smuser command adds the user
without automounting the user’s home directory. See the man page for
automount for more information.
# /usr/sadm/bin/smuser add -- -n newuser2 -u 500 -g other -d

/export/home/newuser2 -c "Regular User Account 2" -s /bin/ksh -x
autohome=N
Authenticating as user: root
Type /? for help, pressing <enter> accepts the default denoted by [ ]

Please enter a string value for: password :: Enter_The_root_Password
Loading Tool: com.sun.admin.usermgr.cli.user.UserMgrCli from sys-02
Login to sys-02 as user root was successful.
Download of com.sun.admin.usermgr.cli.user.UserMgrCli from sys-02
was successful.

Users are added without a password by default with the smuser

command. This can be verified by viewing the appropriate entry in the
/etc/shadow file:
# grep ’newuser2’ /etc/shadow
newuser2::12708::::::
Use the passwd command to create a new password for the user.
# passwd newuser2
New Password: 123pass
Re-enter new Password: 123pass
passwd: password successfully changed for newuser2
Confirm that the password change has been applied by viewing the entry
for that user in the /etc/shadow file:
# grep ’newuser2’ /etc/shadow
newuser2:FSMOsxncoc6yI:12708::::::
The smuser modify Command Format and Options
The following is the command format for the smuser modify command:
smuser modify [auth_args] -- [subcommand_args]
In general, the options for the smuser modify command function the
same as for the smuser add command. Refer to the smuser(1M) man
page for additional options.
Table 7-2 shows the options for the smuser modify command.
Table 7-2 Options for the smuser modify Command
Option Definition
-n login Specifies the user’s login name

-N login Specifies the user’s new login name
The following example changes the login name and home directory for
newuser2 to userb.
# /usr/sadm/bin/smuser modify -- -n newuser2 -N userb -d
/export/home/userb


Download of com.sun.admin.usermgr.cli.user.UserMgrCli from sys-02 was
successful.
The smuser delete Command Format and Options
The following is the command format for the smuser delete command:
smuser delete [auth_args] -- [subcommand_args]
The following example removes the userb account from the system:
# /usr/sadm/bin/smuser delete -- -n userb

Download of com.sun.admin.usermgr.cli.user.UserMgrCli from sys-02 was
successful.
Note – Unlike the userdel command, the smuser delete command has
no -r equivalent option for deleting the home directory. The user’s home
directory must be deleted manually.

Using the smgroup Command
The smgroup add Command Format and Options
The following is the command format for the smgroup add command:
/usr/sadm/bin/smgroup subcommand [auth_args] -- [subcommand_args]
Table 7-3 shows the options for the smgroup add command.
Table 7-3 Options for the smgroup add Command
Option Description
-g gid Specifies the GID number for the new group

-m group_member Specifies the new members to add to the group
-n group_name Specifies the name of the new group
The following example uses the smgroup add command to create a new
group called workgroup with a GID of 123, and to add usera to the
group:
# /usr/sadm/bin/smgroup add -- -n workgroup -g 123 -m usera

Loading Tool: com.sun.admin.usermgr.cli.group.UserMgrGroupCli from sys-02
Download of com.sun.admin.usermgr.cli.group.UserMgrGroupCli from sys-02
was successful.
The smgroup modify Command Format and Options
The following is the command format for the smgroup modify command:
Table 7-4 shows the options for the smgroup modify command.
Table 7-4 Options for the smgroup modify Command
Option Description

Table 7-4 Options for the smgroup modify Command
-n name Specifies the name of the group you want to

modify
-m new_member Specifies the new members to add to the group
-N new_group Specifies the new group name
The following example changes the group workgroup to schoolgroup:

# /usr/sadm/bin/smgroup modify -- -n workgroup -N schoolgroup

was successful.
The smgroup delete Command Format and Options
The following is the command format for the smgroup delete command:
You can use the -n group_name option with the smgroup delete
command to specify the name of the group you want to delete.
The following example deletes the group entry schoolgroup from the
local system:
# /usr/sadm/bin/smgroup delete -- -n schoolgroup
was successful.

Changes in GUI Tools

Solaris 8 managed user accounts with the administration utility
admintool. In the transition from Solaris 8 to Solaris 10, admintool has
become EOL’d and the replacement tool is called Solaris Management
Console (SMC).
Introducing the Solaris Management Console

The Solaris Management Console is a Java technology-based tool for the
administration of systems. It provides a central integration point for the
configuration and administration of important applications and services.
The Solaris Management Console can be started from the command line
or from within the Application Manager by clicking the Solaris
Management Console icon.
Log in to your system as root, and type smc& in a terminal window. You
can start the Solaris Management Console as a normal user, but some
tools and applications are not available to you. When you initiate the
Solaris Management Console for the first time, it can take a few minutes
to launch.
When the system is first booted the Java based SMC server program is not
started. In its place are 3 programs called smcboot. Executing the pfiles
command on the first instance of smcboot will show that it is listening at
port 898 for any incoming SMC server requests. If SMC is run, the 3
smcboot programs are replaced by the Java based SMC server program.
The program can be found by running ps -ef | grep smc.
The SMC server is the program known as:

java -Dviper.fifo.path=/var/run/smc898/boot.fifo.
You will also note that the SMC console program is now running and is:
java -
Djava.security.policy=/usr/sadm/lib/smc/policy/smcconsole.

Using the Solaris Management Console Tools
The default toolbox for a Solaris Management Console server includes the
following folders and tools:
System Status This category includes System Information, Log

Viewer, Processes, and Performance.
System This category includes Users, Projects, Computers
Configuration and Networks, and Patches.
Services This category includes Scheduled Jobs.
Storage This category includes Mounts and Shares, Disks,
and Enhanced Storage.
Devices and This category includes Serial Ports.
Hardware
The Solaris Management Console enables local users and administrators

to register remote Solaris Management Console servers and applications
on the network they want to administer. When you access the Solaris
Management Console, it dynamically configures tree views of those
registered hosts and services. Point and click with the mouse to invoke an
application remotely on a selected Solaris Management Console server
and view the application’s GUI on the local display.
Restarting the Solaris Management Console
If you have trouble accessing Solaris Management Console, the reason

might be that the Solaris Management Console server is not running or is
in a problem state.
To determine if the Solaris Management Console server is running,

perform the command:
# /etc/init.d/init.wbem status
If the Solaris Management Console server is running, a response similar to

the following returns: “Solaris Management Console server
version 2.1.0 running on port 898.”

Note – If this is the first time SMC has been run after a reboot, this
command may show an error.
To stop the Solaris Management Console server, as the root user, perform
the command:
# /etc/init.d/init.wbem stop
The following response returns: “SMC stopped.”
To start the Solaris Management Console server, as the root user, perform
the command:
# /etc/init.d/init.wbem start
After a short time, the following response returns: “SMC server

started.”
Identifying the Functional Areas of the Solaris Management

Console
The Solaris Management Console and the Solaris Management Console

Toolbox Editor windows are divided into functional areas as follows:
● Navigation pane
● View pane
● Information pane
● Location bar
● Status bar

Figure 7-1 shows these divisions.
Menu bar
Location bar
Navigation pane
View pane
Information pane
Context Help and

Console Events tabs
Status bar
Figure 7-1 Solaris Management Console Overview
Note – The Location bar does not appear by default when you first launch
the Solaris Management Console. Click View on the Menu bar, select the
Show option, and select the Location option to display the Location bar.
Navigation Pane
The Navigation pane works like a frame in a web page. Clicking an item
in the Navigation pane determines what appears in the View pane. The
turner icon is displayed to the left of items that represent a group of items.
Click the icon or the item to expand or collapse the group.
The Navigation pane is displayed or not displayed, depending on the

Show setting in the View menu. Click View on the Menu bar, select the
Show option, and select or deselect the Navigation option.
View Pane
The View pane displays the contents of the node selected in the
Navigation pane. The contents could be a folder or a tool.

If the node selected in the Navigation pane is a folder, the View pane
displays the contents of that folder.
If the node selected is a simple tool, such as the Process tool, the View
pane displays a list of current processes. If the node selected is a complex
tool, such as User Manager, the View pane displays additional tools, such
as the tools for user accounts and email accounts. Select one of the
additional tools, such as the user accounts node, and the View pane
displays the contents of the tool.
Information Pane
The Information pane at the bottom of the Solaris Management Console

window displays either context help for the object selected in the
Navigation pane or a list of events and alarms for all Solaris Management
Console events.
The Context Help tab and Console Events tab determine what is shown in
the Information pane. Click the Context Help tab to display context help
for the object selected. Click the Console Events tab to display a list of
events and alarms for all Console events.
The Information pane is displayed or not displayed, depending on the

Show setting in the View menu. Click View on the Menu bar, select the
Show option, and select or deselect the Information option.
Location Bar
The Location bar, beneath the tool bar in the Solaris Management Console
window, displays a Home Toolbox icon and a Toolbox field. Click the
Home Toolbox icon to open the home toolbox. The Toolbox field indicates
the current toolbox and the item currently selected in the toolbox. Click
the button to the right of the Toolbox field to display a pull-down menu of
recent toolboxes visited. Select a toolbox from the pull-down menu to
open that toolbox.
The Location bar is displayed or not displayed, depending on the Show

setting in the View menu. Click View on the Menu bar, select the Show
option, and select or deselect the Location option.

Status Bar
The Status bar, located across the bottom of the Solaris Management
Console window, displays three panes. The left pane of the Status bar
indicates the number of nodes directly subordinate to the node selected in
the Navigation pane. The center pane of the Status bar indicates Console
activity. A moving bar inside the center pane functions as an activity
indicator when Console activity occurs. The right pane of the Status bar
provides progress information during some Console tasks.
The Status Bar is displayed or not displayed, depending on the Show

setting in the View menu. Click View on the Menu bar, select the Show
option, and select or deselect the Status bar option.
Adding a User Account
The default method of adding a user account through Solaris

Management Console is to add the user account with the user’s home
directory automounted. The following steps demonstrate how to build a
user template that adds the user account with the user’s directory under
the /export/home directory.
To add a user account, perform the following steps:

1. Click This Computer in the Navigation pane to display the system
management tools.
2. Click System Configuration to display the tool for setting up a new
user account.
3. Click Users and enter the user name and password to be used for
authentication if prompted to do so by Solaris Management Console.
4. Double-click User Templates to access the tool to create and manage
user templates.
5. From the Menu Bar, select Add User Template from the Action list.

Figure 7-2 shows the Add User Template window.
Figure 7-2 Add User Template Window
6. Type SA200user in the User Template Name field. You can provide
an optional description if you would like.

7. Click the Home Directory tab. Type your system name in the Home
Directory Server field. Uncheck the check box labelled Automatically
Mount Home Directory.
Figure 7-3 shows the Add User Template window with the Home
Directory Information completed.
Figure 7-3 Add User Template Window (Home Directory Tab)

8. Click OK, and the Solaris Management Console (User Templates)

window, as shown in Figure 7-4, reappears with the SA200user
template in the View pane.
Figure 7-4 Management Tools: Solaris Management Console Window –

User Templates

9. Click User Accounts from the Navigation pane, and a list of user
accounts on the system appears in the View pane. See Figure 7-5.
Figure 7-5 Management Tools: Solaris Management Console Window –

User Accounts

10. From the Menu Bar, select Action. Then select Add User, and then
select From Template. The Add User From Template window
appears. See Figure 7-6.
Figure 7-6 Add User From Template Window
Because you only have one template created, it is the default template
available from the User Template pull-down list.
11. In the field beside User Name, enter the login ID of the user you
want to create. A full name and description are optional.
12. Click the button User Must Use and fill in the password and
confirmation fields with the password 123pass.
13. Click OK and the Solaris Management Console (User Accounts)
window reappears with the user account you just created in the
View pane.

14. Double-click the user account you just created. The User Properties
window appears, as shown in Figure 7-7. You can view and modify
the properties of that user account.
Figure 7-7 User Properties Window
15. Click the Group tab.

The screen changes to reveal a list of groups. Figure 7-8 shows the
information under the Group tab, including the primary group to
which the user belongs and a list of available groups.
Figure 7-8 User Properties Window – Adding Groups
16. You can click a group listed under Available Groups, then click Add,
and the group moves into the Member Of column.
17. Add the groups to which you want the user to belong, and then click
OK.

Module 8
Performing System Security
Objectives
Upon completion of this module, you should be able to describe the
Changes in Basic Security Administration between Solaris 8, 9, and 10.
8-1
Relevance
Relevance

system security is all about:
!
?
● How has basic security improved from Solaris 8 through Solaris 10?


● System Administration Guide: Security Services, PN 816-4557
● See the man pages on: passwd(1), crypt.conf(4), policy.conf(4),
audit_control(4), audit_user(4), auditconfig(1M),
cryptoadm(1M), ipfilter(5), ifconfig(1M), ipsecconf(1M), and
routeadm(1M)
Performing System Security 8-3

Controlling System Access

The more access that is available over the network, the more beneficial it
is for remote system users. However, unrestricted access and sharing of
data and resources can create security problems.
Security topics that are discussed in this module are limited to the topics
that are covered in the System Administration I and II courses. There is
far more information on security available in the following courses:
● SC-300; Administering Security on the Solaris Operating System
● SC340; Enterprise Security Assessment and Best Practices
● SC345; Solaris(TM) Operating Environment Network Intrusion Detection
● SC360; Enterprise Security Using Kerberos and LDAP
● SC410; Computer Security Forensics and System Recovery
File Transfer Protocol (FTP) Access

Solaris 9 introduced a new ftp server based on wu-ftpd. Originally
developed by Washington University in Saint Louis, wu-ftpd is widely
used for distribution of bulk data over the Internet and is the preferred
standard for large FTP sites. For information on the licensing terms, refer
to the materials that are incorporated at:
/var/sadm/pkg/SUNWftpu/install/copyright.ftp
This new server provides a directory structure under /etc/ftpd. The

/etc/ftpd/ftpusers file lists the names of users who are prohibited from
connecting to the system through the FTP protocol; for example:
root
daemon
bin
sys
user1
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.

Other files located under the /etc/ftpd structure are described in the
following table.
File Description
ftpaccess The configuration file used to control the overall

operation of the Server, return messages to the
FTP client related to specific events, specify
classes of users who are allowed to execute
certain commands or to download and upload
files.
ftpconversions Conversion database for changing formats and
handling different compression formats.
ftpgroups Contains enhanced group access information.
ftphosts Used to allow or deny access to accounts from
specific hosts.
ftpservers Used to configure virtual hosting. Use a set of
configuration files for each virtual host in a
separate directory.
Create or edit Used to send messages to users of the ftp service.
/etc/ftpd/
Welcome
The Solaris 10 release includes several changes to the FTP service. The ftp
command has been changed. The default mode for transfer of files has
been changed from ascii to binary. By default, a Solaris FTP client
connected to a Solaris FTP server lists both directories as well as plain files
when the ls command is issued to the client. If the FTP server is not
running in the Solaris OS, directories may not be listed.
To allow for the default Solaris behavior when connecting to non-Solaris

FTP servers, the /etc/default/ftp file can be edited appropriately on
each Solaris client. To make the change for individual users, the
FTP_LS_SENDS_NLST environment variable can be set to yes.
For more information see the ftp(4) man page.
Other changes include enhancements to the FTP server, and changes to

the ftpcount, ftpwho and ftp commands. New capabilities supported in
the ftpaccess file are:

● flush-wait controls the behavior at the end of a download or

directory listing
● ipcos sets the IP Class of Service for either the control or data
connection
● Passive ports can be configured so that the kernel selects the TCP
port to listen on
● quota-info enables retrieval of quota information
● recvbuf sets the receive (upload) buffer size used for binary
transfers
● rhostlookup allows or disallows the lookup of the remote hosts
name
● sendbuf sets the send (download) buffer size used for binary
transfers
● xferlog format customizes the format of the transfer log entry
The /etc/shells File
The /etc/shells file was removed in Solaris 9. The addition of the wu-
ftpd version of FTP resulted in better control in restricting FTP access
than was available with the /etc/shells file.
System Files That Store User Account Information

The Solaris OS stores user account and group entry information in the
following system files:
● /etc/passwd
● /etc/shadow
● /etc/group
Solaris 9 introduced a new account to the system files:
User User
Description
name ID
smmsp 25 The sendmail message submission deamon

account.

Solaris 10 introduced two new accounts to the system files.
User User
Description
name ID
gdm 50 Gnome Display Manager daemon.

webservd 80 Account reserved for WebServer access.
Password Management
Solaris 10 introduced a much more robust password policy. A password
can now be a combination of up to 256 letters, numbers, or special
characters that a user enters with the login name to gain access to a
system.
To enable 256 character passwords, the encryption policy in

/etc/security/policy.conf needs to be changed to either md5 or
blowfish. The line that reads: CRYPT_DEFAULT=_unix_ needs to be
changed to CRYPT_DEFAULT=2a (blowfish). The values 1, 2a, and md5
are explained in crypt.conf.
The Solaris 10 OS has new security enhancements. The pam_unix_auth

module implements account locking for local users. Account locking is
enabled by the LOCK_AFTER_RETRIES tunable parameter in
/etc/security/policy.conf and the lock_after-retries key in
/etc/user_attr.
The LOCK_AFTER_RETRIES=YES|NO parameter specifies whether a local

account is locked after the number of failed login attempts for a user is
equal to, or exceeds the allowed number of retries. The number of retries
is defined by RETRIES in /etc/default/login.
The passwd command has two new options, -N and -u. The -N option
creates a password entry for a non-login account. This option is useful for
accounts that should not be logged in to, but must run cron jobs. The -u
option unlocks a previously locked account. The passwd -N username
command sets the password field in /etc/shadow to NP which is an
unmatchable password. This effectively disables the account from logging
in.
For more information, see the passwd(1) man page.

The following example shows how to prevent a user from reusing too
many previous passwords.
# vi /etc/default/passwd
(output edited for brevity)
# HISTORY sets the number of prior password changes to keep and
# check for a user when changing passwords.
# The maximum value of HISTORY is 26.
#
# This flag is only enforced for user accounts defined in the
# local passwd(4)/shadow(4) files.
#
#HISTORY=0
#
Locate the line called #HISTORY=0, and remove the comment from the
beginning of the line. Modify the number to 3, so the line shows as
HISTORY=3. Write and quit the file. As a regular user, log in and attempt
to change your password a number of times, using different passwords
and then one of the previous passwords.
# telnet localhost
Trying 127.0.0.1...
Connected to localhost.
Escape character is ’^]’.
login: testuser
Password: 123pass
$ passwd
passwd: Changing password for testuser
Enter existing login password: 123pass
New Password: pass123
Re-enter new Password: pass123
passwd: password successfully changed for testuser
$ passwd
passwd: Changing password for testuser
Enter existing login password: pass123
New Password: 123pass
passwd: Password in history list.
Please try again
New Password: newpas1
Re-enter new Password: newpas1
passwd: password successfully changed for testuser
$

By uncommenting the HISTORY= line in the /etc/default/passwd file,

prior password history is checked. By changing the value to 3, the
number of prior password changes to keep and check when a user
changes passwords is set to three.
The /etc/default/passwd File
Set values for the following parameters in the /etc/default/passwd file

to control properties for all users’ passwords on the system:
● MAXWEEKS – Sets the maximum time period (in weeks) that the
password is valid.
● MINWEEKS – Sets the minimum time period before the password can
be changed.
● PASSLENGTH – Sets the minimum number of characters for a
password. Valid entries are 6, 7, and 8.
● WARNWEEKS – Sets the time period prior to a password’s expiration to
warn the user that the password will expire.
Note – The WARNWEEKS value does not exist by default in the

/etc/default/passwd file, but it can be added.
The password aging parameters MAXWEEKS, MINWEEKS, and WARNWEEKS

are default values. If set in the /etc/shadow file, the parameters in that
file override those in the /etc/default/passwd file for individual users.
The Solaris 10 OS release introduces a number of new controls for

password management. These controls are configured by setting values in
the /etc/default/passwd file. These controls are commented out by
default.
● NAMECHECK=NO – Sets the password controls to verify that the user is
not using the login name as a component of the password.
● HISTORY=0 – Forces the passwd program to log up to 26 changes to
the user’s password. This prevents the user from reusing the same
password for 26 changes. If the HISTORY value is set to another
number other than zero (0), and then set back to zero, it causes the
password log for a user to be removed on the next password change.
● DICTIONLIST= – Causes the passwd program to perform dictionary
word lookups from comma-separated dictionary files.

● DICTIONDBDIR=/var/passwd – The location of the dictionary where

the generated dictionary databases reside. This directory must be
created manually.
Note – To pre-build the dictionary database, refer to the man page for
mkpwdict(1M).
Complexity of the password can be controlled using the following

parameters:
#MINDIFF=3
#MINALPHA=2
#MINNONALPHA=1
#MINUPPER=0
#MINLOWER=0
#MAXREPEATS=0
#MINSPECIAL=0
#MINDIGIT=0
#WHITESPACE=YES
By default, all of the above parameters are commented out.
Note – By forcing greater complexity of password structure, you may

inadvertently cause the users to write down their passwords as they may
be too difficult for the user to remember. When setting a password change
policy, you must not underestimate the problems that too much
complexity may cause.

Module 9
Configuring and Using Printer Services
Objectives
● Identify network printing fundamental changes
● Configure and administer printer services
9-1
Relevance
Relevance

changes were made to printing:
!
?
● How do I launch the print admin GUI?
● What printers are available for selection?


● See the man pages for lpadmin(1M).
Configuring and Using Printer Services 9-3

Network Printing Fundamentals

The Solaris OS LP print service provides a complete printing environment
that allows the sharing of printers across systems and a set of software
utilities that enable users to print files while they continue to work on
other tasks.
Solaris 8, 9, and 10 have always implemented a client-server model for

printing, utilizing a combination of systems that can be configured as
print servers or print clients. The basic functionality of initialization,
queuing, tracking, fault notification, and filtering has remained the same,
however the tools to configure printers and the range of available printers
has changed.
Printer Filters
In Solaris 10, modifications have been made to incorporate support for a
wide array of printers. This functionality differs greatly from previous
Solaris software releases.
In previous releases, it was only possible to print to printers that

understood PostScriptTM natively, or plain ASCII text. The list of
supported printer types, and information about whether these printer
types accepted PostScript or ASCII text, was limited. Now, 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. The database of printer description files is called the
foomatic database.
Raster Image Processor (RIP)
The RIP enables you to print to printers that do not have resident
PostScript processing capabilities. The Solaris printing software now
provides the print server RIP and supporting technologies. The RIP occurs
behind the scenes. However, to use the appropriate driver, you need to
configure each printer, by using either Solaris Print Manager or a new
option to the lpadmin command.

PostScript Printer Description (PPD)
PostScript is a language developed by Adobe® to describe a print

document. This language removed the need for application developers to
write support for many different makes and models of printers into their
applications. An application which created PostScript output could print
to any PostScript-capable printer.
When a printer vendor creates a printer which has features not referenced
by PostScript, a PostScript Printer Description (PPD) file describes the
device dependent features. It was also created by Adobe to allow printer
manufacturers to implement their own special features into PostScript.

Printer Tools
Printer Tools
Printing tools have changed across the Solaris 8, 9, and 10 versions of the
Operating System.
GUI Tools
In Solaris 8, the Solaris Print Manager GUI was introduced as the tool to
setup and manage both local and remote printers. Solaris 8 also retained
the print functionality through the old admintool GUI which could setup
and manage local printers only.
In Solaris 8 and 9, the Solaris Print Manager GUI was started with the
following command:
# /usr/sadm/admin/bin/printmgr
With Solaris 10, the Solaris Print Manager GUI is started with the
following command:
# /usr/sbin/printmgr
Through Solaris 9 and now with Solaris 10, the Solaris Print Manager has
been modified with some cosmetic changes to make it easier to use. More
importantly, the screens have been updated to enable you to choose a PPD
file for the print queue through the selection of make, model, and driver.
This new feature differs greatly from previous Solaris software releases. In
previous releases, the provided list of printer types, and information
about whether the printer accepted PostScript or ASCII text, was limited.
Solaris 10 has removed the old admintool GUI from the Operating
System.
In Solaris 10 01/06, the Solaris Print Manager has been expanded to

include an additional -Never Print Banner- option. This option ensures
that banner pages are never printed for the specified print queue.
Previously, you only had two choices for printing banner pages in Solaris
Print Manager:
● You could enable the -always print banner- option in Solaris Print
Manager

Printer Tools
● You could select the banner on or off option when you submitted a
print job. This option was on by default.
The Print Manager GUI has undergone a number of updates in the

information that requires and that you can configure in it. The following
table contains the information you would use to configure a new local or
network printer.
Available in releases Available in releases

Required Field
prior to Solaris 10 Solaris 10 and later
Printer Name A unique name for the printer. The name can
contain a maximum of 14 alphanumeric characters,
including dashes and underscores. This is the name
entered on the command line with a print
command.
Printer Server Defaults to the name of the system on which you are
currently running the Solaris OS Print Manager.
This system is the print server for this network
printer.
Description This field is optional. A printer’s description
commonly contains information to help users
identify the printer, for example, physical location
or printer type.
Printer Port Only required for attached printers.
Printer Type Yes PPD is enabled by default
in the Print Manager.
Not, by default, for the This allows you to choose
Solaris 9 OS /04 release a printer from the range
of supported printers in
/usr/lib/lp/model/p
pd/system/foomatic.
File Content Type Yes Yes, by deselecting the
Use PPD files options in
Not, by default, for the the Print Manager
Solaris 9 OS /04 release drop-down menu.
Printer Make No Yes
Yes, available in the

Solaris 9 OS /04 release
only

Printer Tools

Required Field
Printer Model No Yes. A list of supported
printer models for the
selected printer make.
The corresponding PPD
files are in:
/usr/lib/lp/model/p
pd/system/foomatic/
make
Printer Driver No Defaults to the foomatic
PostScript printer driver.
Yes, available in the
Solaris 9 OS /04 release
Fault Notification The list of choices for how the superuser is notified
of printer errors. These include: Write to Superuser,
Mail to Superuser, or None.
Destination The network printer’s unique access name. The
Destination access name can be either the name of
the printer or its IP address as defined in the
/etc/inet/hosts file or in a name service
database. The Destination access name is used only
by the print subsystem when it is making the
network connection to the physical printer or the
printer-host device. It becomes part of the printer
configuration database and is associated with the
network printer’s IP address.
Protocol For a network printer: The Internet protocol that is
used to communicate with the printer for file
transfer. The choices are Berkeley BSD Printer
Protocol and raw Transmission Control Protocol
(TCP). In general, the TCP protocol is more generic
across printers. The printer vendor documentation
supplies the information about the protocol to
select.
Options Identifies two options, the Default Printer option
and the Always Print Banner option, which, by
default, are disabled. To enable an option, click in
the appropriate box (a check mark appears).

Printer Tools

Required Field
User Access List Specifies print clients that can print to this printer.
By default, the word all allows every print client
access to this printer.
Default Printer Allows this printer to become the system default
that is used by all users who have not set their
own, preferred, default printer.
Always Print Sets whether or not a banner page is printed for
Banner each print job request.
Command Line Tools

The existing Solaris command line printing tools have been modified to
include a new -n option to the lpadmin command. With this option, you
can designate a PPD file to use when creating a new print queue or when
modifying an existing print queue.

Other Changes in Functionality

Changes have been made in directory and file structures, and also
through the addition of the Service Management Facility (SMF).
Directory and File Locations

The Solaris OS LP print service includes a directory structure, files, and
logs. The following section describes some of the key changes to this
structure.
The /usr/lib/lp/model Directory
This directory contains four default printer interface programs or shell

scripts, called the standard, standard_foomatic, netstandard, and the
netstandard_foomatic scripts.
The standard_foomatic, and netstandard_foomatic scripts are new

in Solaris 10, and support the new RIP and PPD functionality.
To view the contents of the foomatic directory, type the following

command:
# ls /usr/lib/lp/model/ppd/system/foomatic
Alps Citizen HP Lexmark Panasonic Sony
Anitech Compaq Heidelberg Minolta Pentax Star
Apollo DEC Hitachi Mitsubishi QMS Tally
Apple Dell IBM NEC Raven Tektronix
Avery Dymo Imagen Oce Ricoh Xerox
Brother Epson Infotec Okidata Samsung
CItoh Fujitsu Kodak Olivetti Seiko
Canon Generic Kyocera PCPI Sharp
The foomatic directory contains many subdirectories that are named

with a manufacturer.

Print Requests From the Network
The /usr/sbin/inetd Internet Service Daemon
The Internet services daemon, inetd, is a Service Management Facility

(SMF) restarter process for many network services. It is usually started up
by SMF at system boot time. The inetd service listens for requests for
network services which are currently enabled. The service which handles
incoming print requests from the network is
svc:/application/print/server:default.
To check the status of the print service, use the svcs -a command:
# svcs -a |grep ’print’
disabled 16:59:17 svc:/application/print/server:default
online 16:59:49 svc:/application/print/cleanup:default
offline 16:59:35 svc:/application/print/ipp-listener:default
offline 17:00:43 svc:/application/print/rfc1179:default
Use the svcadm command to enable or disable the service. Changes made
to the state of the service persist across reboots:
# svcadm enable svc:/application/print/server:default
# svcs -a | grep ’print/server’
online 19:01:09 svc:/application/print/server:default
When a request arrives, the inetd daemon executes the server program
that is associated with the service. Print servers listen for print requests
with the inetd daemon, and upon hearing a request, start up the in.lpd
daemon.

Internet Printing Protocol (IPP) Listener
The IPP listener for the Solaris OS listens for Hypertext Transfer Protocol
(HTTP) requests on port 631. The listener receives print client requests
and communicates those requests to the printing system.
After the print server has been configured, the IPP listening service
automatically starts:
# svcs ipp-listener
online 19:01:11 svc:/application/print/ipp-listener:default
A print client needs to know the print server name and the name of a
printer to print to. For example, on a Microsoft Windows system, a
network printer can be configured with the network path:
http://server-name:631/printers/printer-name.

Module 10
Describing Network Basics
Objectives
● Describe Network Interface Configuration Changes
● Describe Changes to the Client-Service Model
10-1
Objectives
Relevance

Network Basics have changed:
!
?
● What is different in changing a systems hostname?
● How do I start server processes now?


● System Administration Guide: IP Services, PN 816-4554-11
Describing Network Basics 10-3

Interface Configuration
The network interfaces that a system uses to communicate with other
systems on the network use both hardware and software configuration
components. When adding a network interface to a system, you must
configure specific files to establish a relationship between the hardware
and the software addresses.
Interface Files
You can get a basic understanding of network interfaces by learning the
function of a few files and services. Solaris 8 and 9 used the following files
for configuration and startup:
● The /etc/rcS.d/S30network.sh file
● The /etc/hostname.xxn file
● The /etc/inet/hosts file
● The /etc/inet/ipnodes file for IPv6 only
With Solaris 10, the function of the /etc/rcS.d/S30network.sh file

has been replaced by the SMF framework, and the /etc/inet/ipnodes
file now contains entries for IPV4 also. With Solaris 10, the services and
files are the following:
● The svc:/network/physical:default service
● The /etc/inet/ipnodes file
Note – The /etc/hostname.le0 file is no longer used since that

architecture was EOL’d with Solaris 10.

The /etc/hostname.xxn file can now be used to configure logical

interfaces without having to consult the /etc/networks file. For example,
the old method would be the following configuration:
# cat /etc/hostname.hme0
10.1.1.1
# cat /etc/hostname.hme0:1
10.1.1.2
# cat /etc/netmasks
10.0.0.0 255.255.255.0
Now, the entire configuration can be accomplished with editing the single
configuration file, for example:
# cat /etc/hostname.hme0
10.1.1.1 netmask 255.255.255.0 broadcast + up
addif 10.1.1.2 netmask 255.255.255.0 broadcast + up
The /etc/netmasks file does not need to be configured.
The svc:/network/physical:default Service
The svc:/network/physical:default service calls the

/lib/svc/method/net-physical method script. It is one of the
startup scripts that runs each time you boot the system. This script uses
the ifconfig utility to configure each interface with an IP address and
other required network information. The script searches for files called
hostname.xxn in the /etc directory, where xx is an interface type and n
is the instance of the interface. For every file named /etc/hostname.xxn,
the script uses the ifconfig command with the plumb option to make the
kernel ready to talk to this type of interface. The script then configures
the named interface using other options to the ifconfig command. The
/etc/hostname.hme0 file is an example of an interface configuration file.
The /etc/inet/ipnodes file
The ipnodes file is a local database that associates the names of nodes
with their Internet Protocol (IP) addresses. The ipnodes file can be used
in conjunction with, or instead of, other ipnodes databases, including the
Domain Name System (DNS), the NIS ipnodes map, and LDAP.
The ipnodes file has one entry for each IP address of each node, and can
contain either IPv4 or an IPv6 addresses.

If a node has more than one IP address, it will have one entry for each, on
consecutive lines. The format of each line is:
IP-address official-node-name nicknames...
Items are separated by any number of spaces or tab characters. The first
item on a line is the host’s IP address. The second entry is the host’s
official name. Subsequent entries on the same line are alternative names
for the same machine, or nicknames. Nicknames are optional.
# cat /etc/inet/ipnodes
#
# Internet host table
#
::1 localhost
127.0.0.1 localhost
192.168.30.68 sys68 loghost
IP addresses can be defined in the ipnodes file or in the hosts file. The
ipnodes file will be searched first, then the hosts file.

Changing the System Host Name

The host name of a system is contained in four files on the system. You
must modify all of these files, and perform a reboot, to successfully
change a system’s host name. The files that contain the host name of a
system are:
● The /etc/nodename file
● The /etc/inet/ipnodes file
Note – If crash dump is enabled on the system, the system name needs to
be changed under /var/crash.
Solaris 8 and 9 also had the hostname in files located under /etc/net in
the directories ticlts, ticots, and ticotsord which each contained a
hosts file.
Reviewing these files in Solaris 10 shows they no longer have any entries,
and contain a message that states they may be removed from a future
release of Solaris.
Note – The /etc/inet/ipnodes file contains IPV4 addresses, and is

consulted before the /etc/inet/hosts file on startup. If you edit the
hosts file by hand and forget to edit the ipnodes file, the system comes
up with the old IP address.
The sys-unconfig Command
You can use the /usr/sbin/sys-unconfig command to undo a system’s

configuration and restore it to an unconfigured state, ready to be
reconfigured again.
Solaris 10 added functionality to the sys-unconfig command by

regenerating keys for the Secure Shell Daemon (sshd).

Describing the Client-Server Model

The client-server model describes the communication process between
two computers or programs. The client system makes a service request to
the server system, then the server system fulfills the request. Although
programs can use the client-server model internally in a single computer,
the model is more widely used across a network. The client-server model
provides a way to distribute services efficiently across multiple locations
on a network.
To start services for server processes, you must know which files to use
for automatic service configuration. You must also know how to manually
start the services.
The Internet Service Daemon (inetd)
The inetd daemon is a special network process that runs on each system
and starts server processes that do not automatically start at boot time.
The inetd daemon is the server process for both the standard Internet
services and Sun Remote Procedure Call (Sun RPC) services. The inetd
daemon starts at boot time by svc.startd. There is a legacy
configuration file for inetd, /etc/inet/inetd.conf. Services listed in
this file are imported into the Service Management Facility (SMF) by the
inetconv command. Once the inetd.conf file has been converted, use
the inetadm command to alter the characteristics of an inet service.
Some services will allow you to change them with inetadm or svcadm,
such as the spray service.
Prior to Solaris 10, the /etc/inet/inetd.conf file contained many

entries; for example:
# cat /etc/inet/inetd.conf
.
.(output truncated)
# Echo, discard, daytime, and chargen are used primarily for testing.
#
echo stream tcp6 nowait root internal
echo dgram udp6 wait root internal
discard stream tcp6 nowait root internal
discard dgram udp6 wait root internal
daytime stream tcp6 nowait root internal
daytime dgram udp6 wait root internal
chargen stream tcp6 nowait root internal
chargen dgram udp6 wait root internal
#

Solstice system and network administration class agent server

100232/10 tli rpc/udp wait root /usr/sbin/sadmind sadmind
# METAD - SLVM metadb Daemon
100229/1 tli rpc/tcp wait root /usr/sbin/rpc.metad
rpc.metad
# METAMHD - SLVM HA Daemon
100230/1 tli rpc/tcp wait root /usr/sbin/rpc.metamhd
rpc.metamhd
# RLOGIND - rlogin daemon (BSD protocols)
login stream tcp6 nowait root /usr/sbin/in.rlogind
in.rlogind
# REXECD - rexec daemon (BSD protocols)
exec stream tcp nowait root /usr/sbin/in.rexecd in.rexecd
exec stream tcp6 nowait root /usr/sbin/in.rexecd in.rexecd
# FINGERD - finger daemon
finger stream tcp6 nowait nobody /usr/sbin/in.fingerd
in.fingerd
# RSTATD - rstat daemon
rstatd/2-4 tli rpc/datagram_v wait root
/usr/lib/netsvc/rstat/rpc.rstatd rpc.rstatd
.(output truncated)
When the inetd daemon received a network request, it ran the associated
command in the inetd.conf file. The previous example shows three
examples of remote services.
Now with Solaris 10, the /etc/inet/inetd.conf file is considered legacy,

and contains very few entries:
# cat /etc/inet/inetd.conf
#
.(output truncated)
#
100235/1 tli rpc/ticotsord wait root /usr/lib/fs/cachefs/cachefsd
cachefsd"
# TFTPD - tftp server (primarily used for booting)
#tftp dgram udp6 wait root /usr/sbin/in.tftpd in.tftpd
-s /tftpboot
# Sun ToolTalk Database Server
100083/1 tli rpc/tcp wait root /usr/dt/bin/rpc.ttdbserverd
rpc.ttdbserverd
# rpc.cmsd is a data base daemon which manages calendar data backed
# by files in /var/spool/calendar
100068/2-5 dgram rpc/udp wait root /usr/dt/bin/rpc.cmsd rpc.cmsd

The Impact of SMF on Network Services
The SMF has a major impact on network services in that each service can
be independently enabled or disabled using the inetadm command.
For example, consider the telnet facility:

# inetadm -l telnet
SCOPE NAME=VALUE
name="telnet"
proto="tcp6"
isrpc=FALSE
wait=FALSE
exec="/usr/sbin/in.telnetd"
user="root"
(output omitted)
The various parameters and values can be set using the inetadm
command. The values can then be stored in the appropriate SMF reference
files for each service. Changes can be maintained across system reboots.
To see whether or not the telnet facility is enabled, use the following
command:
# inetadm | grep telnet
To disable the telnet facility:

# inetadm -d telnet
disabled disabled svc:/network/telnet:default
To enable the telnet facility:

# inetadm -e telnet

To list the current state of all network facilities:

# inetadm
ENABLED STATE FMRI
enabled online svc:/network/rpc/gss:default
enabled online svc:/network/rpc/mdcomm:default
enabled online svc:/network/rpc/meta:default
enabled online svc:/network/rpc/metamed:default
enabled online svc:/network/rpc/metamh:default
disabled disabled svc:/network/rpc/rex:default
enabled online svc:/network/rpc/rstat:default
enabled online svc:/network/rpc/rusers:default
disabled disabled svc:/network/rpc/spray:default
disabled disabled svc:/network/rpc/wall:default
enabled online svc:/network/security/ktkt_warn:default
disabled disabled svc:/network/tname:default
enabled online svc:/network/nfs/rquota:default
disabled disabled svc:/network/chargen:dgram
disabled disabled svc:/network/chargen:stream
disabled disabled svc:/network/daytime:dgram
disabled disabled svc:/network/daytime:stream
disabled disabled svc:/network/discard:dgram
disabled disabled svc:/network/discard:stream
disabled disabled svc:/network/echo:dgram
disabled disabled svc:/network/echo:stream
disabled disabled svc:/network/time:dgram
disabled disabled svc:/network/time:stream
enabled online svc:/network/ftp:default
disabled disabled svc:/network/comsat:default
enabled online svc:/network/finger:default
disabled disabled svc:/network/login:eklogin
disabled disabled svc:/network/login:klogin
enabled online svc:/network/login:rlogin
disabled disabled svc:/network/rexec:default
enabled online svc:/network/shell:default
disabled disabled svc:/network/shell:kshell
disabled disabled svc:/network/talk:default
(output omitted)
Note – When a network service is affected, any related services are also
affected. By disabling one service, a number of other services may become
unavailable.

Module 11
Managing Crash Dumps, Core Files and

Paging
Objectives
● Describe the differences in the coreadm command from Solaris 9 to
Solaris 10
● Describe MPSS
11-1
Objectives
Relevance
Discussion – The following questions are relevant to understanding core

files:
!
?
● What changes have been made to core file generation?
● How much swap should be configured on a system?
This discussion question is added here to get the students to think about all of the recommendations and
best practices they have learned in the past about swap size. In actuality, with Solaris 10, a system can run
just fine without any swap configured.


● See the man pages for pagesize(1), mpss.so.1(1), ppgsz(1),
memcntl(2), mmap(2) and getpagesizes(3C).
The coreadm CommandWhen a process terminates

abnormally, it typically produces a core file. You can use the coreadm
command to specify the name or location of core files produced by
abnormally terminating processes.
Solaris 10 added new options to the coreadm command for global core file
content. You use the coreadm command without arguments to display the
current configuration. The following example shows the default output
from a system running Solaris 9:
# coreadm
1 global core file pattern:
2 global core file content: default
3 global core dumps: disabled
4 per-process core dumps: enabled
5 global setid core dumps: disabled
6 per-process setid core dumps: disabled
7 global core dump logging: disabled
The following example shows the default output from a system running
Solaris 10:
# coreadm
1 global core file pattern:
2 global core file content: default
3 init core file pattern: core
4 init core file content: default
5 global core dumps: disabled
6 per-process core dumps: enabled
7 global setid core dumps: disabled
8 per-process setid core dumps: disabled
9 global core dump logging: disabled
Managing Crash Dumps, Core Files and Paging 11-3

The description of the Solaris 10 output follows:
Note – The line numbers in the example are not part of the configuration.
They are part of the example only to assist with the following description
of the file.
Line 1 of the output identifies the name to use for core files placed in a
global directory.
Line 2 of the output identifies that the content of core files is the default
setting. The resultant core file contains all the process information
pertinent to debugging.
Line 3 of the output identifies the default name that per-process core files
must use. This name is set for the init process, meaning it is inherited by
all other processes on the system.
Line 4 of the output indicates that the init core file content is the default
content structure.
Line 5 indicates that global core files are disabled.
Line 6 indicates that core file generation in the current working directory
of a process is enabled.
Line 7 indicates that generation of global core files with setuid or setgid
permissions are disabled.
Line 8 indicates that generation of per process core files with setuid or
setgid permissions are disabled.
Line 9 identifies whether global core dump logging is enabled.
Caution – A process that has a setuid mode presents security issues with
respect to dumping core files. The files might contain sensitive
information in its address space to which the current non-privileged
owner of the process should not have access. Therefore, by default,
setuid core files are not generated because of this security issue.

By viewing the /etc/coreadm.conf file, you can verify the same

configuration parameters that were displayed with the coreadm
command.
# cat /etc/coreadm.conf
#
# coreadm.conf
#
# Parameters for system core file configuration.
# Do NOT edit this file by hand -- use coreadm(1) instead.
#
COREADM_GLOB_PATTERN=
COREADM_GLOB_CONTENT=default
COREADM_INIT_PATTERN=core
COREADM_INIT_CONTENT=default
COREADM_GLOB_ENABLED=no
COREADM_PROC_ENABLED=yes
COREADM_GLOB_SETID_ENABLED=no
COREADM_PROC_SETID_ENABLED=no
COREADM_GLOB_LOG_ENABLED=no

Changing the Core File Configuration

The coreadm command allows you to control core file generation
behavior. For example, you can use the coreadm command to configure a
system so that all process core files are placed in a single system directory.
The flexibility of this configuration makes it easier to track problems by
examining the core files in a specific directory whenever a process or
daemon terminates abnormally. This flexibility also makes it easy to locate
and remove core files on a system.
Note – You should make all modifications to the coreadm configuration at

the command line by using the coreadm command instead of editing the
/etc/coreadm.conf file.
You can enable or disable two configurable core file paths, per-process
and global, separately. If a global core file path is enabled and set to
/corefiles/core, for example, then each process that terminates
abnormally produces two core files: one in the current working directory,
and one in the /corefiles/core directory.
Note – If the directory defined in the global core file path does not exist,
you must create it.
Users can run the coreadm command with the -p option to specify the file
name pattern for the operating system to use when generating a
per-process core file.
coreadm [-p pattern] [pid]...
Only the root user can run the following coreadm command options to
configure system-wide core file options.
coreadm [-g pattern] [-i pattern] [-d option ... ] [-e option ... ]
‘‘The coreadm Command Options’’ on page 11-7 describes the core file
options.

The coreadm Command Options
The following are some options to the coreadm command.
Note – A regular user can only use the -p option, the superuser can use
all options.
-i pattern Sets the per-process core file name pattern from init to
pattern. This option is the same as the coreadm -p
pattern 1 command, except that the setting is
persistent after a reboot.
-e option Enables the specified core file option, where option is:
● global – Enables core dumps by using the global
core pattern.
● process – Enables core dumps by using the
per-process core pattern.
● global-setid – Enables setid core dumps by
using the global core pattern.
● proc-setid – Enables setid core dumps by using
the per-process core pattern.
● log – Generates a syslog (3) message when a user
attempts to generate a global core file.
-d option Disables the specified core file option; see the -e

option for descriptions of possible options. You can
specify multiple -e and -d options by using the
command line.
-u Updates system-wide core file options from the
contents of the configuration file /etc/coreadm.conf.
If the configuration file is missing or contains invalid
values, default values are substituted. Following the
update, the configuration file is resynchronized with
the system core file configuration.
-g pattern Sets the global core file name pattern to pattern. The
pattern must start with a forward slash (/), and can
contain any of the special embedded variables
described in Table 11-1 on page Module 11-8.

-p pattern Sets the per-process core file name pattern to pattern

for each of the specified process IDs (PIDs). The pattern
can contain any of the special embedded variables
described in Table 11-1 and does not have to begin with
a forward slash (/). If pattern does not begin with “/”,
it is evaluated relative to the current directory in effect
when the process generates a core file.
A non-privileged user can only apply the -p option to

processes owned by that user. The superuser can apply
the -p option to any process.
-G content Set the global core file content. You specify content by
using pattern options listed in Table 11-1. (new is
Solaris 10)
A core file named pattern is a file system path name with embedded
variables. The embedded variables are specified with a leading percent (%)
character. The operating system expands these variables from values in
effect when the operating system generates a core file. The possible
variables are listed in Table 11-2.
Table 11-1 Pattern Options for the coreadm Command
Option Meaning
%p PID
%u Effective user ID (EUID)
%g Effective group ID (EGID)
%f Executable file name
%n System node name (uname -n)
%m Machine hardware name (uname -m)
%t The time in seconds since midnight January 1, 1970
%d Executable file directory/name (new is Solaris 10)
%z Zonename (new is Solaris 10)
%% Literal %

Table 11-2 shows the pattern options for the global core file content.
Table 11-2 Pattern Options for the Global Core File Content
Option Meaning
anon Anonymous private mappings, including thread stacks

that are not main thread stacks
ctf CTF type information sections for loaded object files
data Writable private file mappings
dism DISM mappings
heap Process heap
ism ISM mappings
rodata Read-only private file mappings
shanon Anonymous shared mappings
shfile Shared mappings that are backed by files
shm System V shared memory
stack Process stack
symtab Symbol table sections for loaded object
text Readable and executable private file mappings

Examples of the coreadm Command
Example 1 – Setting the Core File Name Pattern as a Regular User
When executed from a user’s $HOME/.profile or $HOME/.login file, the

following entry sets the core file name pattern for all processes run during
the login session:
coreadm -p core.%f.%p $$
Note – The $$ variable is the PID of the currently running shell. The
per-process core file name pattern is inherited by all child processes.
Example 2 – Dumping a User’s Core Files Into a Subdirectory
The following command places all of the user’s core files into the
corefiles subdirectory of the user’s home directory, differentiated by
the system node name. This example is useful for users who use many
different systems, but share a single home directory across multiple
systems.
$ coreadm -p $HOME/corefiles/%n.%f.%p $$
Example 3 – Enabling and Setting the Core File Global Name Pattern
The following is an example of setting system-wide parameters that add

the executable file name and PID to the name of any core file that is
created:
# coreadm -g /var/core/core.%f.%p -e global
For example, the core file name pattern /var/core/core.%f.%p causes

the xyz program with PID 1234 to generate the core file
/var/core/core.xyz.1234.
Note – In the above coreadm examples, the corefiles file and the core
directory must be created manually. The coreadm command does not
create them automatically.

To verify that this parameter is now part of the core file configuration, run
the coreadm command again:
# coreadm
globalcore file pattern: /var/core/core.%f.%p
globalcore file content: default
initcore file pattern: core
initcore file content: default
global core dumps: enabled
per-process core dumps: enabled
global setid core dumps: disabled
per-process setid core dumps: disabled
global core dump logging: disabled
Example 4 – Checking the Core File Configuration for Specific PIDs
Running the coreadm command with a list of PIDs reports each process’s
per-process core file name pattern, for example:
# coreadm 228 507
228: core default
507: /usr/local/swap/corefiles/%n.%f.%p default
Only the owner of a process or the superuser can query a process by using
the coreadm command with a list of PIDs.
Example 5 – Setting up the System to Produce Core Files in the Global

Repository only if the executables were run from /usr/bin or
/usr/sbin
# mkdir -p /var/core/usr/bin
# mkdir -p /var/core/usr/sbin
# coreadm -G all -g /var/core/%d/%f %p %n
When using the all option in the previous command, examples of the
core file content include:
anon = anonymous private maps
data = writable private file mapping
stack = process stack
symtab = symbol table sections for loaded object files

Paging
Paging
Paging is the transfer of selected memory pages between RAM and the
swap areas. When you page private data to swap spaces, physical RAM is
made available for other processes to use. If you need the pages that were
paged out, you can retrieve them (page them in) from swap and map
them back into physical memory. Moving these pages back into RAM
might require more paging (page outs) of other process’s pages to make
room. Swapping is the movement of all modified data memory pages
associated with a process, between RAM and a disk.
Multiple Page Size Support (MPSS)

Solaris 9 introduced MPSS, which allows a program to use any hardware
supported page size to access portions of virtual memory. Previously
only 8K pages were available for a program’s stack, heap or mmap’d
anonymous memory. This is of use by application developers more than
by system administrators. It allows the programmer to select the size of
virtual memory pages to be paged in and out, which can effect the
performance of some applications. In some cases, paging in more than 8K
at a time might make an application a faster performer.
Use the pagesize command to display the size of a memory page in

bytes. The default page size for the Solaris 10 OS is 8192 bytes.
# pagesize
8192
Use the pagesize command to display all supported page sizes.

# pagesize -a
8192
65536
524288
4194304
Swapping does not typically occur in the Solaris OS. The required amount
of swap space varies from system to system. The amount of available
swap space must satisfy two criteria:
● It must be sufficient to supplement physical RAM to meet the needs
of concurrently running processes
● It must be sufficient to hold a crash dump (in a single slice)

Module 12
Configuring NFS
Objectives
● Describe the differences in the Network File System in Solaris 8, 9,
and 10
● Describe the enhancements to Network File System version 4 (NFS
version 4)
12-1
Objectives
Relevance
Discussion – The following questions are relevant to understanding the

changes in NFS
!
?
● What are the differences between NFSv3 and NFSv4?
● What are the configuration changes and implications for NFS?


● System Administration Guide: Network Services
● Center for Information Technology Integration
http://www.citi.umich.edu/projects/nfsv4/
● http://www.nfsv4.org/
Configuring NFS 12-3

NFSv4 (New With Solaris 10)

NFS version 4 is a distributed file access protocol which owes its heritage
to NFS protocol version 2, Request For Comment (RFC) 1094, and version
3, RFC 1813. Unlike earlier versions, the NFS version 4 protocol supports
traditional file access while integrating support for the mount protocol. In
addition, support for strong security (and its negotiation), compound
operations, client caching, and internationalization have been added and
NFS version 4 operates well in an Internet environment.
The Solaris 10 OS supports versions 2, 3, and 4 NFS simultaneously. The

default is to use NFSv4 software when sharing a directory or accessing a
shared file. Version-related checks are applied whenever a client host
attempts to access a server’s file share. If all hosts in the network are
installed with Solaris 10 OS, then all hosts should, by default, use the
NFSv4 protocols.
NFSv4 includes features that were not in the previous versions of NFS.
These features include the following:
● Stateful connections, and single protocol, reducing the number of
service-side daemons.
NFS version 4 is stateful, and there are OPEN and CLOSE operations to
obtain file data access. Functions previously handled by separate
protocols (for example, MOUNTD, STATD, LOCKD) are incorporated into
one protocol.
NFS version 4 handles file handle-to-path name mapping. This
removes the need for a separate mountd daemon on the server,
therefore reducing server-side support daemons and easing server-
side implementation.
● Improved Firewall Support. NFSv4 uses the well-known port
number 2049.
● Pseudo file systems which ensure the NFS client has seamless access
to all exported objects on the server and that portions of a server file
system that are not explicitly exported are not visible to the client.
● Strong security.
● Extended attributes.
● Delegation. In the Solaris 10 NFSv4 release, the NFS server can hand
over delegation of management of a shared file to the client
requesting that file. It is the server that decides whether or not to
apply delegation. By delegating read or write management control to

the client, this can greatly reduce the amount of network traffic that
would otherwise be caused by clients making requests of the server
for the current state of a shared file.
Pseudo-File System
Previous versions of NFS required use of the mount protocol, which does
not use assigned ports. This made NFS hard to use through a firewall.
Implementation of NFS version 4 must support Transmission Control
Protocol/Internet Protocol (TCP/IP) to provide congestion control. NFS
version 4 uses the well-known port 2049, thus improving firewall
support.
NFS version 4 maps file handles to path names, which the mountd
protocol did in previous versions of NFS. In NFS version 4, the server
provides a root file handle that represents the top of the file system that
the server exported. The server attaches multiple file systems with a
pseudo-file system. The pseudo-file system provides paths that bridge
non-exported portions of the real file system.
NFS version 4 servers create and maintain a pseudo-file system, which

provides clients with seamless access to all exported objects on the server.
Before NFS version 4, the pseudo-file system did not exist. Clients had to
mount each shared server file system for access.

Figure 12-1 shows an example of server and client file systems:
Server exports: Server file systems: Exported directories

/export_fs/local /
/export_fs/projects/nfs4 /export_fs
Server file systems: Client view of server’s export_fs dir:
export_fs export_fs
local projects payroll local projects
nfs4x nfs4 nfs4

Figure 12-1 Views of the Server File System and Client File System
In Figure 12-1 the client cannot see the payroll directory and the nfs4x
directory because these directories are not exported and do not lead to
exported directories. However, the client can see the local directory
because local is an exported directory. The projects directory is visible
to the client because the projects directory leads to the exported
directory, nfs4. Thus, portions of the server namespace that are not
explicitly exported are bridged with a pseudo-file system that views only
the exported directories and those directories that lead to server exports.
A pseudo-file system is a structure that contains only directories and is

created by the server. The pseudo-file system permits a client to browse
the hierarchy of exported file systems. Thus, the client's view of the
pseudo-file system is limited to paths that lead to exported file systems.

Previous versions of NFS did not permit a client to traverse server file
systems without mounting each file system. However, in NFS version 4,
the server namespace does the following:
● Restricts the client's file-system view to directories that lead to server
exports.
● Provides clients with seamless access to server exports without
requiring that the client mount each underlying file system. See the
previous example in Figure 12-1. However, different operating
systems (OSs) might require the client to mount each server
file system.
NFS version 4 is the default NFS version on Solaris 10 OS. The nfs(4) file
in the /etc/default directory configures the client or server to use NFS
versions 2, 3, or 4. In addition, the mount command (mount_nfs (1M))
can use the vers=version_number option to mount a file system using
only the version specified.
Strong Security
NFS version 4 uses the remote procedure call (RPC) implementation of

the General Security Service (GSS) framework to extend the basic security
of RPC. This provides mechanisms for authentication, integrity, and
privacy between the client and server.
Traditional RPC implementations included AUTH_NONE, AUTH_SYS,

AUTH_DH, and AUTH_KRB4 as security flavors. An additional security
method of RPCSEC_GSS is introduced that uses the functionality of
Generic Security Services Application Programming Interface (GSSAPI).
This allows the RPC layer to use various security mechanisms without the
additional implementation overhead of adding RPC security methods.
For NFS version 4, the RPCSEC_GSS security method must be used to

enable the mandatory security mechanism. Other flavors, such as
AUTH_NONE, AUTH_SYS, and AUTH_DH may be implemented as well.
The client negotiates with the server to determine the security mechanism
that meets the requirements for the server and client. The RPCSEC_GSS
framework delivers Sun Enterprise Authentication Mechanism™ (SEAM)
software authentication.
You can mix the security mechanisms on a single server, which allows
security to be applied on a per-share basis.

To configure a Solaris 10 OS NFS version 4 server to use the RPCSEC_GSS

security flavor with SEAM software, the administrator first edits the
/etc/nfssec.conf file using the nfssec security modes described in the
nfssec(5) man page to enable the necessary security mode needed and
then shares the file system with the sec=mode option.
The following is an example:

# share -F nfs -o sec=krb5 /export/home
Compound Procedures
To improve performance and Internet access, the NFS version 4 client

combines multiple RPC request calls into a single compound procedure.
By using compound procedures, clients can combine LOOKUP, OPEN, and
READ operations in a single request. The server breaks the request into a
list of separate requests. The server iterates through the list and performs
each operation in the list until it reaches the end of the list or fails. The
server then returns the results of the operations to the client.
The following is a simplified example of compound procedures. When

reading the /export/testdata file, NFS versions 3 and 4 generate the
following RPC calls:
NFS version 3 NFS version 4
-> LOOKUP "export" ->OPEN "export/testdata"

<- OK READ
->LOOKUP "testdata" <- OPEN OK
<- OK READ OK
-> ACCESS "testdata" (sends data)
<- OK
-> READ "testdata"
<- OK
(sends data)
Fewer RPC calls result in faster NFS response. This allows the client to
tailor its request to appropriately match the operating environment of the
client, thus enhancing cross-platform interoperability.

Extended Attributes
Earlier NFS versions used a fixed set of file and file system attributes that
were modeled on the UNIX® type files and file systems. A non-UNIX-like
server or client had to simulate those attributes, making implementation
on a non-UNIX system difficult. NFS version 4 introduces three categories
of attributes: mandatory, recommended, and named. All NFS version 4
clients and servers supported the mandatory attributes to ensure a
minimum level of interoperability.
Not all clients or servers have to support the recommended attributes.

This allows a server to support the attributes that apply to its operating
environment. The client determines how to proceed if the server does not
support a particular recommended attribute.
The named attribute is in the form of a byte stream that is associated with
a file or file system and is referred to by a string name. This allows the
client to associate data with a specific file or file system.
File handles are created on the server and contain information that
uniquely identifies files and directories. In NFS versions 2 and 3, the
server returned persistent file handles. This meant the client could
guarantee that the server would generate a file handle that always
referred to the same file. The following is an example:
● If a file was deleted and replaced with a file of the same name, the
server would generate a new file handle for the new file. If the client
used the old file handle, the server would return an error that the file
handle was stale.
● If a file was renamed, the file handle would remain the same.
● If you had to reboot the server, the file handles would remain the
same.
When the server received a request from a client that included a file
handle, the resolution was straightforward, and the file handle always
referred to the correct file.
This method of identifying files and directories for NFS operations was
fine for most UNIX-based servers, but could not be implemented on
servers that relied on other methods of identification such as a file's path
name. To resolve this problem, the NFS version 4 protocol permits a
server to declare that its file handles are volatile. Thus, a file handle could
change. If the file handle does change, the client must find the new file
handle.

Like NFS versions 2 and 3, the Solaris OS NFS version 4 server always
provides persistent file handles. However, Solaris OS NFS version 4
clients that access non-Solaris OS NFS version 4 servers must support
volatile file handles if the server uses them. Specifically, when the server
tells the client that the file handle is volatile, the client must cache the
mapping between path name and file handle. The client uses the volatile
file handle until it expires. Upon expiration, the client does the following:
● Flushes the cached information that refers to that file handle
● Searches for that file's new file handle
● Retries the operation
UTF-8
File and directory names are UTF-8 encoded. This encoding includes 16 or
32 bit characters and allows one superset to handle all character sets. This
allows the client and the server to be unaware of each other's localization
and supports internationalization.
A UTF-8 string represents the owner and owner_group attributes (and

also users and groups within the ACL attribute). This avoids presentation
that is tied to a particular underlying implementation at the client or
server. The client and server have their own local representation of owner
and owner_group that is used for local storage or presentation to the end
user. When these attributes are transferred between the client and server,
the local representation is translated to a syntax of the form
user@dns_domain. For a client and server that do not use the same local
representation, this allows translation to a common syntax that both can
interpret.
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 id
from the client to nobody. Administrators should avoid making special
accounts that exist only on a client.
Although the server and the client perform both integer-to-string

conversions and string-to-integer conversions, a difference exists. 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. While
nfsmapid has no external customer-accessible interfaces, the domain used
can be configured by using the NFSMAPID_DOMAIN parameter in the nfs(4)
configuration file.
Delegation
NFS version 4 provides both client support and server support for
delegation. Delegation is a technique by which the server delegates the
management of a file to a client. For example, the server could grant either
a read delegation or a write delegation to a client. You can grant read
delegations to multiple clients at the same time, because these read
delegations do not conflict with each other. A write delegation can be to
only one client, because a write delegation conflicts with any file accessed
by any other client. While holding a write delegation, the client would not
send various operations to the server because the client is guaranteed
exclusive access to a file. Similarly, the client would not send various
operations to the server while holding a read delegation because the
server guarantees that no client can open the file in write mode.
The server alone decides whether to grant a delegation. A client does not
request a delegation. The server decides based on the access patterns for
the file. If several clients recently accessed a file in write mode, the server
might not grant a delegation because this access pattern indicates the
potential for future conflicts.

A conflict occurs when a client accesses a file in a manner that is

inconsistent with the delegations that are currently granted for that file.
For example, if a client holds a write delegation on a file and a second
client opens that file for read or write access, the server recalls the first
client's write delegation. Similarly, if a client holds a read delegation and
another client opens the same file for writing, the server recalls the read
delegation.
Note that in both situations, the second client is not granted a delegation
because a conflict now exists. When a conflict occurs, the server uses a
callback mechanism to contact the client that currently holds the
delegation. Upon receiving this callback, the client sends the file's
updated state to the server and returns the delegation. If the client fails to
respond to the recall, the server revokes the delegation. In such instances,
the server rejects all operations from the client for this file, and the client
reports the requested operations as failures. Generally, these failures are
reported to the application as input/output (I/O) errors. To recover from
these errors, the file must be closed and then reopened.
One server does not resolve access conflicts for a file that is stored on
another server. Thus, an NFS server resolves only conflicts for files that it
stores. Furthermore, in response to conflicts that are caused by clients that
are running various versions of NFS, an NFS server can initiate only
recalls to the client that is running NFS version 4. An NFS server cannot
initiate recalls for clients that are running earlier versions of NFS.
The process for detecting conflicts varies. For example, unlike NFS
version 4, because version 2 and version 3 do not have an open procedure,
the conflict is detected only after the client attempts to read, write, or lock
a file. The server's response to these conflicts varies also. The following
are sample responses:
● For NFS version 3, the server returns the JUKEBOX error, which
causes the client to halt the access request and retry later. The client
prints the message: File unavailable.
● For NFS version 2, because an equivalent of the JUKEBOX error does
not exist, the server makes no response, which causes the client to
wait and then retry. The client prints the message NFS server not
responding. Note that these conditions clear when the delegation
conflict is resolved.
Note – By default, server delegation is enabled when NFS version 4 is

started.

The NFS version 4 callback daemon, nfs4cbd (1M), provides the callback
service on the client. This daemon is started automatically whenever a
mount for NFS version 4 is enabled. By default, the client provides the
necessary callback information to the server for all Internet transports that
are listed in the /etc/netconfig system file. If the client is enabled for
Internet Protocol version 6 (IPv6) and if the IPv6 address for the client's
name can be determined, then the callback daemon accepts IPv6
connections.
The callback daemon uses a transient program number and a dynamically

assigned port number. This information is provided to the server, and the
server tests the callback path before granting any delegations. If the
callback path fails, the server does not grant delegations, which is the only
externally visible behavior.
Because callback information is embedded within an NFS version 4

request, the server cannot contact the client through a device that uses
Network Address Translation (NAT). Also, the callback daemon uses a
dynamic port number. Therefore, the server might not be able to traverse
a firewall, even if that firewall enables normal NFS traffic on port 2049. In
such situations, the server does not grant delegations.

The /etc/default/nfs file

When configuring NFS, the first step is to add the appropriate entries in
the /etc/default/nfs file. This file allows NFS to be configured without
making changes to the service management facility scripts.
Server Configuration
You must log in as superuser or assume an equivalent role to edit the file.
1. Edit the /etc/default/nfs file.
2. Make the following entries to configure an NFS version 4 only
server:
NFS_SERVER_VERSMAX=4
NFS_SERVER_VERSMIN=4
While numerous parameters are supported, only those used to
configure the NFS version 4 server are considered here.
See the nfs(4) man page for a complete list of possible parameters.
NFS_SERVER_VERSMIN=num
NFS_SERVER_VERSMAX=num
The NFS server uses only NFS versions in the range these variables
specify. Valid values or versions are: 2, 3, and 4. By default these
variables are unspecified (commented out) and the client's default
minimum is Version 2. The default maximum is Version 4.
3. If required, make the following entry:
NFS_SERVER_DELEGATION=off
By default, this variable is commented out and the NFS server does
provide delegations to clients. The user can turn off delegations for
all exported file systems by setting this variable to off (case
sensitive). This variable applies only to NFS version 4.
4. If required, make the following entry:
NFSMAPID_DOMAIN=my.comany.com
By default, the nfsmapid daemon uses the Domain Name Service
(DNS) domain of the system. This setting overrides the default. This
domain is used for identifying user and group attribute strings in the
NFS version 4 protocol. Clients and servers must match with this
domain for operation to proceed normally. This variable applies only
to NFS version 4.

Client Configuration
You must login as superuser or assume an equivalent role to edit the file.
1. Edit the /etc/default/nfs file.
2. Insert the following lines to configure a NFS version 4 only client:
NFS_CLIENT_VERSMAX=4
NFS_CLIENT_VERSMIN=4
While numerous parameters are supported, only those used to
configure the NFS version 4 client are considered here.
See the nfs(4) man page for a complete list of possible parameters.
The NFS client only uses NFS versions in the range specified by
these variables. Valid values or versions are: 2, 3, and 4. By default
these variables are unspecified (commented out) and the client's
default minimum is Version 2. The default maximum is Version 4.
3. Mount a file system.
# mount server_name:share_point local_dir
● server_name – Provides the name of the server
● share_point – Provides the path of the remote directory to be
shared
● local_dir – Provides the path of the local mount point

SMF Effects on NFS

As with other processes, control has been switched from rc scripts to
SMF.
The /etc/dfs/dfstab File
The /etc/dfs/dfstab file contains the commands that share local

directories. Each line of the dfstab file consists of a share command. The
following example shows the Solaris 10 version of the dfstab file, with
it’s commented message about starting processes highlighted.
# cat /etc/dfs/dfstab
# Place share(1M) commands here for automatic execution
# on entering init state 3.
#
# Issue the command ’svcadm enable network/nfs/server’ to
# run the NFS daemon processes and the share commands, after adding
# the very first entry to this file.
#
# share [-F fstype] [ -o options] [-d "<text>"] <pathname> [resource]
# .e.g,
# share -F nfs -o rw=engineering -d "home dirs" /export/home2
share -F nfs -o ro -d "Shared data files" /usr/local/data

share -F nfs -o rw,root=sys-01 -d "Database files" /rdbms_files
Note – If the svc:/network/nfs/server service does not find any

share commands in the /etc/dfs/dfstab file, it does not start the NFS
server daemons.
The contents of the /etc/dfs/dfstab file are read when:

● The system enters the multi-user-server milestone.
● The superuser runs the shareall command.
● The superuser enables the svc:/network/nfs/server service.

Managing the NFS Daemons
Two NFS daemons, the statd daemon and the lockd daemon, run both
on the NFS servers and the NFS clients. These daemons start
automatically when a system enters the network milestone. This can be
seen by examining the dependencies for the network milestone.
# svcs -D milestone/network
STATE STIME FMRI
disabled 15:34:35 svc:/network/dns/client:default
disabled 15:34:37 svc:/network/nfs/cbd:default
disabled 15:34:38 svc:/network/rpc/bootparams:default
disabled 15:34:39 svc:/network/rarp:default
disabled 15:34:51 svc:/network/dns/server:default
disabled 15:34:52 svc:/network/slp:default
disabled 15:35:20 svc:/network/shell:kshell
online 15:35:03 svc:/milestone/single-user:default
online 15:35:13 svc:/network/inetd:default
online 15:35:24 svc:/network/nfs/client:default
online 15:35:26 svc:/network/shell:default
online 15:35:30 svc:/network/nfs/server:default
online 15:35:31 svc:/network/nfs/mapid:default
online 16:31:18 svc:/network/nfs/nlockmgr:default
online 16:33:12 svc:/network/nfs/status:default
Both the statd and lockd daemons provide crash recovery and locking
services for NFS version 2 and 3. If a server crashes, clients can quickly re-
establish connections with files they were using. Therefore, the server has
a record of the clients that were using its NFS resources. It contacts each
client for information about which files were in use, which helps to
provide continuous operation. You can start both of these daemons using
the svcadm command.
The lockd daemon is started by the SMF service nfs/nlockmgr.

# svcadm -v enable nfs/nlockmgr
svc:/network/nfs/nlockmgr:default enabled.
The statd daemon is started by the SMF service nfs/status.

# svcadm -v enable nfs/status
svc:/network/nfs/status:default enabled.
Neither daemon requires administrative intervention.

Restarting the NFS Client Daemons
The service management facility automatically starts the NFS client

daemons when the system enters the network milestone, and shuts down
NFS client daemons when the system enters the single-user milestone.
To manually restart these daemons, perform the command:

# svcadm -v restart nfs/status
Action restart set for svc:/network/nfs/status:default.
# svcadm -v restart nfs/nlockmgr
Action restart set for svc:/network/nfs/nlockmgr:default.
#

NFS Server and Client Daemon Recap

Table 12-1 lists the NFS server daemons.
Table 12-1 NFS Server Daemons
Daemon Description NFSv4
mountd Handles file system mount requests from remote No

systems, and provides access control.
nfsd Handles client file system requests. Yes
statd Works with the lockd daemon to provide crash No
recovery functions for the lock manager.
lockd Supports record locking operations on NFS files. No
nfslogd Provides operational logging for NFSv2 and 3. No

nfsmapid NFS user and group ID mapping daemon (new in Yes
S10)
Table 12-2 lists the NFS client daemons.
Table 12-2 NFS Client Daemons
Daemon Description
statd Works with the lockd daemon to provide crash

recovery functions for the lock manager
lockd Supports record-locking operations on NFS files
nfs4cbd NFSv4 callback daemon. (new in S10)

Displaying NFS Mounted Resources

The dfmounts command displays remotely mounted NFS resource
information.
dfmounts [ -F nfs ] [ server ]
The dfmounts command, when used without arguments, displays a list of

directories on the local server that are currently mounted and also
displays a list of the client systems that currently have the shared resource
mounted.
# dfmounts
RESOURCE SERVER PATHNAME CLIENTS
- sys-02 /usr/local/data sys-03
Note – Since the dfmounts command uses the mountd daemon to display
currently shared NFS resources, it will not display NFS version 4 shares.
NFS Server Logging

The NFS server logging feature records NFS transactions on the file
system. The nfslogd daemon provides operational logging.
Note – Server logging is not supported in NFS version 4.

Module 13
Configuring AutoFS
Objectives
Upon completion of this module, you should be able to describe new map
entries with AutoFS.
13-1
Objectives
Relevance
Discussion – The following questions are relevant to discussing AutoFS:

! ● What changes have been made to AutoFS maps?
?


● System Administration Guide: Network Services
Configuring AutoFS 13-3

Special Mountings
Special Mountings
The /etc/auto_master file contains mount points for special maps. In
Solaris 9, the xfn map provided access to resources available through the
Federated Naming Service (FNS). Resources associated with FNS were
mounted below the /xfn directory. Support for FNS was dropped in
Solaris 10. Examples of the /etc/auto_master files from both releases are
shown below:
From a Solaris 10 system:

# cat /etc/auto_master
#
#
# ident "@(#)auto_master 1.8 03/04/28 SMI"
#
# Master map for automounter
#
+auto_master
/net -hosts -nosuid,nobrowse
/home auto_home -nobrowse
From a Solaris 9 system:

# cat /etc/auto_master
# Master map for automounter
#
+auto_master
/net -hosts -nosuid,nobrowse
/home auto_home -nobrowse
/xfn -xfn

Special Mountings
New AutoFS Configuration File

The Solaris 10 3/05 release introduced a new configuration file,
/etc/default/autofs, which provides an additional way to configure
your autofs commands and autofs daemons.
Now, the same specifications that you would make on the command line
can be made in this new configuration file. However, unlike the
specifications you would make on the command line, this file preserves
your specifications, even during upgrades to your operating system.
Additionally, you no longer are required to update critical startup files to

ensure that the existing behavior of your autofs environment is preserved.
You can make your specifications by using the following keywords:
AUTOMOUNTD_ENV permits you to assign different values to different

environments. This keyword is the equivalent of the -D argument for
automountd.
AUTOMOUNTD_NOBROWSE turns browsing on, or turns browsing off,

for all autofs mount points. This command is the equivalent of the -n
argument for automountd.
AUTOMOUNTD_TRACE expands each remote procedure call (RPC) and

displays the expanded RPC on standard output. This keyword is the
equivalent of the -T argument for automountd.
AUTOMOUNTD_VERBOSE logs status messages to the console and is

the equivalent of the -v argument for the automountd daemon.
AUTOMOUNT_TIMEOUT sets the duration for a file system to remain

idle before the file system is unmounted. This keyword is the equivalent
of the -t argument for the automount command.
AUTOMOUNT_VERBOSE provides notification of autofs mounts,

unmounts, and other nonessential events. This keyword is the equivalent
of the -v argument for automount.
For more information, refer to the automount(1M) and the

automountd(1M) man pages.
Configuring AutoFS 13-5

Module 14
Configuring Solaris Volume Manager

Software
Objectives
The Solaris Volume Manager software provides commands and a
graphical user interface (GUI) tool to configure physical slices of disks
into logical volumes.

● Describe Solaris Volume Manager software concepts
● Build a RAID-0 (concatenated) volume
● Build a RAID-1 (mirror) volume for the root (/) file system
14-1
Objectives
Relevance

Solaris Volume Manager in the Solaris 10 OS:
!
?
● What are the key features of SVM?
● How does SVM compare to VxVM?


● Solaris Volume Manager Administration ES-222 Revision: B
● Solaris Volume Manager Administration Guide, PN 816-4520
Configuring Solaris Volume Manager Software 14-3

Solaris Volume Manager Concepts
Solaris Volume Manager Concepts

The Solaris Volume Manager software in the Solaris 9 and 10 Operating
System replaces the Solstice DiskSuite software used in releases of the
Solaris OS prior to Solaris 9 OS.
The Solaris Volume Manager software is used to implement RAID 0,

RAID 1, RAID 1+0, and RAID 5.
This module covers the configuration of the following:

● RAID 0: Non-redundant disk array (concatenation and striping)
● RAID 1: Mirrored disk array
in Solaris 8, the Solstice Disksuite product was used, with an emphasis

placed on the metatool (GUI) interface. Solaris 9 introduced the Solaris
Volume Manager software, which was essentially the next generation of
the Solstice Disksuite. The SVM GUI is launched from the SMC Console
via the Enhanced Storage tool.
The soft partition feature of the Solaris Volume Manager software enables
administrators to divide a large partition or an existing volume into
smaller areas or extents.
Soft partitioning was introduced in a patch to Solaris 8, and is Sun’s

answer to vxvm’s public region. Prior to soft partitioning using standard
partition based sds/svm you were limited to only being able to logically
divide a disk/lun into 7 partitions/slices. This was always perceived as a
limiting factor compared to vxvm. With soft partitioning you can have an
unlimited amount of them from your available space.
You can create multiple soft partitions on a single hard partition and use
them directly to create small file systems. Using soft partitions directly is
simple, but does not provide data protection.

The State Database Replicas

The state database stores information on disk about the state of your
Solaris Volume Manager software configuration. Multiple copies of the
database, called replicas, provide redundancy and protect against data
loss if a copy of the database is corrupted due to the system crashing or
other failure. The state database replicas should be distributed across
multiple disks so that failure of a single disk only causes the loss of a
single state database replica.
If the system loses a state database replica, Solaris Volume Manager

software uses a majority consensus algorithm to determine which state
database replicas still contain valid data. The algorithm requires that a
majority (half +1) of the state database replicas are available before any of
them are considered valid. The majority consensus algorithm requires that
you create at least three state database replicas before you build or
commit any metadevices. To reach a consensus, at least two of the three
replicas must be available.
The majority consensus algorithm:

● Makes sure that the system stays running if at least half of the state
database replicas are available.
● Causes the system to panic if fewer than half of the state database
replicas are available.
● Prevents the system from starting the Solaris Volume Manager
software unless a majority of the total number of state database
replicas are available.
If insufficient state database replicas are available, you must boot into
single-user mode and delete enough of the corrupt replicas to achieve a
majority consensus.
State database replicas are stored in their own disk slices.
Caution – If you upgrade from Solstice DiskSuite to Solaris Volume

Manager software and have state database replicas at the beginning of
slices (as opposed to on separate slices), do not delete existing replicas
and replace them with new ones in the same location. The default Solaris
Volume Manager software state database replica size is 8192 blocks, while
the default size in Solstice DiskSuite was 1034 blocks. If you delete a
default-size state database replica from Solstice DiskSuite, and add a new

default-size replica with the Solaris Volume Manager software, you will
overwrite the first 7158 blocks of any file system occupying the rest of the
shared slice, which destroys the data.
Creating the State Database

You can create state database replicas by using:
● The metadb -a command
● The Solaris Volume Manager software GUI
Creating the State Database Using the Command Line
To create state database replicas using the command line, use the metadb
command. The syntax of the command is:
metadb -a [-f] [-c n] [-l nnnn] disk_slice
where:
-a Adds a state database replica.

-f Forces the operation, even if no replicas exist. Use
this flag to force the creation of the initial replicas.
-c n Specifies the number of replicas to add to the slice.
-l nnnn Specifies the size of the new replicas, in blocks.
disk_slice Specifies the name of the disk_slice that will
hold the replica.
Note – The metadb command without options reports the status of all
replicas.

The following example shows the creation of state database replicas:

# metadb -a -f c0t0d0s4 c0t0d0s5 c1t0d0s0 c1t0d0s1
# metadb
flags first blk block count
a u 16 8192 /dev/dsk/c0t0d0s4
This example lists the four replicas that were just created. Each replica
begins at block 16 of the assigned disk slice. Each replica is 8192 blocks, or
4 Mbytes in size. The flags indicate that the replica is active and up to
date. If there are capital letters in the flags field, it is an indication that the
replica is corrupt.
Note – The previous example places the state database replicas on disks
on different controllers. This is an appropriate fault tolerant configuration
for a production environment.

Creating the State Database Using the Solaris Management

Console
The Enhanced Storage Tool within the Solaris Management Console

provides a GUI that guides you through Solaris Volume Manager tasks.
Complete the following steps to create the state database replicas:

1. To start the Solaris Management Console, perform the command:
# smc &
The Solaris Management Console appears, as shown in Figure 14-1.
Figure 14-1 Solaris Management Console Welcome Screen
2. Use the Navigation pane to traverse the Solaris Management

Console structure until you reach the Enhanced Storage Tool.
3. Click This Computer.
4. Select Storage.

5. Click Enhanced Storage, as shown in Figure 14-2, to display the

contents of the Enhanced Storage Tool.
Figure 14-2 Solaris Management Console: Storage Tool
Note – After you start the Solaris Management Console, you must log in
after you open the first tool.
6. Click the State Database Replica icon.

If the state database currently contains replicas, these replicas appear

in the View pane. If no state database replicas exist, the View pane is
empty, as shown in Figure 14-3.
Figure 14-3 Solaris Management Console: View Pane

7. To create a replica, select Create Replicas from the Action menu, as

shown in Figure 14-4, and follow the instructions.
Figure 14-4 Solaris Management Console Window – Action Menu
A series of windows guide you through the creation of the state

database.
8. Select alternate disk sets when additional disk sets are available, as
shown in Figure 14-5. In this configuration, no additional disk sets
have been configured, so choose the default selection of <none>.
Figure 14-5 Create Replicas: Select Disk Sets Window

Note – A disk set is a set of shared disk drives that contain logical Volume
Manager objects that can be shared exclusively but not concurrently by
one or two hosts. Disk sets are enablers for host fail-over scenarios.
9. Click Next to continue.
Note – Disk sets are described in ES-222: Solaris Volume Manager

Administration.

When you choose disk slices on which to store the state database
replicas, select at least three slices. Figure 14-6 shows that you can
choose to configure as many slices as are required by the size of your
system’s disk configuration. The size of these disk slices are pre-set
using the partitioning mechanism of the format utility.
Figure 14-6 Create Replicas: Select Components Window
10. Select a slice.

11. Click Add.
12. Continue adding slices until all the necessary slices are selected.
Note – Alternatively, to select multiple slices, hold down the Control key
while you make your selections.

The default size of each replica is 8192 blocks or 4 Mbytes. The

window, as shown in Figure 14-7, enables you to increase the size of
the replicas and the number of replicas per slice.
Figure 14-7 Create Replicas: Set Length and Count Window
14. Unless equipment limitations force you to assign multiple replicas to

a device, accept the default replica count of 1.

Figure 14-8 shows the selections you have chosen for your state
database replicas. Additionally, this window shows the commands
that the Storage Volume Manager uses to build your selected
configuration.
Figure 14-8 Create Replicas: Review Window
Showing the commands is a nice feature of SVM, and one that you may want to point out to students so they
may capture command output, then use for future CLI or scripting efforts.
16. Double-check your selections to ensure that they meet the criteria of
your state database replicas.
Note – Before you click Finish, click Show Commands to view and,
optionally, log the commands used to accomplish the specified Enhanced
Storage Tool operations.
17. Click Finish to complete the operation.

Figure 14-9 shows that the newly configured state database replicas
appear in the View pane of the Solaris Management Console.
Figure 14-9 Solaris Management Console: New State Database Replicas

Window
If at least three replicas are configured on separate disks, the system

tolerates a single disk failure and still maintains the majority consensus
algorithm. The majority consensus algorithm is necessary for the system
to remain running or for it to reboot to multiuser mode when required.
Note – The configuration represented in this example does not follow Sun
Microsystems best practices. State database replicas should be distributed
across multiple devices and disk controllers wherever possible.

Configuring RAID-0
Configuring RAID-0
RAID-0 volumes allow you to expand disk storage capacity efficiently.
These volumes do not provide data redundancy but can be used to
expand disk storage capacity. If a single slice fails on a RAID-0 volume,
there is a loss of data. RAID-0 comes in two forms, stripes and
concatenations.
● Concatenated volumes (or concatenations)
A concatenated volume writes data to the first available slice. When
the first slice is full, the volume writes data to the next available slice.
● Striped volumes (or stripes)
A stripe distributes data equally across all slices in the stripe.

RAID-0 Striped Volumes

Figure 14-10 shows the arrangement of a RAID-0 volume configured as a
stripe. A RAID-0 volume configured as a stripe arranges data across two
or more slices. Striping alternates equally-sized segments of data across
two or more slices, forming one logical storage unit. These segments are
interleaved round-robin, so that the combined space is created alternately
from each slice.
Physical Physical Physical

Slice A Slice B Slice C
Interlace 1 Interlace 2 Interlace 3
Solaris Volume
Manager
RAID 0
(Stripe)
Logical Volume
Figure 14-10 RAID-0 Stripe
Striping enables parallel data access because multiple controllers can

access the data at the same time. Parallel access increases Input/Output
(I/O) performance because multiple disks in the volume can service I/O
requests simultaneously.

You cannot convert an existing file system directly to a striped volume.

You must first back up the file system, create the striped volume, and then
restore the file system to the striped volume.

Creating a RAID-0 Volume
Using the Command Line
In this example, the slice being used for the /export/home file system is
almost at capacity. A new slice from another disk is concatenated to it,
making a RAID-0 concatenated volume. The existing slice is shown:
# df -h /export/home
Filesystem size used avail capacity Mounted on
/dev/dsk/c0t0d0s7 470M 395M 28M 94% /export/home
If the metadatabases are not already configured, they need to be

configured before creating any metadevices.
# metadb -a -f -c 2 c3t2d0s7 c3t3d0s7
# metadb
flags first blk block count
a u 8208 8192 /dev/dsk/c3t2d0s7
a u 8208 8192 /dev/dsk/c3t3d0s7
The concatenated volume must be referenced by a metadevice name. The

metainit command creates the metadevices. The syntax of the metainit
command is:
metainit -f concat/stripe numstripes width component...
where:
-f Forces the metainit command to continue, even if

one of the slices contains a mounted file system or
is being used as swap space. This option is useful
when configuring mirrors or concatenations on
root (/), swap, and /usr file systems.
concat/stripe Specifies the volume name of the concatenation or
stripe being defined.
numstripes Specifies the number of individual stripes in the
metadevice. For a simple stripe, numstripes is
always 1. For a concatenation, numstripes is equal
to the number of slices.

width Specifies the number of slices that make up a

stripe. When the width is greater than 1, the slices
are striped.
component Specifies the logical name for the physical slice
(partition) on a disk drive, such as
/dev/dsk/c0t0d0s1.
Metadevices are referenced by the letter d followed by a number. The new

metadevice will be called d0. The -f option is required, as one of the
slices being included in the concatenated volume is mounted. As this is a
concatenation, the number of stripes is equal to the number of slices being
added, in this case 2. The number of slices in each stripe is one, so the
number 1 appears before each slice:
# metainit -f d0 2 1 c0t0d0s7 1 c3t2d0s0
d0: Concat/Stripe is setup
Note – The metastat command does not show information about soft
partitioning.
The metastat command is used to check the configuration:

# metastat
d0: Concat/Stripe
Size: 3118752 blocks (1.5 GB)
Stripe 0:
Device Start Block Dbase Reloc
c0t0d0s7 0 No Yes
Stripe 1:
Device Start Block Dbase Reloc
c3t2d0s0 2160 No Yes
Device Relocation Information:

Device Reloc Device ID
c0t0d0 Yes id1,dad@AST38420A=7AZ0VMFG
c3t2d0 Yes id1,sd@SFUJITSU_MAB3045S_SUN4.2G00F50615____
The d0 metadevice is shown, with the two stripes which make up the
concatenation. The new device is represented with block and character
special device files:
# ls -lL /dev/md/dsk
total 0
brw-r----- 1 root sys 85, 0 Oct 25 12:35 d0

# ls -lL /dev/md/rdsk
total 0
crw-r----- 1 root sys 85, 0 Oct 25 12:35 d0
The new metadevice (d0) has been created but is not being used yet. The
/export/home file system is still mounted as a regular disk slice:
/dev/dsk/c0t0d0s7 470M 395M 28M 94% /export/home
It needs to be remounted using the new metadevice device files. Locate

the entry in the /etc/vfstab file which mounts the file system at boot
time:
Change the device files to the metadevice files:

/dev/md/dsk/d0/dev/md/rdsk/d0 /export/home ufs 2 yes -
Then un-mount and re-mount the file system using the new device files:
# umount /export/home
# mount /export/home
/dev/md/dsk/d0 470M 395M 28M 94% /export/home
The file system is now mounted using the metadevice device file. Notice
that the file system does not appear to be any bigger, and the capacity is
still at 94%. The existing file system needs to be grown into the new space.
This is done with the growfs command. Use the option -M to specify a
mount point:
# growfs -M /export/home /dev/md/rdsk/d0
/dev/md/rdsk/d0: 3118752 sectors in 3094 cylinders of 16 tracks, 63
sectors
1522.8MB in 194 cyl groups (16 c/g, 7.88MB/g, 3776 i/g)
super-block backups (for fsck -F ufs -o b=#) at:
32, 16224, 32416, 48608, 64800, 80992, 97184, 113376, 129568, 145760,
2968096, 2984288, 3000480, 3016672, 3032864, 3049056, 3065248, 3081440,
3096608, 3112800,

The file system now occupies all the space in the d0 metadevice:
/dev/md/dsk/d0 1.4G 395M 988M 29% /export/home

Using Solaris Management Console (SMC)
It is not possible to perform the same configuration using only Solaris

Management Console (SMC). When SMC performs the metainit
command at the end of the slice selections, it doesn’t use the -f to force
the addition of a mounted file system to a metadevice. To configure the
concatenated volume in SMC, unmount the /export/home file system.
# umount /export/home
The same slices and file systems are used in this example as was used in
the previous command line example. It assumes the metastate databases
are already configured.
1. To check this, start the Solaris Management Console:
# smc &
2. Select the Volumes tool and Create Volume from the Action menu, as
shown in Figure 14-11.
Figure 14-11 Select Create Volume
Every time you create a new volume, you can create additional state
database replicas. When creating RAID-0 volumes, it is usually
unnecessary to create additional state database replicas.

3. Select Don’t Create State Database Replicas in the Create Volume

window, as shown in Figure 14-12.
Figure 14-12 Create Volume Window

Every time you create a new volume, as shown in Figure 14-13, you can
relocate it on alternate disk sets.
Figure 14-13 Create Volume: Select Disk Set Window
5. Select the default of <none> and click Next to continue.

Figure 14-14 shows a selection of volume configurations that you can

create.
Figure 14-14 Create Volume: Select Volume Type Window
6. Select Concatenation (RAID 0) and click Next to continue.

You can name the volume, as shown in Figure 14-15. In this example
d0 is being used:
Figure 14-15 Create Volume: Name Volume Window
7. Name the volume d0 and click Next to continue.

Select the slice already being used and an unused slice, as shown in
Figure 14-16.
Figure 14-16 Create Volume: Select Components Window
8. Select the existing slice and click Add to move it to the Selected list.
9. Select an unused slice and click Add to move it to the Selected list.

You can select the order of presentation of the slices within the
volume, as shown in Figure 14-17.
Power user – A hot spare pool is a set of slices you can use to improve the
fault tolerance of the system. To allow continued data accesses to a failed
volume until you can replace a failed slice, hot spares are automatically
swapped in to replace the failed slice. After replacing the failed slice, the
hot spare is automatically swapped back onto the replacement slice, as
shown in Figure 14-18.

RAID-0 does not have any data redundancy features and no hot spare
pools have been created. The Hot Spare Pool window is shown in
Figure 14-18.
Figure 14-18 Create Volume: Use Hot Spare Pool Window
12. Select No Hot Spare Pool and click Next to continue.

The Create Volume window provides a confirmation of your

selections. It also provides a summary of the commands necessary to
accomplish the identical task from the command line, as shown in
Figure 14-19.
Figure 14-19 Create Volume: Review Window
13. Click Finish.

Figure 14-20 shows the metadevice for the newly created RAID-0
volume.
Figure 14-20 Solaris Management Console: Volumes Window
This procedure has created the d0 concatenated metadevice. The

/etc/vfstab file needs to be changed, the file system remounted and
grown before the extra space is available. First, change the standard
device files to the metadevice files:
/dev/md/dsk/d0 /dev/md/rdsk/d0 /export/home ufs 2 yes -
# mount /export/home
# growfs -M /export/home /dev/md/rdsk/d0
/dev/md/rdsk/d0: 3118752 sectors in 3094 cylinders of 16 tracks, 63
sectors
1522.8MB in 194 cyl groups (16 c/g, 7.88MB/g, 3776 i/g)
super-block backups (for fsck -F ufs -o b=#) at:
32, 16224, 32416, 48608, 64800, 80992, 97184, 113376, 129568, 145760,
2968096, 2984288, 3000480, 3016672, 3032864, 3049056, 3065248, 3081440,
3096608, 3112800,
/dev/md/dsk/d0 1.4G 395M 988M 29% /export/home

Configuring RAID-1
Configuring RAID-1
RAID-1 volumes are also known as mirrors and provide data redundancy.
In a two-way mirror, the data is written to two disk slices of the same size.
If one disk fails, the other will have an up-to-date copy of the data.
A RAID-1 volume maintains identical copies of the data in several

RAID-0 volumes. Mirroring requires more disks. You need at least twice
as much disk space as the amount of data to be mirrored.
After configuring a mirror, you can use it as if it were a physical slice.

With multiple copies of data available, and correctly configured read and
write policies, data access time is reduced.
You can mirror any file system, including existing file systems.
Using Multiple Submirrors
A mirror is made of two or more RAID-0 volumes. The mirrored RAID-0

volumes are called submirrors. A mirror consisting of two submirrors is
known as a two-way mirror, while a mirror consisting of three submirrors
is known as a three-way mirror.
Creating a two-way mirror is usually sufficient for data redundancy. A

third submirror lets you maintain redundancy with one of the other two
submirrors offline.
When a submirror is offline, it is in a read-only mode. The Solaris Volume

Manager software tracks all the changes written to the online submirror.
When the submirror is brought back online, only the newly written
portions are resynchronized. Typical reasons for taking the submirror
offline include backups, troubleshooting and repair.
Their is a fairly subtle consideration related to the State DBs when they support a mirror volume. A read-write
mirror uses what is called a Dirty Region Log (DRL) and these DRLs are located in the State DBs. The DRL
is used to record all changes made to the mirror volume. If the system panics before some sub-mirrors get
updated, or a sub-mirror was offline for some reason, entries in the DRL significantly reduce the time needed
to syncronize the sub-mirror data again. Rather than copying all of the mirrors data to a sub-mirror being
attached, the DRL can be used to indicate the changes that have occured and avoid copying data that is
already on the sub-mirror.
You can attach or detach a submirror from a mirror at any time, though at
least one submirror must remain attached to the mirror at all times.
Usually, you begin the creation of a mirror with only a single submirror,
after which you can attach additional submirrors.

Configuring RAID-1
Mirror Options
Mirror performance can be modified by using the following options:

● Mirror read policy
● Mirror write policy
Note – The mirror options listed here are representative of the options
presented when configuring RAID-1 mirrors using the Solaris Volume
Manager software.
You can define mirror options when you initially create the mirror or after
you set up the mirror. You can distribute the load across the submirrors to
improve read performance. Table 14-1 describes the configurable mirror
read policies.
Table 14-1 Mirror Read Policies
Read Policy Description
Round Robin (default) Balances the load across the submirrors

Geometric Enables the system to divide reads among
submirrors on the basis of a logical disk block
address
First Directs all reads to the first submirror
You can improve write performance by replicating all submirrors

simultaneously. If a failure occurs during this write, the submirror that
had the failure is put into maintenance state (errored state). Table 14-2
describes the configurable mirror write policies.
Table 14-2 Mirror Write Policies
Write Policy Description
Parallel (Default) Replicates a write to a mirror, and dispatches

the write to all of the submirrors
simultaneously
Serial Specifies that writes to one submirror must
complete before initiating writes to the next
submirror

Configuring RAID-1
When a submirror is offline, any writes to the mirror are tracked in a dirty
region log. When the submirror is brought back online, those regions
must be updated or resynchronized.

Building a Mirror of the Root (/) File System

The procedure for building a mirror of the root (/) file system can be
accomplished using the command line exclusively but it is not possible to
use the Solaris Management Console (SMC) exclusively. As seen during
RAID-0 configuration, SMC is not able to force the creation of a
metadevice from a mounted file system.
Note – Remove the volume d0 created in the previous example to avoid

confusion during this procedure.
This section describes how to create a RAID-1 volume for the root (/) file
system, which cannot be unmounted. To create a mirror, do the following:
1. Create a RAID-0 volume for the file system you want to mirror.
2. Create a second RAID-0 volume to contain the second submirror of
the RAID-1 volume.
3. Create a one-way mirror using the RAID-0 volume that contains the
file system to be mirrored.
4. Use the metaroot command to update the system’s configuration, as
this is a root (/) mirror.
5. Reboot your system, as this is a root (/) mirror.
6. Attach the second submirror to the file system mirror.
7. Record the alternate boot path that is used in the event of a failure of
the primary submirror, as this is a mirror of the root (/) file system.

The Scenario
The scenario assumes the root (/) file system is on disk slice c0t0d0s0.
1. A RAID-0 volume called d11 is created from slice c0t0d0s0.
2. A second RAID-0 volume is created as metadevice d12 from a spare
disk slice at c3t3d0s1.
3. A RAID-1 volume is created and named d10 using the RAID-0
volumes named d11 and d12, as shown in Figure 14-21.
RAID 1
Volume
@
@ @
RAID 0 RAID 0
Volume Volume
Figure 14-21 Mirror of Root (/) Partition
Creating The RAID-0 Volumes

The first step when building a mirror of the root (/) file system is to create
RAID-0 volumes, which you later combine to form the mirror. Each
RAID-0 volume becomes a submirror to the mirror. Use the metainit
command to force the creation of the RAID-0 volume. The force (-f)
option must be used because this is the root (/) file system, which cannot
be unmounted.
The following example shows how to use the metainit command to

create a RAID-0 volume:
# /usr/sbin/metainit -f d11 1 1 c0t0d0s0

Caution – If converting an existing file system to a RAID-0 volume, both

the numstripes and width arguments must be 1, or the data is lost.
The command line forces the creation of volume d11. Volume d11 creates
a concatenation composed of a single stripe, one slice wide, and it is
stored on the /dev/dsk/c0t0d0s0 disk slice.
Note – In this example, the root (/) file system is stored on the disk slice
/dev/dsk/c0t0d0s0. Because the root (/) file system is stored at that
location, you must use of the -f option to force the creation of a volume
on the mounted partition.
To create an additional RAID-0 volume, for the secondary submirror of

the root file system, use the Enhanced Storage Tool within the Solaris
Management Console.
To create additional volumes from the command line, use the metainit
command again:
# metainit d12 1 1 c3t3d0s1
To create the same metadevice from the GUI, complete the following
steps:
1. Click the Volumes icon.

Any configured metadevice volumes appear on the View pane, as

shown in Figure 14-22. If there are no metadevice volumes currently
configured, the View pane remains empty.
Figure 14-22 Volumes Icon

2. Select Create Volume from the Action menu, as shown in

Figure 14-23.
Figure 14-23 Solaris Management Console: Action Menu
3. Answer the prompts in the Create Volume Wizard window.

Every time you create a new volume, you can create additional state
database replicas. When creating RAID-0 volumes, it is usually
unnecessary to create additional state database replicas.
4. Select Don’t Create State Database Replicas in the Create Volume
window, as shown in Figure 14-24.
Figure 14-24 Create Volume Window

Every time you create a new volume, as shown in Figure 14-25, you
can relocate it on alternate disk sets.
6. If only one disk set exists on the system, select the default of <none>.

Figure 14-26 shows a selection of volume configurations that you can

create.
8. Select Concatenation (RAID 0).


You can name the volume, as shown in Figure 14-27. In this

procedure, build a mirror named d10. The two submirrors that
comprise the mirror are d11 (for the first submirror) and d12 (for the
second submirror). You have already created volume d11 from the
slice that contains the root (/) file system, so this one is volume d12,
which contains the mirror of the root (/) file system.
10. Name the volume d12.


You can also select a slice that the new volume occupies, as shown in
Figure 14-28. This volume is the secondary submirror of a mirror,
therefore the size of this slice must be equal to or greater than the
size of the primary submirror of the mirror.
12. Select a slice equal to or greater than the size of the primary
submirror RAID-0 volume.
13. Click Add to move it to the Selected list.

You can select the order of presentation of the slices within the stripe
group, if you are mirroring a file system that can span multiple
slices, as shown in Figure 14-29.
Note – When mirroring root (/), you cannot span multiple slices.
This window is used when building multiple slices into a single volume. Because this is a mirror of root, where
a single slice is involved, this window serves no function in this procedure.

A hot spare pool is a set of slices you can use to improve the fault
tolerance of the system. To allow continued data accesses to a failed
volume until you can replace a failed slice, hot spares are
automatically swapped in to replace the failed slice. After replacing
the failed slice, the hot spare is automatically swapped back onto the
replacement slice.
16. Because no hot spare pools have been created, select No Hot Spare
Pool, as shown in Figure 14-30.
Figure 14-30 Create Volume: Use Hot Spare Pool Window

The Create Volume: Review window provides a confirmation of your

accomplish the identical task from the command line, as shown in
Figure 14-31.
18. Click Finish.

Figure 14-32 shows the metadevice for the newly created RAID-0
volume.
Figure 14-32 Solaris Management Console: Volumes Window
In this procedure, you created two RAID-0 volumes, d11 and d12. The
d11 volume contains the slice where the root (/) file system is stored, and
the d12 volume contains space for a copy of the root (/) file system.
Creating The RAID-1 Volume

You can create the RAID-1 volume using:
● The metainit command
● The Enhanced Storage Tool within the Solaris Management Console

The metainit Command
The syntax for creating a RAID-1 volume by using the metainit

command is:
metainit mirror -m submirror [read_options] [write_options] [pass_num]
where:
mirror -m Specifies the volume name of the mirror.

submirror The -m indicates that the configuration is a mirror.
Submirror is a volume (stripe or concatenation) that
makes up the initial one-way mirror.
read_options The following read options for mirrors are available:
• -g – Enables the geometric read option, which
results in faster performance on sequential
reads.
• -r – Directs all reads to the first submirror. Use
the -r option only when the devices that
comprise the first submirror are substantially
faster than those of the second mirror. You
cannot use the -r option with the -g option.
write_options The following write option is available:
S – Performs serial writes to mirrors. The default

setting for this option is parallel write.
pass_num A number (0–9) at the end of an entry defining a
mirror that determines the order in which that
mirror is resynchronized during a reboot. The
default is 1. Smaller pass numbers are
resynchronized first. Equal pass numbers are run
concurrently. If 0 is used, the resynchronization is
skipped. Use 0 only for mirrors mounted as
read-only, or as swap space.
Note – If neither the -g nor -r options are specified, reads are made in a
round-robin order from all submirrors in the mirror. This process enables
load balancing across the submirrors.

The following command-line example creates a mirrored volume named

d10, and attaches a one-way mirror using volume d11. Volume d11 is a
submirror of the mirror named d10.
# /usr/sbin/metainit d10 -m d11
d10: Mirror is setup
The Enhanced Storage Tool
You can also create the mirror by using the Enhanced Storage Tool within
the Solaris Volume Manager software.
To create a mirror:
1. Click the Volumes icon.
The previously configured RAID-0 volumes are displayed, as shown
in Figure 14-33. If these volumes are not displayed, you must first
configure the RAID-0 volumes before you can use them as
submirrors of the RAID-1 volume.
Figure 14-33 Solaris Management Console: Volume

2. Select Create Volume from the Action menu, as shown in

Figure 14-34.
Figure 14-34 Solaris Management Console: Action Menu Window

Because the dirty region logs that are used to track which data blocks
in the submirrors have been modified are recorded within the state
database replicas, when you create RAID-1 volumes, you can add
additional state database replicas. You do not have to create
additional replicas when creating RAID-1 volumes, but mirror
performance might suffer if you do not.
3. Due to equipment limitations in the classroom, select Don’t Create
State Database Replicas, as shown in Figure 14-35.
Figure 14-35 Create Volume: Create State Database Replicas Window

You can relocate the mirror to alternate disk sets.

5. If only one disk set exists on the system, select the default of <none>,
as shown in Figure 14-36.
Note – When you are mirroring root, you must use the local disk set.

The Create Volume: Select Volume Type Windowwindow displays

which volume configurations you can create, as shown in
Figure 14-37.
7. Choose Mirror (RAID 1).


In the Create Volume: Name Volume window, you can enter a

volume name, as shown in Figure 14-38. Choose a pattern that is
easy to remember so that it is easy to identify the volume types. For
example, you could name the RAID-1 volumes with names ending in
zero, such as d10. Then you can number the submirrors or RAID-0
volumes as d11 for the first submirror and d12 for the second
submirror.
9. Enter 10 as the volume name d field.


11. Select metadevice d11 for use as the primary submirror, as shown in
Figure 14-39.
Figure 14-39 Create Volume: Select Primary Submirror Window

13. Bypass the Create Volume: Select Remaining Submirrors Window

window shown in Figure 14-40, because you are mirroring the root
partition, which means that you must attach the secondary
submirror by using the command line.
● When mirroring the root (/) partition, the procedure requires a
few additional steps prior to attaching the secondary submirror.
● When building a mirror that does not already contain data, you
can select the secondary submirror, as shown in Figure 14-40.
Figure 14-40 Create Volume: Select Remaining Submirrors Window

The Create Volume: Set Mirror Parameters window lets you set the
mirror parameters, as shown in Figure 14-41. These parameters were
described in the metainit command example that was used to
configure a RAID-1 volume.
Figure 14-41 Create Volume: Set Mirror Parameters Window
15. To accept the defaults, click Next to continue.

Review your selections in the Create Volume: Review window, as

shown in Figure 14-42. This window provides a confirmation of your
accomplish the identical task from the command line.
16. Click Finish.

The RAID-1 volume named d10 is created, and the display is

updated, as shown in Figure 14-43. The primary submirror (d11) is
attached to the mirror (d10), but the process of creating the mirrored
partition is not complete.
Figure 14-43 Solaris Management Console: Volumes
You can click on the d10 volume to highlight it, and then use the right mouse button to display a menu. From
this menu, you can select Properties to view the configuration and verify the sub-mirrors included.
17. Go to the command line, and use the metaroot command to

complete building the mirror of the root (/) file system, as described
in ‘‘Executing the metaroot Command’’ on page 14-63.

Executing the metaroot Command
When creating mirrors of mounted file systems, you must update the
/etc/vfstab file to change the mount point from a slice, such as
/dev/dsk/c#t#d#s#, to a volume, such as /dev/md/dsk/d##. When
mirroring any mounted file system other than root (/), you can use the vi
editor to update the /etc/vfstab file.
When mirroring the root (/) file system, use the metaroot command to
modify the /etc/vfstab and /etc/system files, as follows:
metaroot device
where device specifies either the metadevice or the conventional disk

device (slice) used for the root (/) file system.
The following example shows that the /etc/vfstab file has been
updated by the metaroot command to point to the RAID-1 mirrored
metadevice.
# metaroot d10
# grep md /etc/vfstab
/dev/md/dsk/d10 /dev/md/rdsk/d10 / ufs 1 no -
In addition to modifying the /etc/vfstab file to update the root (/) file
system pointer, the metaroot command updates the /etc/system file to
support the logical volumes. For example:
# tail /etc/system
rootdev:/pseudo/md@0:0,10,blk
You must reboot the system before attaching the secondary submirror.
When the system boots, it mounts the root file system using the
metadevice device file. Enter the init command to reboot the system:
# init 6
After the reboot is complete, the root file system is mounted through the
d10 metadevice:
# df -h /
/dev/md/dsk/d10 141M 111M 15M 88% /

The metastat command shows the state of the metadevices. Notice here
that only one submirror is in the d10 metadevice:
# metastat
d10: Mirror
Submirror 0: d11
State: Okay
Pass: 1
Read option: roundrobin (default)
Write option: parallel (default)
Size: 307440 blocks (150 MB)
d11: Submirror of d10

State: Okay
Stripe 0:
Device Start Block Dbase State Reloc Hot Spare
c0t0d0s0 0 No Okay Yes
(output omitted)
Attach the secondary submirror by using the metattach command:

# metattach d10 d12
d10: submirror d12 is attached
Caution – Create a one-way mirror with the metainit command, and

then attach the additional submirrors with the metattach command. If
the metattach command is not used, no resynchronization operations
occur. As a result, data could become corrupted as the Solaris Volume
Manager software assumes that both sides of the mirror are identical and
can be used interchangeably.
The metastat command shows the mirror synchronization taking place.

# metastat d10
d10: Mirror
Submirror 0: d11
State: Okay
Submirror 1: d12
State: Resyncing
Resync in progress: 83 % done
Pass: 1


State: Okay
Stripe 0:

State: Resyncing
Stripe 0:
Updating the boot-device PROM Variable
If you mirror your root (/) file system, record the alternate boot path
contained in the boot-device PROM variable. In the following example,
you determine the path to the alternate boot device by using the ls -l
command on the slice that is being attached as the secondary submirror to
the root (/) mirror.
# ls -l /dev/dsk/c3t3d0s1
lrwxrwxrwx 1 root root 57 Oct 25 11:22 /dev/dsk/c3t3d0s1 -
> ../../devices/pci@1f,0/pci@1/pci@1/SUNW,isptwo@4/sd@3,0:b
Record the path that follows the /devices directory:

/pci@1f,0/pci@1/pci@1/SUNW,isptwo@4/sd@3,0:b
Caution – When using some disk controllers, the path to the device varies
between the entries in the /devices directory and the entries in the
OpenBoot programmable read-only memory (PROM). In these instances,
follow the entries in the OpenBoot PROM.
If, for example, on one Ultra™ 5 workstation, the PCI-SCSI controller

returns:
/pci@1f,0/pci@1/scsi@4,1/sd@2,0:b
from the /devices directory, yet the show-disks command from the
OpenBoot PROM returned:
/pci@1f,0/pci@1/scsi@4,1/disk
then, the alternate boot path must be:

/pci@1f,0/pci@1/scsi@4,1/disk@2,0:b
If you do not adapt to the change when attempting to boot from the
alternate boot device, you get an error stating:
can’t open boot device
To get the system to boot automatically from the alternate boot device in
the event of a primary root submirror failure, complete the following
steps:
1. Use the OpenBoot nvalias command to define a backup_root
device alias for the secondary root mirror. For example:
ok nvalias backup_root /pci@1f,0/pci@1/pci@1/SUNW,isptwo@4/sd@3,0:b
2. Redefine the boot-device variable to reference both the primary
and secondary submirrors, in the order in which you want to access
them. For example:
ok printenv boot-device
boot-device= disk net
ok setenv boot-device disk backup_root net
boot-device= disk backup_root net
In the event of primary root disk failure, the system automatically boots
from the secondary submirror. To test the secondary submirror, boot the
system manually, as follows:
ok boot backup_root

Unmirroring the Root (/) File System

Follow this procedure to unmirror the root (/) file system. This procedure
assumes that the root (/) file system is mirrored on a Solaris Volume
Manager software volume named d10, and that the mirror consists of two
submirrors. The primary submirror is d11, and the secondary submirror is
d12. To unmirror the root (/) file system, complete the following steps:
1. Run the metastat command on the mirror to verify that submirror 0
is in the Okay state.
# metastat d10
d10: Mirror
Submirror 0: d11
State: Okay
Submirror 1: d12
State: Okay
Pass: 1

State: Okay
Stripe 0:

State: Okay
Stripe 0:

c0t0d0 Yes id1,dad@AST38420A=7AZ0VMFG
c3t3d0 Yes id1,sd@SFUJITSU_MAB3045S_SUN4.2G00F52267____

2. Run the metadetach command on the mirror to make a one-way

mirror.
# metadetach d10 d12
d10: submirror d12 is detached
3. Because this is a root (/) file system mirror, run the metaroot
command to update the /etc/vfstab and etc/system files.
# metaroot /dev/dsk/c0t0d0s0
# grep c0t0d0s0 /etc/vfstab
/dev/dsk/c0t0d0s0/dev/rdsk/c0t0d0s0/ufs1no-
4. Reboot the system.

# init 6
5. Run the metaclear command to clear the mirror and submirrors.
The -r option recursively deletes specified metadevices and hot
spare pools, associated with the targeted metadevices specified in the
metaclear command.
# metaclear -r d10
d10: Mirror is cleared
d11: Concat/Stripe is cleared
# metaclear d12
d12: Concat/Stripe is cleared
6. If you changed your boot-device variable to an alternate boot path,
return it to it’s original setting.

The metassist Command

Solaris 9 9/04 introduced the metassist command which allows you to
create top level Solaris Volume Manager volume configurations with a
single command. For example, rather than manually working through the
process of partitioning disks, creating RAID 0 volumes (as submirrors),
creating hot spare pools and hot spares, and finally creating a mirror, with
the metassist command, you can issue a single command to create a
volume, and Solaris Volume Manager will do the rest for you.
With the metassist command, you can specify volume characteristics in

terms of quality of service. You can specify the following quality of service
characteristics:
● size
● redundancy (number of copies of data)
● data paths
● fault recovery (whether the volume should be associated with a hot
spare pool)
● volume types (for example, RAID 0 (concatenation) or RAID 0
(stripe))
● components to use in specific volumes
● components that are available or unavailable for use
● number of components to use
● details specific to the type of volume being created (including
interlace value for stripes, read policy for mirrors, and similar
characteristics)
Use the command line to specify the quality of service attributes you
require, and allow the metassist command to create the necessary
volumes for you. A simple example would be:
# metassist create -s storagepool -S 10Gb
This command would create a stripe volume of 10Gb in size in the

storagepool disk set, using available storage existing in the storagepool
disk set.

Creating volumes and volume configurations automatically with the

metassist command requires that you have a functional Solaris Volume
Manager configuration before you begin. At a minimum, you should have
the following:
● root access or have assumed an equivalent role
● state database replicas, distributed appropriately for your system
● available disks to use for the volumes you will create
● The following disk set RPC daemons running:
● rpc.metad
● rpc.metamhd
● rpc.metamedd
Understanding Which Disks Are Available
The metassist command checks disks to see which disks appear to be

unused, and attempts to conservatively determine which disks are
available. Any disk or slice that is determined to be in use is considered
unavailable for use by the metassist command. Checks include:
● Disks used in other disk sets
● Mounted slices
● Slices with a file system superblock, indicating a mountable file
system
● Slices used in other Solaris Volume Manager volumes
For more information about the metassist command, see the following
resource:
Solaris Volume Manager Administration Guide, part number 816-4520

Exercise: Mirroring the Root (/) File System

● Configure the Solaris Volume Manager software to create state
database replicas
● Mirror the root (/) file system
● Update the default boot device
● Unmirror the root (/) file system
Preparation
This exercise mirrors the root (/) file system of your system’s boot disk.
This exercise requires a second disk that is not in use. Steps in this
exercise direct you to partition the second disk so that it has one partition
equal to the root (/) partition on the boot disk, and at least two partitions
to be used for state database replicas.
This exercise is performed on each individual system, so there is no need

to work with a partner. Most steps in these procedures are executed using
the command line. The Enhanced Storage Tool within the Solaris
Management Console is used to monitor the progress of the exercise.
This exercise requires an understanding of how to use the format utility to

partition disks.
Task
Complete the following steps:
1. Start the Solaris Management Console and complete the following
steps:
a. Open the Enhanced Storage Tool within the Solaris
Management Console, and leave it open throughout this
exercise to use it as a monitoring tool.
b. Use the tools within the Enhanced Storage Tool to view objects
that you create using command line commands.

2. Use the df command to list file systems in use and the format utility
to display the partition table for your system’s boot disk.
You should record the following information:
● Disk slice used for the root (/) file system, and its size in
megabytes. This will become the primary submirror:
_______________________________________________
● Does the slice used for the root (/) file system start on cylinder
0 of the boot disk?
_______________________________________________
● Disk slice for state database replica 1: _______________________
● Disk slice for state database replica 2: _______________________
3. Use the format utility to partition your spare disk so that it includes
the partitions listed:
● Set the size of slice 0 to be equal to or greater than the disk slice
used for the root (/) file system. This slice is a candidate to
become the secondary submirror.
● Set the size of slice 6 to be at least 4 Mbytes. This slice will be
used for state database replica 3.
Both slice 0 and slice 1 were set to match the boot disk root slice size to provide a choice of two slices to use
for the secondary submirror. Explain to students that you cannot mirror a slice that contains a disk label to
one that does not.
Different training centers may have built the student systems differently, some where slice 0 of the boot disk
starts on cylinder 0, others where it does not. Explain the need to choose the slice on the second disk, 0 or
1, that correlates to how the root slice is defined on the boot disk. Also, explain that it is not a general SVM
requirement to define partitions exactly as they are here in the exercise.

4. Determine the names of Solaris Volume Manager objects to use for

this exercise:
● Volume to map to the root (/) file system primary submirror:
_______________________________________________
● Volume to map to the root (/) file system secondary submirror:
_______________________________________________
● Volume to map to the root (/) file system mirror:
_______________________________________________
5. Create a sufficient number of state database replicas to support the
majority consensus algorithm used in the Solaris Volume Manager
software. For example:
What is the minimum number of state database replicas necessary to
support the majority consensus algorithm?
_______________________________________________
6. Create a RAID-0 volume to use as the root (/) file system’s primary
submirror.
7. Create a RAID 0 volume on the secondary drive to use as the root (/)
file system’s secondary submirror.
You should refer to step 2 to determine which of the following
conditions is true.
a. If the root slice on your boot disk starts on cylinder 0, use slice 0
on the second disk as the secondary submirror.
b. If the root slice on your boot disk does not start on cylinder 0, use
slice 1 on the second disk as the secondary submirror.
8. Create a RAID-1 volume as a one-way mirror using the root (/) file
system primary submirror as the source of the mirror’s data.
9. Review the /etc/vfstab and the /etc/system files. Use the
metaroot command to update these two files to use the RAID-1
volume as the mount point for the root (/) file system. Observe the
changes to the /etc/vfstab and the /etc/system files.
10. Reboot the system, and then log in as root.
steps:
Management Console.

12. Attach the RAID-0 volume used as the root (/) file system’s
secondary submirror to the RAID-1 volume and allow the mirror
synchronization to complete before continuing.
What is the primary reason for using the command line to attach a
secondary submirror to a mirror?
_______________________________________________
_______________________________________________
Note – To view the status of the resynchronization process, use the

/usr/sbin/metastat | grep Resync command.
13. Determine the physical device path to the alternate root (/) device
you selected in step 7 (as reported by the Solaris 10 OS).
14. Use the init 0 command to enter the OpenBoot PROM, and then
the show-disks command to determine the path to the alternate root
(/) device (as reported by the OpenBoot PROM).
15. Define a backup root (/) device alias.
16. Add the backup_root device alias to the boot-device variable.
You should retain the alias for the primary boot disk.
17. Test the ability to boot the secondary root (/) submirror and log in as
root when the boot process completes.
18. Verify the status of the root (/) submirrors.
19. Detach one submirror to make the root (/) mirror a one-way mirror.
20. Update the /etc/vfstab file to redefine the root (/) mount point
using the original disk slice, and the /etc/system file to remove the
forceload statements.
21. Shut down the system to the OBP level.
complete the following steps:
a. Reset it to its default setting.
b. Boot the system to the multi-user milestone.
23. Clear the mirror and submirrors.
24. Remove all state database replicas.

Exercise Summary
Exercise Summary

discoveries you had during the lab exercises.
!
?
Manage the discussion based on the time allowed for this module, which was provided in the “About This
Course” module. If you do not have time to spend on discussion, then just highlight the key concepts students
should have learned from the lab exercise.
● Experiences
● Interpretations
● Conclusions
● Applications

Exercise Solutions
Exercise Solutions

The solutions to the task are as follows.
Task
Review the following solutions:
steps:
Management Console, and leave it open throughout this
exercise to use it as a monitoring tool.
# smc &
Note – The task solutions are presented using the command-line

equivalents because every task step can be performed by using the
command line.

Exercise Solutions
2. Use the df command to list file systems in use, and the format
utility to display the partition table for your system’s boot disk.
Record the following information:
● Disk slice used for the root (/) file system, and its size in
megabytes. This will become the primary submirror:
As pre-defined for your lab system. (Slice 0 and 500 Mbytes, in this
example.)
● Does the slice used for the root (/) file system start on cylinder
0 of the boot disk?
As pre-defined for your lab system. (No, in this example.) This
information is required to determine what slice on the second disk to
use as the secondary submirror, for the purpose of this exercise.
● Disk slice for state database replica 1:
As pre-defined for your lab system. (Slice 4, in this example.)
● Disk slice for state database replica 2:
As pre-defined for your lab system. (Slice 5, in this example.)
# df -h
/dev/dsk/c0t0d0s0 470M 194M 229M 46% /
/devices 0K 0K 0K 0% /devices
ctfs 0K 0K 0K 0% /system/contract
proc 0K 0K 0K 0% /proc
mnttab 0K 0K 0K 0% /etc/mnttab
swap 854M 880K 853M 1% /etc/svc/volatile
objfs 0K 0K 0K 0% /system/object
/dev/dsk/c0t0d0s6 4.8G 2.9G 1.9G 61% /usr
fd 0K 0K 0K 0% /dev/fd
/dev/dsk/c0t0d0s3 479M 57M 375M 14% /var
swap 853M 0K 853M 0% /tmp
swap 853M 40K 853M 1% /var/run
/dev/dsk/c0t0d0s7 2.1G 2.1M 2.0G 1% /export
# format
(output omitted)
format> partition
(output omitted)
partition> print
Current partition table (original):
Total disk cylinders available: 17660 + 2 (reserved cylinders)

0 root wm 1041 - 2056 500.06MB (1016/0/0) 1024128
1 swap wu 0 - 1040 512.37MB (1041/0/0) 1049328
2 backup wm 0 - 17659 8.49GB (17660/0/0) 17801280
3 var wm 2057 - 3093 510.40MB (1037/0/0) 1045296

Exercise Solutions
4 unassigned wm 3094 - 3102 4.43MB (9/0/0) 9072

5 unassigned wm 3103 - 3111 4.43MB (9/0/0) 9072
6 usr wm 3112 - 13270 4.88GB (10159/0/0) 10240272
7 home wm 13271 - 17659 2.11GB (4389/0/0) 4424112
partition> q
(output omitted)
format> q
#
3. Use the format utility to partition your spare disk so that it includes
the partitions listed:
Both slice 0 and slice 1 were set to match the boot disk root slice size to provide a choice of two slices to use
for the secondary submirror. Explain to students that you cannot mirror a slice that contains a disk label to
one that does not.
Different training centers may have built the student systems differently, some where slice 0 of the boot disk
starts on cylinder 0, others where it does not. Explain the need to choose the slice on the second disk, 0 or
1, that correlates to how the root slice is defined on the boot disk. Also, explain that it is not a general SVM
requirement to define partitions exactly as they are here in the exercise.
# format
(output omitted)
partition> print
Volume: test
Current partition table (test):
Total disk cylinders available: 4924 + 2 (reserved cylinders)

0 root wm 0 - 285 501.48MB (286/0/0) 1027026
1 swap wu 286 - 571 501.48MB (286/0/0) 1027026
2 backup wm 0 - 4923 8.43GB (4924/0/0) 17682084
3 var wm 0 0 (0/0/0) 0
4 unassigned wm 0 0 (0/0/0) 0
5 unassigned wm 572 - 4917 7.44GB (4346/0/0) 15606486
6 usr wm 4918 - 4920 5.26MB (3/0/0) 10773

Exercise Solutions
7 unassigned wm 4921 - 4923 5.26MB (3/0/0) 10773
partition>
4. Determine the names of Solaris Volume Manager objects to use for
this exercise:
● Volume to map to the root (/) file system primary submirror:
As defined for your lab system. (The examples use d11.)
● Volume to map to the root (/) file system secondary submirror:
● Volume to map to the root (/) file system mirror:
5. Create a sufficient number of state database replicas to support the
majority consensus algorithm used in the Solaris Volume Manager
software. For example:
# /usr/sbin/metadb -a -f c0t0d0s4
# /usr/sbin/metadb -a c0t0d0s5
#
What is the minimum number of state database replicas necessary to
support the majority consensus algorithm?
As a best practice, you should use three state database replicas as the
minimum to support the majority consensus algorithm.
6. Create a RAID-0 volume to use as the root (/) file system’s primary
submirror.
# /usr/sbin/metainit -f d11 1 1 c0t0d0s0
(The variable points to the root (/) slice.)
7. Create a RAID 0 volume on the secondary drive to use as the root (/)
file system’s secondary submirror.
You should refer to step 2 to determine which of the following
conditions is true.
a. If the root slice on your boot disk starts on cylinder 0, use slice 0
on the second disk as the secondary submirror.
# /usr/sbin/metainit d12 1 1 c1t5d0s0
b. If the root slice on your boot disk does not start on cylinder 0, use
slice 1 on the second disk as the secondary submirror.

Exercise Solutions
# /usr/sbin/metainit d12 1 1 c1t5d0s1

8. Create a RAID-1 volume as a one-way mirror using the root (/) file
system primary submirror as the source of the mirror’s data.
# /usr/sbin/metainit d10 -m d11
d10: Mirror is setup
9. Review the /etc/vfstab and the /etc/system files. Use the
metaroot command to update these two files to use the RAID-1
volume as the mount point for the root (/) file system. Observe the
changes to the /etc/vfstab and the /etc/system files.
# cat /etc/vfstab
(output omitted)
# cat /etc/system
(output omitted)
# /usr/sbin/metaroot d10
# cat /etc/vfstab
(output omitted)
# cat /etc/system
(output omitted)
10. Reboot the system, and then log in as root.
# init 6
steps:
Management Console.
12. Attach the RAID-0 volume used as the root (/) file system’s
secondary submirror to the RAID-1 volume and allow the mirror
synchronization to complete before continuing.
# /usr/sbin/metattach d10 d12
d10: submirror d12 is attached
#
What is the primary reason for using the command line to attach a
secondary submirror to a mirror?
The primary reason for using the command line to attach a secondary
submirror to a mirror is to force a resynchronization of the data between the
primary and secondary submirror.

Exercise Solutions
Note – To view the status of the resynchronization process, use the

/usr/sbin/metastat | grep Resync command.
13. Determine the physical device path to the alternate root (/) device
you selected in step 7 (as reported by the Solaris 10 OS).
This varies by system. Use the ls -l command.
# ls -l /dev/dsk/c1t5d0s1
lrwxrwxrwx 1 root root 57 May 24 12:47 /dev/dsk/c1t5d0s1 -
> ../../devices/pci@1f,0/pci@1/pci@1/SUNW,isptwo@4/sd@5,0:b
14. Use the init 0 command to enter the OpenBoot PROM, and then
the show-disks command to determine the path to the alternate root
(/) device (as reported by the OpenBoot PROM).
This varies by system.
ok show-disks
15. Define a backup root (/) device alias.
This varies by system. Use the nvalias command.
ok nvalias backup_root device_path
16. Add the backup_root device alias to the boot-device variable.
You should retain the alias for the primary boot disk.
This varies by system. Use a combination of the printenv and setenv
commands.
ok printenv boot-device
boot-device = disk net
ok setenv boot-device disk backup_root
boot-device = disk backup_root
17. Test the ability to boot the secondary root (/) submirror and log in as
root when the boot process completes.
ok boot backup_root
18. Verify the status of the root (/) submirrors.
# /usr/sbin/metastat d10
d10: Mirror
Submirror 0: d11
State: Okay
Submirror 1: d12
State: Okay
Pass: 1

Exercise Solutions

State: Okay
Stripe 0:

State: Okay
Stripe 0:

c0t0d0 Yes id1,dad@AST39140A=AY907169
c1t5d0 Yes id1,sd@SFUJITSU_MAB3091S_SUN9.0G00D84225____
19. Detach one submirror to make the root (/) mirror a one-way mirror.
# /usr/sbin/metadetach d10 d12
20. Update the /etc/vfstab file to redefine the root (/) mount point
using the original disk slice, and the /etc/system file to remove the
forceload statements.
# /usr/sbin/metaroot /dev/dsk/c0t0d0s0
21. Shut down the system to the OBP level.
# init 0

Exercise Solutions

complete the following steps:
a. Reset it to its default setting.
b. Boot the system to the multi-user milestone.
ok set-default boot-device
ok boot
23. Clear the mirror and submirrors.
# /usr/sbin/metaclear -r d10
# /usr/sbin/metaclear d12
24. Remove all state database replicas.
# /usr/sbin/metadb -d c0t0d0s4
# /usr/sbin/metadb -d -f c1t5d0s7

Module 15
Controlling Access and Configuring System

Messaging
Objectives
● Describe the effect of the /etc/inet/ipnodes file on the loghost
variable
● Describe generic log rotation
15-1
Objectives
Relevance

System messaging changes in the Solaris 10 OS
!
?
● What are the contents of the ipnodes file?
● How can I control the size of different log files?


Controlling Access and Configuring System Messaging 15-3

Configuring System Messaging

The syslog function, the syslogd daemon, and input from the
/etc/syslog.conf file work together to facilitate system messaging for
the Solaris 10 OS.
While the file names and functionality has remained much the same
through Solaris 8, 9, and 10, a change to how the loghost variable is
determined in Solaris 10 needs explanation.
The loghost Setting

These /etc/inet/hosts file examples show that the loghost variable can
be assigned to either system.
Example A /etc/inet/hosts:
192.9.200.1 host1 loghost
192.9.200.2 host2
Example B /etc/inet/hosts:
192.9.200.1 host1
When the syslogd daemon starts at system boot, the syslogd daemon
evaluates the /etc/hosts file, and checks the Internet Protocol (IP)
address associated with the hostname as compared to the IP address
associated with loghost.

This functionality has not changed through the Solaris releases mentioned
in this course, but there has been a change in Solaris 10 that affects the
loghost setting. Previous to Solaris 10, the /etc/inet/ipnodes file was
only populated with IPv6 addresses. Now, the /etc/inet/ipnodes
can contain either IPv4 or an IPv6 addresses, as shown in the following
example:
cat /etc/inet/ipnodes
#
# Internet host table
#
::1 localhost
127.0.0.1 localhost
192.9.200.2 host2
IP addresses can be defined in the /etc/inet/ipnodes file or in the

/etc/inet/hosts file. The ipnodes file will be searched first, then the
hosts file.
This is the most important item to discuss, the order of search.
Ideally, both of these files will contain the same information so that there
would not be any inconsistency between loghost variables.

The /etc/syslog.conf File

Solaris 9 introduced a generic log rotation facility. System administrators
can use this facility to maintain and rotate system and application log
files.
The logadm command is a general log rotation tool that is can be run from
cron. The logadm command reads the /etc/logadm.conf file and checks
for the presence of those named log files to see if they should be rotated.
The corresponding log file gets renamed by adding a number suffix such
as logfile.0, logfile.1, etc. By default, ten versions of the logfile are
kept.
The following example is an /etc/logadm.conf file from a system running

Solaris 10 01/06. This file has been edited for readability.
# more /etc/logadm.conf
#
/var/log/syslog -C 8 -P ’Fri Jan 20 10:10:00 2006’ -a ’kill -HUP ‘cat
/var/run/syslog.pid‘’
/var/adm/messages -C 4 -P ’Fri Jan 20 10:10:00 2006’ -a ’kill -HUP ‘cat
/var/run/syslog.pid‘’
/var/cron/log -c -s 512k -t /var/cron/olog
/var/lp/logs/lpsched -C 2 -N -t ’$file.$N’
/var/fm/fmd/errlog -M ’/usr/sbin/fmadm -q rotate errlog && mv
/var/fm/fmd/errlog.0- $nfile’ -N -s 2m
smf_logs -C 8 -s 1m /var/svc/log/*.log
#
# The entry below is used by turnacct(1M)
#
/var/adm/pacct -C 0 -N -a ’/usr/lib/acct/accton pacct’ -g adm -m 664 -o
adm -p never
#
# The entry below manages the Dynamic Resource Pools daemon (poold(1M))
logfile.
#
/var/log/pool/poold -N -a ’pkill -HUP poold; true’ -s 512k

Solaris 10 has changed the way many services are handles with the release
of the SMF. For example, in Solaris 9, enabling and logging inetd trace
messages would have been accomplished by performing the following
procedure:
1. Edit the /etc/inet/inetsvc file and changing the line that read:
/usr/sbin/inetd -s to /usr/sbin/inetd -s -t
2. Edit the /etc/default/inetd file and setting the following field:
ENABLE_CONNECTION_LOGGING=YES
3. Stopping and starting the inetd process:
# /etc/init.d/inetsvc stop
# /etc/init.d/inetsvc start
With Solaris 10, the same procedure is accomplished by performing the

following steps:
1. Modify the inetd service, and change the default value of the
tcp_trace option to TRUE:
# inetadm -M tcp_trace=TRUE
2. Verify that the inetd daemon is running with the tracing option
enabled.
# inetadm -p
NAME=VALUE
bind_addr=""
bind_fail_max=-1
bind_fail_interval=-1
max_con_rate=-1
max_copies=-1
con_rate_offline=-1
failrate_cnt=40
failrate_interval=60
inherit_env=TRUE
tcp_trace=TRUE
tcp_wrappers=FALSE
The same change in procedures applies when stopping and starting the
syslog process. With Solaris 9, the procedure would be:
# /etc/init.d/syslog stop/start
With Solaris 10, the procedure is:

# svcadm refresh system-log

Module 16
Naming Services
Objectives
Upon completion of this module, you should be able to descibe the
differences in:
● The name service switch file
● The LDAP name service
16-1
Objectives
Relevance

the changes are between Solaris 8, 9, and 10:
!
?
● What are the changes that have been made to naming services, such
as NIS, DNS, and LDAP?
● How has the /etc/nsswitch.conf file been changed?
● How has the /var/yp/Makefile file been changed?


● http://docs.sun.com: System Administration Guide: Naming and
Directory Services (DNS, NIS, and LDAP)
● http://www.sun.com/bigadmin/content/n2l: User Guide for NIS to
LDAP Transition Tool
Naming Services 16-3

Lightweight Directory Access Protocol (LDAP)
Lightweight Directory Access Protocol (LDAP)

LDAP is the protocol clients use to communicate with a directory server.
It is a vendor independent protocol and can be used on common TCP/IP
networks.
LDAP Directory Server

A directory server is not necessarily an LDAP server. However, in the
context of this module, the term Directory Server is synonymous with
LDAP Server. Solaris 10 comes with an LDAP client and LDAP server. The
LDAP Directory Server is called the Sun Java™ System Directory Server.
The Sun Java System Directory Server is no longer bundled with Solaris
10. The Sun Java System Directory Server is now bundled with the Java
Enterprise Server CDs.
The Sun Java System Directory Server must be set up and then configured
to support Solaris LDAP clients.
Solaris 9 supported Lightweight Directory Access Protocol (LDAP) with

the iPlanet" Directory Server 5.1, as well as other LDAP directory servers.
Services supported by LDAP include application servers, calendar
servers, and messaging servers.
Installation of the following packages at a minimum results in a working

LDAP directory Server:
IPLTadcon IPLTadmin IPLTcons IPLTdscon IPLTdsr
IPLTdsu IPLTjss IPLTnls IPLTnspr IPLTnss
IPLTpldap

Changes in the /etc/nsswitch File

Name resolution using the Internet domain name system begins with the
client-side resolver. The resolver is a set of routines that are built into the
resolver library. The /etc/nsswitch.conf file is one of two files used for
name resolution, /etc/resolv.conf is the other.
This module describes differences in the

/etc/nsswitch.<name_service> file from Solaris 8 through Solaris 10,
using the diff command to examine each name service version within
each different release.
The output of each diff command has been edited to increase readability.
The /etc/nsswitch.conf File

The default /etc/nsswitch.conf file in each release has no differences.
The /etc/nsswitch.dns File

The default /etc/nsswitch.dns file is the same in Solaris 8 and 9,
however, there are changes between Solaris 9 and Solaris 10:
# diff S9nsswitch.dns S10nsswitch.dns
> # DNS service expects that an instance of svc:/network/dns/client be

> # enabled and online.
< ipnodes: files

< # Uncomment the following line and comment out the above to resolve
< # both IPv4 and IPv6 addresses from the ipnodes databases. Note that
< # IPv4 addresses are searched in all of the ipnodes databases before
< # searching the hosts databases. Before turning this option on, consult
< # the Network Administration Guide for more details on using IPv6.
< #ipnodes: files dns
> # Note that IPv4 addresses are searched for in all of the ipnodes
databases before searching the hosts databases.
> ipnodes: files dns
>
< sendmailvars: files

Notice in the example that the first line has a note explaining that the
appropriate SMF service must be enabled and online. This note is
prevelant through all examples of the Solaris 10 configuration files, and is
a result of the introduction of the Service Management Facility.
The second note pertains to the difference in the /etc/inet/ipnodes file

between Solaris 9 and Solaris 10. The /etc/inet/ipnodes file in Solaris
10 can have IPv4 addresses in it, and is consulted before the
/etc/inet/hosts file.
The third item shown is the database sendmailvars, which has been
removed in Solaris 10.

The /etc/nsswitch.ldap File

Changes between the Solaris 8 and the Solaris 9 versions are:
# diff S8nsswitch.ldap S9nsswitch.ldap
< # role-based access control
> printers: user files ldap
< exec_attr: files ldap
< user_attr: files ldap
< # audit
< audit_user: files ldap
Notice in the example that the first comment, followed by the exec_attr,
user_attr, and audit_user databases show that RBAC functionality was
introduced in Solaris 9.
The second line shown illistrates the printers database is now supported.
The printers database provides centralized printer configuration
information to print clients on the network. This is new functionality in
Solaris 9.

# diff S9nsswitch.ldap S10nsswitch.ldap
> # LDAP service requires that svc:/network/ldap/client:default be
enabled and online.
< ipnodes: files

< #ipnodes: ldap [NOTFOUND=return] files
> ipnodes: ldap [NOTFOUND=return] files
These differences have already been discussed in this module.

The /etc/nsswitch.nis File

There are no differences between the Solaris 8 and Solaris 9 versions of the
file.

# diff S9nsswitch.nis S10nsswitch.nis
> # NIS service requires that svc:/network/nis/client:default be enabled
> # and online.
< ipnodes: files

< #ipnodes: nis [NOTFOUND=return] files
> ipnodes: nis [NOTFOUND=return] files
These differences have already been discussed in this module.

Configuring the NIS Domain

To generate NIS maps, you need the source files. You can find source files
in the /etc directory on the master server. To locate the source files in
another directory, modify the /var/yp/Makefile file.
The /var/yp/Makefile File

The ypinit command reads the /var/yp/Makefile file for source file
locations, and converts ASCII source files into NIS maps. The
/var/yp/Makefile file contains new variable in the Solaris 10 OS.
The two new variables are INETDIR, and RBACDIR and are found in the
first section of the /var/yp/Makefile file, as highlighted below:
#B=-b
B=
DIR =/etc
INETDIR=/etc/inet
RBACDIR=/etc/security
PWDIR =/etc
DOM = ‘domainname‘
NOPUSH = ""
ALIASES = /etc/mail/aliases
YPDIR=/usr/lib/netsvc/yp
SBINDIR=/usr/sbin
YPDBDIR=/var/yp
YPPUSH=$(YPDIR)/yppush
MAKEDBM=$(SBINDIR)/makedbm
MULTI=$(YPDIR)/multi
REVNETGROUP=$(SBINDIR)/revnetgroup
STDETHERS=$(YPDIR)/stdethers
STDHOSTS=$(YPDIR)/stdhosts
MKNETID=$(SBINDIR)/mknetid
MKALIAS=$(YPDIR)/mkalias
New ipnodes maps (ipnodes.byaddr and ipnodes.byname) have been

added to NIS. The maps store both IPv4 and IPv6 addresses. See the
ipnodes(4) man page for more information. NIS clients and servers can
communicate using either IPv4 or IPv6 RPC transports.
The ageing.byname mapping contains information used by yppasswdd to

read and write password aging information to the DIT. If password aging
is not being used, then it can be commented out of the mapping file.

NIS to LDAP Transition Tool

Between Solaris 9 and Solaris 10, a new transition tool for migrating NIS
to LDAP was introduced. TheNIS to LDAP transition tool is commonly
refered to as N2L.
N2L is a replacement for the existing NIS server side product which
provides a migration path from NIS to LDAP. It enables NIS maps to be
synchronized with NIS like information in the directory and accessed
with NIS like speed and extensibility.
The primary role of N2L is to support the following tasks:

● Importing NIS maps into the LDAP Directory Information Tree (DIT)
● Client access to that information in the DIT, with NIS-like speed and
extensibility
Other key points of N2L are:

● LDAP server may be on same machine as NIS server (recommended)
or a different machine.
● Scripts make standard + .auto maps easy to set
● Custom maps can be done based on templates set up for standard
maps.
Details about N2L can be found on docs.sun.com, in the "Naming and

Directory Services (DNS, NIS, and LDAP)" of the System Administration
Guide.
Also, see the man pages for ypserv(4) and NISLDAPmapping(4)
If you are teaching an LVC, you may also want to have one of the students bring up
http://www.sun.com/bigadmin/content/n2l/NIS2LDAP.pdf in a shared window to keep the students interest.

Module 17
Configuring the Custom JumpStart

Procedure
Objectives
differences in:
● Boot Services
● Identification Services
● Configuration Services
● Installation Services
17-1
Relevance
Relevance

!
?
● What are the new keywords in Solaris 9 and 10?
● What is the effect of SMF on Jumpstart?


Configuring the Custom JumpStart Procedure 17-3

Introducing JumpStart Differences

JumpStart is an automatic installation process available in the Solaris OS.
JumpStart enables you to install the Solaris OS automatically and
configure it differently, depending on the characteristics of client systems.
Boot Services
Solaris 8 and 9 used the same boot services, there were no changes
between these two versions of the Operating System. Solaris 10
introduced SMF, which changed the way processes are started and
stopped.
After the /etc/dfs/dfstab file has been edited, you must verify that
NFS services are running, and if necessary, start them:
1. Run the svcs command to check that NFS services are enabled.
# svcs -a |grep nfs
STATE STIME FMRI
disabled 14:56:34 svc:/network/nfs/mapid:default
disabled 14:56:36 svc:/network/nfs/server:default
online 14:57:13 svc:/network/nfs/rquota:ticlts
online 14:57:13 svc:/network/nfs/rquota:udp
2. Use the svcadm command to enable the NFS services if required:

# svcadm enable network/nfs/server:default
3. Check that the NFS service is online.
# svcs -a |grep nfs

STATE STIME FMRI
online 16:01:14 svc:/network/nfs/mapid:default
online 16:01:14 svc:/network/nfs/rquota:ticlts
online 16:01:15 svc:/network/nfs/server:default

online 16:01:15 svc:/network/nfs/rquota:udp

#
4. Verify that the /export/config and /export/install directories

are currently shared.
# share
- /export/install ro,anon=0 ""
- /export/config ro ""
Identification Services
JumpStart clients require support from a server to automatically get the
answers to system identification questions that the client systems issue.
Identification items are configurable through the sysidcfg file and

through a Name Service. In Solaris 9, the default router configuration
became required.
Solaris 10 introduced the ability to configure multiple network interfaces.
Configuration Services
JumpStart clients require support from a server to obtain answers for
system configuration questions that they issue.
Solaris 10 introduced the ability to add or delete software packages and

patches that were not part of the installation media.
Installation Services
JumpStart clients require support from a server to find an image of the
Solaris OS to install. A system that provides this service is called an install
server. An install server shares a Solaris OS image from a CD-ROM, DVD,
or local disk. JumpStart clients use the NFS service to mount the
installation image during the installation process.
Sources of the Operating System Image
An install server provides the Solaris Operating System image by sharing

one of the following:

● The Solaris OS Software 1 CD-ROM

● The Solaris OS Software DVD
● A spooled image of the Solaris Operating System obtained from
either the CD-ROM or DVD media
● Flash Installation, which was introduced with Solaris 9
Beginning with the Solaris 8 2/02 release, the Solaris Media Kit has been
available on either CD-ROM or DVD media.
The Spooled Image
An install server can provide installation services by sharing a spooled

image on a local disk. When you spool the Solaris Operating System
image from CD-ROM or DVD, the result is a directory that contains the
boot image and the installation image.
The setup_install_server script enables you to spool the boot and

installation images from the Solaris OS 1 CD-ROM or from the DVD.
The add_to_install_server script enables you to spool additional

installation image data from CD-ROMs 2, 3, and 4.
The modify_install_server script was available in Solaris 8 and 9, and

removed in Solaris 10. It enabled an interactive Solaris Web Start style of
installation on the client.
A Flash Install Image
The Flash Archive and Flash Installation functionality was introduced in

Solaris 9.
Flash installation is significantly faster than the current JumpStart

installation or a network installation method. Flash allows detailed
customization of the Solaris Operating System, hardware configuration,
and third-party software packages prior to creation of the clones
Examples of the sysidcfg File

The Solaris OS JumpStart clients require a sysidcfg file to answer
identification questions that cannot be provided by default from a name
service.

The following is an example of a basic sysidcfg file, with the default

router addition from Solaris 9 highlighted:
network_interface=hme0 {primary protocol_ipv6=no
netmask=255.255.255.0
default_route=192.10.10.100}
security_policy=none
name_service=none
timezone=US/Mountain
system_locale=en_US
timeserver=192.10.10.100
root_password=Hx23475vABDDM
The following example shows a sysidcfg file which is used to configure

multiple network interfaces. The capability to configure multiple network
interfaces in the sysidcfg file was introduced in Solaris 9 (9/04).
network_interface=hme0 { primary hostname=sys01
ip_address=192.168.2.10
protocol_ipv6=no
netmask=255.255.255.0
network_interface=qfe0 { hostname=sys01
ip_address=192.168.2.101
protocol_ipv6=no netmask=255.255.255.0
network_interface=qfe1 { hostname=sys02
ip_address=192.168.2.111
network_interface=qfe2 { dhcp protocol_ipv6=no }
network_interface=qfe3 { ip_address=192.168.2.121
security_policy=none
name_service=none
timezone=US/Mountain
system_locale=en_US
timeserver=192.10.10.1
root_password=Hx23475vABDDM

Changes to the Profile File

In order to provide configuration services, the JumpStart server provides
a rules.ok file that allows the JumpStart client to select a profile file.
The rules file enables groups of clients with the same characteristics to
be grouped together as a class. Consequently the profile file is frequently
referred to as the class file, particularly with Solaris 8.
In Solaris 10, the following profile keywords were added or enhanced:
patch patch_id_list | patch_file

patch_location
filesys mirror device size file_system
optional_parameters
metadb slice [size in blocks] [number]
package package_name add | delete
The package and patch keywords
The package keyword prior to Solaris 10 was only used to add or delete
packages from the installation that were part of the installation media.
The keyword has been enhanced to allow package installations that are
not part of the installation media. Previously this was only possible by
using a finish script.
Packages to be installed can be obtained from the following sources:

● NFS server
● HTTP server
● Local device
● Local file
If adding packages to a system through http(s), they must be in Data

Stream format. If adding patches to a system through http(s), they must
be in jar format.

The syntax for the entry in the profile varies depending on the location
selected, as shown in Table 17-1.
Table 17-1 Package Syntax
Package Source Syntax example
NFS package SUNWnew add nfs sys01:/var/spool/pkg/Solaris_10

or
package SUNWnew add
nfs://sys01/var/spool/pkg/Solaris_10
HTTP package SUNWnew add http://sys01/solaris10
or
package SUNWnew add http://sys01/solaris10 proxy
sys02:8080
local_device package SUNWnew add local_device c0t6d0s0
/solaris10/pkg ufs
local_file package SUNWnew add local_file /solaris10/pkg
Adding Patches Using the patch Keyword (New in Solaris 10)
The patch keyword has been introduced in Solaris 10 to allow patches to

be installed during the JumpStart process. Table 17-2 shows patch
keyword syntax.
Previously patches had to be installed either manually or with a finish

script. Patches can be obtained from the following sources:
● NFS server
● HTTP server
● Local device
● Local file
Table 17-2 Patch keyword syntax
Source Syntax Example
NFS patch list_file nfs://sys01/solaris_10/patches
patch 112345-06,122223-01 nfs

sys01:/solaris_10/patches

Table 17-2 Patch keyword syntax
Source Syntax Example

HTTP patch 112233-01,223344-04
http://sys01/solaris10/patches
patch list_file http://sys01/solaris10/patches
local_device patch 112233-01,223344-04 local_device c0t6d0s0
/solaris10/Patches
patch list_file local_device c0t6d0s0
/solaris10/Patches
local_file patch 112233-01,223344-04 local_file
/solaris10/Patches
patch list_file local_file /solaris10/Patches
The cluster keyword requires a parameter that lists name of the

configuration cluster you want to install. Table 17-3 defines configuration
cluster names according to the common names used for them during the
interactive installation routine.
Table 17-3 Possible Entries for the cluster Keyword
Configuration Cluster
Interactive Installation Name
Name
Minimal Core Metacluster SUNWCmreq

(new in Solaris 9)
Reduced Network SUNWCrnet
(new in Solaris 10)
Core SUNWCreq
End User SUNWCuser
Developer SUNWCprog
Entire Distribution SUNWCall
Entire Distribution Plus OEM Support SUNWCXall
See the Solaris™ 10 System Release and Installation Collection for a

description of the clusters and packages available on the Solaris 10
Software Distribution CD-ROMs.

Examples of Profile Files
The following example describes a profile file that uses default

partitioning, except that the swap partition size set to 128 Mbytes. The
client installs the developer configuration cluster (SUNWCprog) and adds
the NIS packages, SUNWypr and SUNWypu. The manual pages from this
cluster (SUNWman) are deleted because the client mounts them from the
server named server1.
install_type initial_install
system_type standalone
partitioning default
filesys any 128 swap # specify size of swap
filesys server1:/usr/share/man - /usr/share/man ro,soft
cluster SUNWCprog
package SUNWman delete
package SUNWypr add
package SUNWypu add
The following example describes a profile file that installs the Entire
Distribution configuration cluster (SUNWCall), and removes the SUNWman
package. The example uses explicit partitioning and declares the slices
and sizes assigned to the root (/), swap, /usr, /var, and /opt file
systems.
system_type standalone
partitioning explicit
filesys c0t0d0s0 150 /
filesys c0t0d0s1 128 swap
filesys c0t0d0s6 800 /usr
filesys c0t0d0s7 free /var
filesys c0t1d0s7 all /opt
cluster SUNWCall
package SUNWman delete
Creating RAID-1 Volumes using the Profile File
The filesys keyword can be used in the profile file to create RAID-1
volumes on the client system.
The syntax of the profile filesys keyword is:

filesys [mirror[:name] slice slice size file_system [mount_options]

The following example creates a mirror called d12 consisting of two

components, slice c0t0d0s0 and c1t3d0s0. The size of the mirror is
850 Mbytes and is used as the mount point for the root file system.
filesys mirror:d12 c0t0d0s0 c1t3d0s0 850 /
If a name is not provided for the mirror, one is automatically provided.
The mirror keyword causes one state database replica to be put on each
slice in the mirror automatically. The administrator may choose to create
additional metastate databases.
Note – If you mirror a slice that contains a Volume Table of Contents

(VTOC), you must mirror it to a slice that also contains a VTOC.
The following profile example creates RAID-1 volumes (mirrors) for the
root (/), /usr, and /var file systems:
cluster SUNWCXall
filesys mirror c0t0d0s0 c1t3d0s0 850 /
filesys mirror:d10 c0t0d0s1 c1t3d0s1 1000 /var
filesys c1t3d0s3 512
metadb c0t0d0s4 count 4
metadb c1t3d0s4 count 4
filesys mirror c0t0d0s6 c1t3d0s6 5000 /usr
filesys c0t0d0s7 free /export/home
filesys c1t3d0s7 free
The following list describes this example:

1. The installation type is an initial installation.
2. The Entire Distribution Plus OEM software cluster is to be installed.
3. The root (/) file system is created and mirrored on the slices
c0t0d0s0 c1t3d0s0 and is 850 Mbytes in size. The resulting RAID
volumes are automatically assigned names as none is specified.
4. The /var file system is created and mirrored on the slices
c0t0d0s1 and c1t3d0s1. The RAID-1 volume is called d10.
5. The swap slice is created on c0t0d0s3 and is 512 Mbytes in size.
6. Slice c1t3d0s3 is 512MB in size but is not allocated to any file
system.

7. Four state database replicas are created on slice c0t0d0s4 and slice
c1t3d0s4.
8. The /usr filesystem is created and mirrored on slices c0t0d0s6
and c1t3d0s6. The name of the RAID-1 volume is automatically
assigned.
9. The /export/home file system is created on the remaining free
space on disk c0t0d0.
10. Slice c1t3d0s7 is created on the remaining free space on c1t3d0
but is not allocated to any file system.

Booting the JumpStart Client

After the JumpStart server has been configured to provide all of the
required services, you can initiate the installation process on the
JumpStart client.
As of Solaris 8 7/01 new options have been added for use with the boot
command when you perform a custom JumpStart installation:
With the boot command, you can specify the location of the configuration
files to use to perform the installation. You can specify a path to an HTTP
server, an NFS server, or a file that is available on local media. If you do
not know the path to the files, you can require that the installation
program prompt you for the path after the machine boots and connects to
the network.
The nowin option enables you to specify that the custom JumpStart
program not begin the X program. You do not need to use the X program
to perform a custom JumpStart installation, so you can shorten the
installation time by using the nowin option.
Finish Scripts
Finish scripts are Bourne scripts that JumpStart clients run after installing
the Solaris Operating System but before they reboot. Finish scripts allow
you to perform a variety of post-installation tasks on the JumpStart client,
including:
● Setting the power-management configuration
● Retrieving backed-up data from a server on the network
● Copying selected files from a JumpStart server to the client
● Specify the NFS4 domain
The NFSv4 Finish Script (New in Solaris 10)
A sample script is delivered as part of the JumpStart sample files in the

CD’s s0/Solaris_10/Misc/jumpstart_sample directory. This finish
script allows the user to specify the NFS4 domain, within the script, and
have the sysidcfg finish.sh script call it.

The provided script sets the NFSMAPID_DOMAIN setting in

/etc/default/nfs and create the /etc/.NFS4inst_state.domain
state file.
Upon first system boot, sysidnfs4 is executed by sysidconfig as

explained above, but the existence of the state file prevents any further
prompts for the name of the NFSv4 domain.
The NFSv4 finish script (edited for brevity) is shown below:

# cat /cdrom/cdrom0/s0/Solaris_10/Misc/jumpstart_sample/set_nfs4_domain
#!/bin/sh
#
# @(#)set_nfs4_domain 1.1 04/11/08 SMI
#
...
#
echo "setting NFSv4 domain"
...
NFS4_DOMAIN=foo.bar
...
FILE=/a/etc/default/nfs
STATE=/a/etc/.NFS4inst_state.domain
VAR=NFSMAPID_DOMAIN
VALUE=${NFS4_DOMAIN}
...
TFILE=${FILE}.$$
sed -e "s/^#[ ]*${VAR}=.*\$/${VAR}=${VALUE}/" ${FILE} > ${TFILE}
mv ${TFILE} ${FILE}
...
IFILE=‘echo ${FILE} | sed -e "s|^/a||g"‘
PERM=‘grep "^${IFILE} e" /a/var/sadm/install/contents |
(read f1 f2 f3 f4 f5 ; echo $f4)‘
chmod ${PERM} ${FILE}
touch ${STATE}
exit 0

Module 18
Performing a Flash Installation
Objectives
differences in:
● Describe the Flash installation feature
● Manipulate a Flash archive
● Use a Flash archive for installation
18-1
Objectives
Relevance

!
?
● What are the requirements and limitations for using Flash Archives?
● How do I use a Flash Archive in an installation?


● Solaris 10 Installation Guide: Solaris Flash Archives (Creation and
Installation) PN 817-5668
Performing a Flash Installation 18-3

Introducing Flash Archives and Installations

The Flash installation feature lets you create a single reference installation
of the Solaris OS on a master system, and then replicate the installation on
other systems known as clones. Flash Archives were introduced in an
Update to Solaris 8. Flash installation is a three-stage process involving:
● Installing and customizing the master system
● Creating a Flash archive on the master system
● Deploying the Flash archive to the clone system
Installing the Master
The Flash installation feature uses one or more archives created from a
master system that acts as a reference configuration. The master system is
an installed system that has been customized as required. Customization
can include adding or removing software packages, adding third-party or
unbundled software products, and modifying configuration files, such as
the SMF method scripts and run control script, and by enabling or
disabling SMF managed services. Further customization can be done
when creating the archive.
Hardware Requirements
The recommended system specifications for a Flash installation are:

● A SPARC system for the clone and a SPARC system for the master
(or an UltraSPARC® system for the clone and an UltraSPARC system
for the master).
● The master and the clone must have the same kernel architecture,
such as sun4u.
● Before you create the archive, you must install and configure the
master with the exact software, hardware, and peripheral device
package that you want on the clone. For example, to create a clone
that uses an Elite3D framebuffer, (even if the master does not use the
Elite3D card), you must include the necessary Solaris OS software
support in the archive.

Software Requirements
The recommended software specifications for a Flash installation is:

The Flash utility is installed as part of the Solaris OS. The Entire
Distribution + OEM software group is recommended for you to be
able to include all files and driver support when creating the Flash
archive.
Limitations of the Flash Utility
There are certain limitations to the Flash utility, including, but not limited
to, the configuration of the Solaris Volume Manager software and the
current versions of the Solaris OS:
● Flash does not support metadevices or non-UFS file systems.
● You can only create the archive from material available on the master
system.
Creating and Manipulating Flash Archives

The Flash archive is derived from the current installation on the master
system. You can easily transfer the archive as a large file from server to
server to deploy it to the clone systems.
You can create the archive when the system is running in single-user
mode, multiuser mode, or being booted from the Solaris 10 OS 1 CD-
ROM, or DVD.
During installation you must specify a directory and a location where the
Flash archive resides. Options during installation are:
● Network file system (NFS) server
● Hypertext Transfer Protocol (HTTP) server
● File Transfer Protocol (FTP) server
● Local or remote tape
● Compact Disc Read-Only Memory (CD-ROM)
● Local drive of clone machine
The Flash installation process involves creation of the Flash archive prior
to the deployment of the Flash archive to the clones.

Note – Ensure that the master is running as stable as possible during

archive creation.
The Flash installation utility comprises two commands:

● You can use the /usr/sbin/flar create command set to create an
archive on the master.
● You can use the /usr/sbin/flar administration command to
extract information from an archive, to split an archive, or to
combine archives.
Creating a Flash Archive

Options to the flar create command which are new in Solaris 10 are
noted in the table below by the comment "New in S10".
The syntax for the flar create command is:

flar create -n name [-R root] [-A old_root] [-t [-p posn] [-b blocksize]]
[-i date] [-u section [-d path ]] [-U key=value] [-m master]
[-H] [-S] [-c] [-M] [-I] [-f [ list_file | - ] [-F]]
[-a author] [-e descr | -E descr_file] [-T type]
[[-x exclude_dir/file][-x exclude_dir/file]...] [-X
list_file]
[[-y include_dir/file [-y include_dir/file]...]
[-z filter_list_file]
archive
where:
-n Specify the name of the archive.

-R Specify the root of the Flash archive in the currently running
system is not to be used.
-A Location of source master image. Used when creating
differential archives. (New in S10)
-i Set alternative creation date. (New in S10)
-S Do not include sizing information in the archive.
-c Compress the archive using the compress command.
-t Create an archive on a tape device.

-m Specify the name of the master on which you created the

archive.
-M Do not create a manifest. Used when creating differential
archives. (New in S10)
-a Specify the author of the archive.
-e Specify the description of the archive.
-x Exclude the named directory or file from the archive.
-X Exclude the named files in the file list. (New in S10)
-y Include the named directory or file (New in S10)
-z Include files prefixed with a plus sign and exclude files
prefixed with a minus sign in the file list. (New in S10)
archive Specify the path to the Flash archive.
Examples
The following example shows the creation of a Flash archive used to

install other systems. The master should be as quiescent as possible:
● Run the system in single-user mode
● Shut down any applications you want to archive
● Shut down any applications that use extensive system resources
# flar create -n flash_root_archive -c -R / -e root_archive \
-x /export/flash -a admin_operator -S /export/flash/flash_archive1
Determining which filesystems will be included in the archive...
Determining the size of the archive...
The archive will be approximately 517.98MB.
Creating the archive...
2034098 blocks
Archive creation complete.
In the example :
-n flash_root is the name of the Flash archive
-c causes the archive to be compressed
-R / creates the archive rooted at the root (/) directory
-e root_archive is the description of the archive
-x /export/flash excludes this directory from the archive

-a admin_operator is the author of the archive

-S do not include sizing information
Note – Be sure that you have enough disk space to contain the Flash
archives that you build. In the above example, the /export/flash
directory is large enough to contain the 518 Mbyte archive.
The following example creates a Flash archive and customizes the files to
be included in the archive:
# flar create -n local_apps -x /usr/local/ -y
/usr/local/custom_scripts local_archive
-n local_apps is the name of the archive
-x /usr/local is excluded from the archive
-y /usr/local/custom_scripts is included on the archive
The archive is created from the root (/) directory as -R has not been
specified.
Administering a Flash Archive

You use the /usr/sbin/flar command to perform archive
administration. You can split an archive into sections, which enables you
to modify some sections, add new sections, or delete sections. After you
have modified the sections, you need to merge the sections to create an
new archive. For example, you might want to add a User-Defined section
or modify the Archive Identification section. Do not modify the Archive
Files section or you compromise the integrity of the archive.
The syntax for the flar command is:

flar info archive
flar combine archive
flar split archive
where:
info Retrieves information about archives that have been created

combine Combines the individual sections that make up an existing

archive into a new archive
split Splits an archive into one file for each section of the archive
Keywords exclusive to Flash and identification of the archive can be

viewed from the online manual pages.
To list the header data that is created with the archive, use the flar info
command:
# flar info flash_archive1
archive_id=f67e46f0096ab9ac580cea5ba3ffeb72
files_archived_method=cpio
creation_date=20041005160703
creation_master=sys65
content_name=build68
creation_node=sys65
creation_hardware_class=sun4u
creation_platform=SUNW,UltraSPARC-IIi-cEngine
creation_processor=sparc
creation_release=5.10
creation_os_name=SunOS
creation_os_version=s10_68
files_compressed_method=compress
content_architectures=sun4u
type=FULL
The header of the archive file contains the following identification

parameters for the archive:
● content_name – The name of the archive (in this case,
flash_directoryname_archive)
● creation_date – The date that the archive is created (from the
master)
● creation_master – The name of the master (in this case, sys65)
● Other information about the archive
You can also use additional keywords for administering the archive.

Using a Flash Archive for Installation

The third and final stage of the Flash installation is the deployment of the
archive onto the clone. This process can create multiple clones of the
master.
You can use any of the Solaris OS installation methods to install Flash
archives, for example:
● Install Flash archives with the Solaris Web Start program
● Install Flash archives with the Solaris OS suninstall program
● Install Flash archives with a JumpStart installation
● The WAN Boot procedure
The initial steps for using a Flash archive for installation are the same as
setting up for a JumpStart installation. Using a Flash archive can be
interactive during the installation, or completely hands-off, depending on
how you set up your installation server.

Flash Installation Demonstration
1. Insert the Solaris 10 OS 1 CD-ROM, or DVD.

2. Boot the Flash clone system from the Boot PROM prompt as follows:
ok boot cdrom -nowin
After the pre-installation phase completes, a series of character-based
curses screens appear.
Note – The text screens shown in this installation sequence have been
edited for brevity and readability. Depending on your installation method,
you press the appropriate function key or it’s Escape key equivalent.
Read the curses-based content, answer any relevant prompts, and

use the function or escape key sequences to progress to the next
prompt. The installation proceeds the same as a standard installation
until you reach the Solaris Interactive Installation screen.
Solaris Interactive Installation
On the following screens, you can accept the defaults or you can
customize how Solaris software will be installed by:
- Selecting the type of Solaris software to install

- Selecting disks to hold software you’ve selected
- Selecting unbundled products to be installed with Solaris
- Specifying how file systems are laid out on the disks
After completing these tasks, a summary of your selections (called a

profile) will be displayed.
There are two ways to install your Solaris software:
- "Standard" installs your system from a standard Solaris Distribution.

Selecting "Standard" allows you to choose between initial install
and upgrade, if your system is upgradable.
- "Flash" installs your system from one or more Flash Archives.
F2_Standard F4_Flash F5_Exit F6_Help

You can select either a standard installation or a Flash installation.

3. Press F4 to select a Flash installation.

Follow the prompts that follow and answer the relevant questions
until you come to the Flash Archive Retrieval Method window.
Flash Archive Retrieval Method
On this screen you must select a method to retrieve the Flash archive.
The retrieval method depends on where the archive is stored. For
example, if the archive is stored on a tape, select "Local Tape".
Available Retrieval Methods

========================================
[ ] HTTP[S]
[ ] FTP
[X] NFS
[ ] Local File
[ ] Local Tape
[ ] Local Device
F2_Continue F5_Cancel F6_Help
When performing Flash archive installations, you can select any one
of six retrieval methods. One commonly used version is to retrieve
the archive from the master as NFS-shared files.
4. Select NFS, and press F2 to continue.
When you select a retrieval method, you must select a specific
location. In the NFS retrieval method, the next screen prompts you
for the server and location. Remember to use the IP address of the
server instead of the server name.
Flash Archive Addition
Please specify the path to the network file system where the Flash
archive is located. For example:
NFS Location: syrinx:/export/archive.flar
=========================================================================
NFS Location: 192.168.30.30:/export/install/flash_archive1
F2_Continue F5_Cancel F6_Help

5. Press F2 to continue.
Next, you add a Flash archive. If the NFS file system is mounted and
shared, and if you can locate the Flash archive within the file system,
you are prompted for additional Flash archive names. A Solaris OS
image must exist on a clone system before you can install additional
Flash archives. The first Flash archive you install must also contain a
bootable Solaris OS image.
Flash Archive Selection
You selected the following Flash archives to use to install this system.
If you want to add another archive to install select "New".
Retrieval Method Name
====================================================================
NFS build74L2
F2_Continue F3_Go Back F4_Edit F5_New F6_Help

Select Disks
On this screen you must select the disks for installing Solaris software.
Start by looking at the Suggested Minimum field; this value is the
approximate space needed to install the software you’ve selected. Keep
selecting disks until the Total Selected value exceeds the Suggested
Minimum value.
NOTE: ** denotes current boot disk
Disk Device Available Space
=========================================================================
[X] ** c0t0d0 19457 MB (F4 to edit)
[ ] c1t0d0 8633 MB
Total Selected: 19457 MB

Suggested Minimum: 2171 MB
F2_Continue F3_Go Back F4_Edit F5_Exit F6_Help

The Select Disks window identifies where you want to install the
Flash archive. This disk is now the boot disk for the clone system.

The system is queried and you are given the opportunity to preserve
any existing data on the target disk. If you decide to preserve data
you then select the file systems to preserve.
File System and Disk Layout
The summary below is your current file system and disk layout, based on
the information you’ve supplied.
NOTE: If you choose to customize, you should understand file systems,

their intended purpose on the disk, and how changing them may affect the
operation of the system.
File sys/Mnt point Disk/Slice Size
========================================================================
/ c0t0d0s0 5000 MB
swap c0t0d0s1 512 MB
overlap c0t0d0s2 19457 MB
/export/home c0t0d0s7 13945 MB
F2_Continue F3_Go Back F4_Customize F5_Exit F6_Help

The File System and Disk Layout window appears. This screen
varies according to your disk partition specification in the
preconfigured profile files. Explicit partitioning configures the disk
as specified in the profile file, while existing partitioning specifies
that you should leave the disk as currently configured. The existing
specification brings up the next screen where you are prompted to
customize the existing partitions.

The Mount Remote File Systems window appears. If your Flash
archives are stored on the master Flash archive server, press F2 to
continue.
-Profile
The information shown below is your profile for installing Solaris

software.
It reflects the choices you’ve made on previous screens.
========================================================================
Installation Option: Flash

Boot Device: c0t0d0
Client Services: None
Software: 1 Flash Archive

NFS: build74L2
File System and Disk Layout: / c0t0d0s0 3227 MB
swap c0t0d0s1 512 MB
/export/home c0t0d0s7 15718 MB
Esc-2_Begin Installation F4_Change F5_Exit F6_Help
The profiling phase of the Flash installation is now complete.

10. Review your selections and make changes, if necessary. If you are
satisfied with the selections, press F2 to begin the installation.
When you start the installation, you see the volume table of contents
(VTOC) information. The Solaris Flash Install install window,
provides a progress slide bar and numerical indication of how far the
installation has progressed.

The next screen shows the steps involved in completing the Flash
installation. After you install the Flash archive, the cleanup scripts
complete the installation housekeeping tasks, and the system either
reboots or prompts you to reboot, depending on your earlier
configuration.
Customizing system files
- Mount points table (/etc/vfstab)
- Unselected disk mount points
(/var/sadm/system/data/vfstab.unselected)
- Network host addresses (/etc/hosts)
Cleaning devices
Customizing system devices

- Physical devices (/devices)
- Logical devices (/dev)
Installing boot information

- Installing boot blocks (c0t0d0s0)
Installation log location

- /a/var/sadm/system/logs/install_log (before reboot)
- /var/sadm/system/logs/install_log (after reboot)
Flash installation complete

Executing JumpStart postinstall phase...
The begin script log ’begin.log’

is located in /var/sadm/system/logs after reboot.
Pausing for 90 seconds at the "Reboot" screen. The wizard will continue
to the next step unless you select "Pause". Enter ’p’ to pause. Enter ’c’
to continue. [c]

11. Reboot the system to complete the installation operation.

Notice that the device configuration might not correspond to the
devices on the system. It is usual to encounter errors on the first
reboot after a Flash install, because the actual device configuration
might differ between master and clone systems. The first reboot
reconfigures the devices.
Rebooting with command: boot

Boot device: /pci@1f,0/ide@d/disk@0,0:a File and args:
SunOS Release 5.10 Version s10 64-bit
SUNW,eri0 : 100 Mbps half duplex link up
Configuring devices.
Hostname: sys41
Loading smf(5) service descriptions: 118/118
checking ufs filesystems
/dev/rdsk/c0t0d0s7: is logging.
Creating new rsa public/private host key pair
Creating new dsa public/private host key pair
sys41 console login:

Differential Flash Archives

If you have previously installed a clone using a Flash archive, it is now
possible to update that system with changes by using a differential
archive. If the master has been updated, for example, by applying patches,
or packages have been added or removed, these changes can be applied
as a differential archive. The differential archive only overwrites files
specified in the archive, rather than the entire installation on the clone.
A list of new, changed or deleted files is generated, called a manifest.
A differential archive fails if the clone has been manually updated after it
was Flash installed from the master source.
A differential archive requires two images to compare. A source master

image, such as the original master flash configuration that has been left
untouched, and an updated master image. By default this updated master
image is the updated image, but it can be an image stored elsewhere. The
differential archive is made up of just the differences between the two
images.
The unchanged master image can be:

● A live upgrade boot environment mounted onto a directory
● An unchanged clone system mounted onto a directory using NFS
● An expanded flash archive on the local system
Creating a Differential Flash Archive

You use the flar create command to create a Differential Flash Archive.
Options for creating a Differential Archive are:
Option Description
-A Creates a differential archive by comparing a new

unchanged_master system image with the image that is specified by
_image_dir the unchanged_master_image_dir argument.
unchanged_master_image_dir is a directory
where the unchanged master system image is
stored or mounted through UFS, NFS, or
lumount.

Option Description
-M Excludes the manifest file. When you use this
option, no validation occurs on the differential
archive. When creating a differential archive, flar
create creates a long list of the files in the system
that are unchanged, are changed, and are to be
deleted from the archive. This list is stored in the
manifest section of the archive. When the
differential archive is deployed, the software uses
this list to perform a file-by-file check, ensuring
the integrity of the clone system. Use of this
option avoids such a check and saves the space
that is used by the manifest section in a
differential archive.
JumpStart Keywords for Solaris Flash Archives
The only keywords that are valid when you install a Solaris Flash archive
are the following:
Initial Differential
Keyword
Installation Archive
archive_location (required) X X
fdisk (x86 only) X X
filesys X
forced_deployment X
install_type (required) X X
local_customization X X
no_content_check X
no_master_check X
package X
root_device X X

The steps to create Differential Flash Archive are as follows:

1. Prepare the master system with changes. Before changes are made,
the master system should be running a duplicate of the original
archive.
2. (Optional) Prepare customization scripts to reconfigure or customize
the clone system before or after installation.
3. Mount the directory of a copy of the saved-unchanged master image.
This second image is to be used to compare the two system images.
Access the image by the following methods.
● Mounted from a Solaris Live Upgrade boot environment
● Mounted from a clone system over NFS
● Restored from backup by using the ufsrestore comman
4. Create the differential archive with the -A option of the flar
create command.
5. Install the Differential Archive on clone systems with custom
JumpStart. Or, you can use Solaris Live Upgrade to install the
differential archive on an inactive boot environment.

Exercise: Creating a Flash Archive

In this lab, you will create a Flash archive of specific directory contents.
Preparation
The following tasks require a system that is running the Solaris 10 Update
1 OS.
Task
This task has you use the flarcreate command along with some
additional options as a means of giving you practice with customizing a
Flash archive.
Create a Flash archive that excludes all of the following directories:

● /usr/bin/
● /usr/share/
● /var/apache/htdocs/flashdir/
● /var/sadm/pkgs/
● /usr/sfw/
● /usr/openwin/
● /usr/perl5/
● /usr/dt/
● /usr/apache2/
● /usr/staroffice7/
In addition, include /usr/bin/cat command, skip the disk space check

and ignore the integrity check.
Create a file that lists the directories and files to exclude and include. Use
the plus (+) and minus (-) signs when creating the file.
Remove this flar file after you complete this task.

Note – Do not use this flar for any other purpose in this course.

Exercise Summary
Exercise Summary

discoveries you had during the lab exercise.
!
?
Manage the discussion based on the time allowed for this module. If you do not have time to spend on
discussion, highlight just the key concepts students should have learned from the lab exercise.
● Experiences
● Interpretations
● Conclusions
● Applications

Exercise Solutions
Exercise Solutions
This section provides the answers to the exercise tasks.
Creating a Flash Archive

This task has you use the flarcreate command along with some
additional options as a means of giving you practice with customizing a
Flash archive.
Create a Flash archive that excludes all of the following directories:

● /usr/bin/
● /usr/share/
● /var/apache/htdocs/flashdir/
● /var/sadm/pkgs/
● /usr/sfw/
● /usr/openwin/
● /usr/perl5/
● /usr/dt/
● /usr/apache2/
● /usr/staroffice7/
In addition, include /usr/bin/cat command, skip the disk space check

and ignore the integrity check.
Steps to create a custom Flash archive:

1. Create a file that lists the directories and files to exclude and include.
Use the plus (+) and minus (-) signs when creating the file.
# vi filelist
- /usr/bin/
- /usr/share/
- /var/apache/htdocs/flashdir/
+ /usr/bin/cat
- /var/sadm/pkgs/
- /usr/sfw/
- /usr/openwin/
- /usr/perl5/
- /usr/dt/

Exercise Solutions
- /usr/apache2/
- /usr/staroffice7/
2. Check the disk size of the drives. The Flash archive you create
requires 1.73 Gbytes of free space in some filesystems. If the primary
disk does not have enough free space, create and mount a suitable
filesystem on the second disk.
# df -h /a
/dev/dsk/c1t1d0s7 26G 4.7G 21G 19% /a
3. Create the Flash archive after arranging for the destination file
system to use to hold it.
# flarcreate -n solaris10 -S -I -z filelist /a/test.flar
Verify the command worked by listing all of the files within the Flash
archive that contain the string bin/cat.
# flar info -l /a/test.flar |grep -i bin/cat
usr/bin/catman
usr/apache/tomcat/bin/catalina.sh
usr/bin/cat
usr/bin/cat
4. Remove the flar file.
# rm /a/test.flar
Note – Do not use this flar for any other purpose in this course.

Module 19
Using Live Upgrade
Objectives
● Create an alternate boot environment cloned from a running system
● Create a differential flash archive in a Live Upgrade boot
environment
● Create an empty alternative boot environment and understand when
this is necessary
● Extend a base boot environment with a differential flash archive
19-1
Objectives
Relevance
Discussion – The following questions are relevant to understanding how

to leverage the Live Upgrade feature of the Solaris 10 OS:
!
? ● How can I upgrade my system with the minimum amount of
downtime and the maximum amount of safety?
● How can I upgrade my system using Live Upgrade technology and
differential flash archives?


● Solaris 10 Installation Guide: Solaris Live Upgrade and Upgrade Planning
Guide at docs.sun.com:
http://docs.sun.com/app/docs/doc/817-5505/6mkv5m1kg?a=view
Using Live Upgrade 19-3

Introducing 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. Alternatively, 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 Live Upgrade enables you to duplicate a boot environment

without affecting the currently running system. You can then do the
following:
● Upgrade a system.
● Change the current boot environment's disk configuration to
different file system types, sizes, and layouts on the new boot
environment.
● Maintain numerous boot environments with different images. For
example, you can create one boot environment that contains current
patches and create another boot environment that contains an
Update release.
Take a moment and share a browser session for all to see and point out key documentation on Live Update
at docs.sun.com. Search for Solaris 10 Installation Guide: Solaris Live Upgrade and Upgrade Planning which
is located at:
http://docs.sun.com/app/docs/doc/817-5505?q=Live+Update
If you are teaching this class as an LVC, engage a student by having them do the above.

Solaris Live Upgrade Process

The process of using Live Upgrade to upgrade a Solaris system includes
the following general phases:
● Creating an alternate boot environment (ABE) by cloning a current
Solaris OS instance. The source for this cloning could also be a flash
archive.
● Changing the state of the system in the ABE for reasons including
the following:
● Upgrading to another OS release
Explain how this could be part of the strategy to adopt and incorporate monthly Solaris Express upgrades.
● Updating a release with patches or updates

● Activating the new boot environment (BE)
● Optionally falling back to the original BE.
Multiple Release Compatibilty
The release of the Solaris Live Upgrade packages must match the release
of the OS you are upgrading to. For example, if your current OS is the
Solaris 9 release and you want to upgrade to the Solaris 10 release, you
need to install the Solaris Live Upgrade packages from the Solaris 10
release.
Note – See the following for more information about the Live Upgrade
packages and required patches:
http://docs.sun.com/app/docs/doc/817-
5505/6mkv5m1kk?q=Live+Update&a=view

Live Upgrade Commands

The following Table 19-1 briefly describes the commands used with Live
Upgrade.
Table 19-1 Live Upgrade Commands
LU Command Description
lu A deprecated curses-based menuing interface for creating and

administering boot environments.
luactivate Designate the specified boot environment as the one to boot from in
subsequent boots.
lucancel Cancel a scheduled Live Upgrade operation.
lucompare Compare the contents of two boot environments.
lucreate Create a boot environment.
lucurr Display the name of the currently booted boot environment.
ludelete Delete a boot environment.
lufslist List the file systems of a specified boot environment.
lumake Re-create a boot environment based on the current boot
environment.
lumount/ Mount/unmount file systems of a specified boot environment.
luumount
lurename Rename a boot environment.
lustatus For every boot environment, list whether a boot environment is
active, active upon the next boot, in the midst of a copy operation,
and if a copy operation is scheduled for it.
luupgrade Modify a boot environment by installing flash archives, installing a
complete OS, installing and/or deleting OS and application
packages, or installing OS patches.

Example Procedure: Live Upgrade and Differential

Flash Archives
Set a context for the students about this module. Live Upgrade is an involved techology that can be applied
to many varying configurations. This module is not intended to be exhaustive. The approach taken in this
module is to use this example to cover the basic operations and functions of Live Upgrade and not examine
all the permutations possible. The end of the module contains a list of other, more involved topics and
variations and references into the online documentation.
The following example procedure illustrates many of the commands of

Live Upgrade. This particular procedure will illustrate:
● Creating a base master flash archive
● Creating an ABE cloned from a running system
● Creating a differential flash archive in a Live Upgrade BE
● Creating an empty ABE (-s - option) in preparation for using the
luupgrade command to clone using a base master flash archive
● Using the luupgrade command to extend the base ABE with a
differential flash archive
Creating a Master Flash Archive
Application of a differential flash archive involves first applying a base

master flash archive and then applying a differential archive.
1. Make a full flash archive of the currently running system for use as
the base master flash archive.
# mkdir /xxx ; cd /xxx
# flarcreate -S -c -n master_sys_env_1 master_sys_env_1.flar
This flash archive will not be used until later in this procedure. It
will be used to initially install a client system after which a
differential flash archive will be installed on that client to extend its
installed state.
Explain all the options used. -S dispenses with the time consuming size calculation that gets written into the
flash archive header. -c is to compress the archive.
2. Check the administrative information stored in the flash archive.

# flar info master_sys_env_1.flar
archive_id=bce4466c276e17fde18d0ebaccd44615
creation_master=sys-01
content_name=master_sys_env_1

creation_node=sys-01
creation_platform=SUNW,UltraAX-i2
...
type=FULL
Point out that the type is FULL.
Cloning an Alternate Boot Environment From a Running System
In this part of the procedure a new boot environment (sys_env_2) will be

cloned from the currently running boot environment (sys_env_1). Refer to
Figure 19-1. The single root file system will be copied over. The swap and
/export/home partitions will be part of each boot environment.
sys_env_1 sys_env_2
c1t0d0 c1t1d0
Copy
root (/) root (/)
0 0
1 /swap 1
3 3
4 4 Current release X
Critical file system root (/)
5 5
Inactive release X
6 6 Critical file systems root(/)
7 /export/home 7 Shared file systems
Active
Figure 19-1 Cloning a New Boot Environment From a Running System
3. Prepare disk space for an alternate boot environment. By first

examining the partitioning of disk 1, where the current boot
environment is installed:
...

* First Sector Last

0 2 00 2097414 67963725 70061138 /
1 3 01 0 2097414 2097413
2 5 00 0 71127180 71127179
4 0 00 70061139 8667 70069805
5 0 00 70069806 8667 70078472
7 8 00 70078473 1048707 71127179 /export/home
4. Examine the mounting of the current boot environment.

# mount
...
/ on /dev/dsk/c1t0d0s0 ...
/export/home on /dev/dsk/c1t0d0s7 ...
...
5. Partition the second disk to be identical to the first so that it can be
used for the ABE.
# /usr/sbin/prtvtoc /dev/rdsk/c1t0d0s2 | /usr/sbin/fmthard -s - \
/dev/rdsk/c1t1d0s2
fmthard: New volume table of contents now in place.
Note – Having partitioning the same on both disks is a requirement for

this example only. Live Upgrade can be used to implement partitioning
changes. For example, if the original system has separate partitions and
file systems for /, /usr and /var, the new enviroment can merge all of
them into one partition and one file system.
6. Check that the partitioning on the second disk matches that of the
first disk.
*
...
* First Sector Last

0 2 00 2097414 67963725 70061138
1 3 01 0 2097414 2097413
2 5 00 0 71127180 71127179
4 0 00 70061139 8667 70069805
5 0 00 70069806 8667 70078472
7 8 00 70078473 1048707 71127179
7. Create the alternative boot environment with these specifications:

● Name the current boot environment sys_env_1

● Name the new boot environment sys_env_2
● Arrange that /export/home will be shared between the
environments
● Match the file system - partition assignments for both
environments
# lucreate -c "sys_env_1" -m /:/dev/dsk/c1t1d0s0:ufs -n "sys_env_2"
Discovering physical storage devices

Discovering logical storage devices
Cross referencing storage devices with boot environment configurations
Determining types of file systems supported
Validating file system requests
Preparing logical storage devices
Preparing physical storage devices
Configuring physical storage devices
Configuring logical storage devices
Analyzing system configuration.
No name for current boot environment.
Current boot environment is named <sys_env_1>.
Creating initial configuration for primary boot environment <sys_env_1>.
The device </dev/dsk/c1t0d0s0> is not a root device for any boot
environment.
PBE configuration successful: PBE name <sys_env_1> PBE Boot Device
</dev/dsk/c1t0d0s0>.
Comparing source boot environment <sys_env_1> file systems with the file
system(s) you specified for the new boot environment. Determining which
file systems should be in the new boot environment.
Updating boot environment description database on all BEs.
Searching /dev for possible boot environment filesystem devices
Updating system configuration files.

environment.
Creating configuration for boot environment <sys_env_2>.
Source boot environment is <sys_env_1>.
Creating boot environment <sys_env_2>.
Creating file systems on boot environment <sys_env_2>.
Creating <ufs> file system for </> on </dev/dsk/c1t1d0s0>.
Mounting file systems for boot environment <sys_env_2>.
Calculating required sizes of file systems for boot environment
<sys_env_2>.
Populating file systems on boot environment <sys_env_2>.
Checking selection integrity.

Integrity check OK.

Populating contents of mount point </>.
Copying.
Creating shared file system mount points.
Creating compare databases for boot environment <sys_env_2>.
Creating compare database for file system </>.
Updating compare databases on boot environment <sys_env_2>.
Making boot environment <sys_env_2> bootable.
Population of boot environment <sys_env_2> successful.
Creation of boot environment <sys_env_2> successful.
Explain the command line options as necessary. The -c option is used only once, to name the first
environment. Explain that the absence of a -m option instance for the /export/home file system is what
configures it to be shared in both BEs.

8. Examine both boot environments with the lufslist command.

# lufslist sys_env_1
boot environment name: sys_env_1

This boot environment is currently active.
This boot environment will be active on next system boot.
Filesystem fstype device size Mounted on Mount

Options
-----------------------------------------------------------------------
/dev/dsk/c1t0d0s1 swap 1073875968 - -
/dev/dsk/c1t0d0s0 ufs 34797427200 / -
/dev/dsk/c1t0d0s7 ufs 536937984 /export/home -
# lufslist sys_env_2
boot environment name: sys_env_2
Filesystem fstype device size Mounted on Mount

Options
-------------------------------------------------------------------------
/dev/dsk/c1t0d0s1 swap 1073875968 - -
/dev/dsk/c1t1d0s0 ufs 34797427200 / -
/dev/dsk/c1t0d0s7 ufs 536937984 /export/home -
Note that in the sys_env_2 environment listing, /export/home still shows

on the first disk, c1t0d0. This is also true for swap. This is because both
swap and /export/home are being shared between the two environments;
they were not cloned to the new BE. Only the root file system shows on
the second disk, c1t1d0s0. (When the source of the cloning contains
separate file systems for /, /usr, /var, or /opt, these critical file systems
are required for the new boot environment and therefore will be copied.)

9. Use the lustatus command to check the status of the boot

environments.
# lufsstatus
Boot Environment Is Active Active Can Copy

Name Complete Now On Reboot Delete Status
-------------------------- -------- ------ --------- ------ ----------
sys_env_1 yes yes yes no -
sys_env_2 yes no no yes -
Note that sys_env_1 is currently active and will be in effect on next

system boot. The sys_env_2 BE has been cloned and therefore
complete but not now active.
10. View the contents of the compare file created in /etc/lu/compare.
# cd /etc/lu/compare
# ls
sys_env_1:sys_env_2
# more sys_env_1:sys_env_2
/:root:root:22:40755:DIR:
/lost+found:root:root:2:40700:DIR:
/export:root:sys:3:40755:DIR:
/var:28385:100:44:40775:DIR:
/var/sadm:root:other:13:40755:DIR:
/var/sadm/install:root:bin:4:40555:DIR:
/var/sadm/install/admin:root:bin:2:40555:DIR:
...
This step is just to make students aware that a comparison of environments is maintained.
11. Activate the sys_env_2 environment with the luactivate

command.
# luactivate sys_env_2
**********************************************************************
The target boot environment has been activated. It will be used when you
reboot. NOTE: You MUST NOT USE the reboot, halt, or uadmin commands. You
MUST USE either the init or the shutdown command when you reboot. If you
do not use either init or shutdown, the system will not boot using the
target BE.
**********************************************************************

In case of a failure while booting to the target BE, the following

process needs to be followed to fallback to the currently working boot
environment:
1. Enter the PROM monitor (ok prompt).
2. Change the boot device back to the original boot environment by

typing:
setenv boot-device /pci@1f,0/pci@1/scsi@8/disk@0,0:a
3. Boot to the original boot environment by typing:
boot
**********************************************************************
Activation of boot environment <sys_env_2> successful.
Stress the importance of this information that indicates the original boot device. If the need would arise, you
may have to set the OBP boot-device variable to get the original environment to boot.
12) Use the lustatus command to see the change in status.

# lustatus
-------------------------- -------- ------ --------- ------ ----------
sys_env_1 yes yes no no -
sys_env_2 yes no yes no -
Note that the sys_env_2 environment is not yet active. It will
become active on the next boot, however, because the boot-device
OBP variable has been configured for the new environment. Make
note of the procedure for booting the original environment as output
in the lucreate command in case the new environment doesn't boot
properly.
12. Use the init 6 command to finish making sys_env_2 the currently
running environment.
# init 6
13. When the system comes back up, login and verify that the sys_env_2
environment is active with the lustatus command.
# lustatus


-------------------------- -------- ------ --------- ------ ----------
Modifying the State of the New Boot Environment
As explained in the Live Upgrade process summary earlier in the module,

the state of the system can be changed in many ways depending on your
reasons for implementing Live Upgrade. It could be to implement the
next Solaris Express release or applying a set of updates/patches.
In this example and referring to Figure 19-2, a simple modification will be

made for instructional purposes. A simple package will be added. When a
differential archive is created later in this procedure, the difference
captured in that archive will be the inclusion of this package.
sys_env_1 sys_env_2
c1t0d0 c1t1d0
root (/) root (/)

0 0
1 /swap 1
3 3
4 4 Current release X
5 5
Inactive release X
6 6 Critical file systems root(/)
7 /export/home 7 Shared file systems
Modified
Figure 19-2 Modified Boot Environment
14. Modify the system state of the sys_env_2 environment by adding the
SMCtop package to the system.
# cd /var/spool/pkgs
# pkgadd -d .
The following packages are available:

1 SMCtop top
(sparc) 3.5.1

Select package(s) you wish to process (or 'all' to process

all packages). (default: all) [?,??,q]: 1
...
15. Verify that the new package as been added.
# pkginfo -l SMCtop
PKGINST: SMCtop
...
16. Use the lucompare command to compare the two boot
environments.
This step is optional and time consuming.
# lucompare -t -o ./environ_compare_2_to_1 sys_env_1

Determining the configuration of "sys_env_1"...
Comparing / ...
17. Examine the first few lines of the compare file to see the type of
information it contains.
# more environ_compare_2_to_1
< sys_env_2
> sys_env_1
Sizes differ
01 < /var/sadm/install/contents:root:root:1:100644:REGFIL:22638869:
02 > /var/sadm/install/contents:root:root:1:100644:REGFIL:22637090:
Checksums differ
01 <
/var/sadm/install/.lockfile:root:root:1:100600:REGFIL:128:1845941275:
02 >
/var/sadm/install/.lockfile:root:root:1:100600:REGFIL:128:582217747:
Sizes differ
01 < /var/sadm/pkg/SUNWcsu/pkginfo:root:root:1:100644:REGFIL:7214:
02 > /var/sadm/pkg/SUNWcsu/pkginfo:root:root:1:100644:REGFIL:5897:
...

Creating a Differential Archive Using Live Upgrade Boot

Environments
In this section of the procedure a differential flash archive is created

capturing the changes between the original system and the evolved
system as illustrated in Figure 19-3.
sys_env_1 sys_env_2
c1t0d0 c1t1d0
root (/)
/a 0
Mount
1
root (/)
0
3
Create 1 /swap
Differential 4 Current release X
Flash Archive 3 Critical file system root (/)
5
4 Inactive release X
6 Critical file systems root(/)
5
7 Shared file systems
6
7 /export/home
Figure 19-3 Creating a Differential Flash Archive in the Live Upgrade

Environment
18. Prepare to create a differential flash archive be mounting the inactive

environment (sys_env_1) on /a in the active environment with the
lumount command.
# mkdir /a
# lumount sys_env_1 /a
/a
19. Use the mount command to see the original environment mounted.
# mount
...
/a on /dev/dsk/c1t0d0s0 ...
...

20. Create a differential archive which captures the difference between

the current active environment and the inactive sys_env_1
environment mounted on /a. Exclude the flash archive (-x /a/xxx)
that was created in the beginning of this procedure which now
resides in the /a/xxx/ directory. Call the new differential archive
differ_flar_on_sys_env_1_new_pkg.flar and store it in the
/a/xxx directory. Dispense with the size check (-S) and compress
the archive (-c).
# flarcreate -n differential_flash -S -c -A /a -x /a/xxx \
/a/xxx/differ_flar_on_sys_env_1_new_pkg.flar
Differential Flash
Checking integrity...
Integrity OK.
Running precreation scripts...
Precreation scripts done.
Creating the archive...
437639 blocks
Archive creation complete.
Running postcreation scripts...
Postcreation scripts done.
Running pre-exit scripts...

Pre-exit scripts done.
21. Use the flar info command to see the administrative information
stored with the archive.
# flar info differ_flar_on_sys_env_1_new_pkg.flar
archive_id=c04e27bfc16c1c32cfa04cfa359217d6
creation_master=sys-01
content_name=differential_flash
creation_node=sys-01
creation_platform=SUNW,UltraAX-i2
creation_release=5.10
creation_os_name=SunOS
creation_os_version=Generic_118822-25
type=DIFFERENTIAL
Point out that this time the type for the archive is DIFFERENTIAL.

Applying a Differential Flash Archive Using Live Upgrade BEs
The next section of this procedure demonstrates one way of applying a

differential archive. Typically this will involve installing a client with the
original flash archive made at the beginning of the procedure and then
extending that client's installed state by applying the differential archive.
In this example however, Live Upgrade will be used on the same system
to make a blank or empty third boot environment (-s - option) which will
be upgraded to the an initial installed state using the master flash archive
and then extended using the differential flash archive. Figure 19-4
illustrates the boot environments involved.
sys_env_1 sys_env_2 sys_env_3
c1t0d0 c1t1d0 c2t0d0
root (/) root (/) Empty

0 0 0
1 /swap
1 1
3 3 3
4 Install Master
4 4
and
Differential
5 5 5
Flash Archives
6 6 6
7 /export/home 7 7
Current release X
Inactive release X
Critical file systems root(/)
Shared file systems
Figure 19-4 Applying Flash Archives to a Boot Environment
22. Prepare a third disk by partitioning it like the others.

# /usr/sbin/prtvtoc /dev/rdsk/c1t1d0s2 | /usr/sbin/fmthard -s - \
/dev/rdsk/c2t0d0s2
fmthard: New volume table of contents now in place.
During this development of the course it was learned that the disks have to be the same size otherwise you
get an fmthard error duing the luupgrade step shown later.

23. Before making the new boot environment, unmount /a with the
luumount command.
# luumount /a
24. Create a new boot environment with the following specifications:
● use c2t0d0
● do not clone a boot environemnt. Use the -s - option to make it
empty
● name the new boot environment sys_env_3
When prompted for the / and swap devices via the menu, select
those devices appropriate for the new boot environment that is being
created.
# lucreate -n "sys_env_3" -s -
...
Updating system configuration files.
...
Since lucreate cannot determine the new / device on its own, the
menu appears and you need to specify, with the F2, ENTER and F3
keys, the /ans swap devices:
Active boot environment - None
Mount Point Device FS Type Size (MB) % Used
-------------------------------------------------------------------------
New boot environment - sys_env_3
Recommended
Mount Point Device FS Type Size (MB) Min
Size(MB)
/ ufs 0
- swap 0
Esc F2 F3 F4 F5 F6 F7 F8 F9 ^D ^X
HELP CHOICE SAVE SLICE PRINT CANCEL SCHEDULE SPLIT MERGE CLR OTHR
In this example, for the above menu interaction, c2t0d0s0 was
specified for the / device and c2t0d0s1 was specified for the swap
device. The F2 key is used to display a drop down menu from which
to select the devices (using the ENTER key). When finished, the F3
key is used to save the configuration and then the menu exits and
output continues.


environment.
Creating <ufs> file system for </> on </dev/dsk/c2t0d0s2>.
Creation of boot environment <sys_env_3> successful.
Note – The menu appeared because the root file system location was not
specified on the lucreate command line. The menu would not have
appeared if this command were used instead:
# lucreate -n "sys_env_3" -s - -m /:/dev/dsk/c2t0d0s0:ufs
25. Use the lustatus command to see all statuses for the boot
environments.
# lustatus
-------------------------- -------- ------ --------- ------ ----------
sys_env_3 no no no yes -
Note how sys_env_3 is not complete. It is empty or blank.

26. Make the master archive and differential archive images available on
the local file system. (The archive was saved in the sys_env_1 BE and
needs to be copied to the current sys_env_2 BE).
# mount /dev/dsk/c1t0d0s0 /a
# cd /a/xxx
# cp master* diff */
# umount /a
27. Make an install image accessible.
# mkdir /net2
# mount 192.168.201.1:/export/install /net2
# mount
...
/net2 on 192.168.201.1:/export/install...
...
At the time of development of this course, it was necessary to be sure that the install image referenced
matched was Solaris 10 U1 (not FCS). At the time this was because the Solaris 10 FCS install image was
missing a merge script needed by the luupgrade command executed in the next step.

28. Use the luupgrade command to populate the new sys_env_3 BE

with the master full flash archive. First use dry run method (-N).
# luupgrade -f -n sys_env_3 -s /net2/SunOS5.10_0106_sun4 -a \
/master_sys_env_1.flar -N -l /errorlog
Validating the contents of the media </net2/SunOS5.10_0106_sun4>.
The media is a standard Solaris media.
Validating the contents of the miniroot
</net2/SunOS5.10_0106_sun4/Solaris_10/Tools/Boot>.
Locating the flash install program.
Checking for existence of previously scheduled Live Upgrade requests.
Constructing flash profile to use.
Creating flash profile for BE <sys_env_3>.
Performing the operating system flash of the BE <sys_env_3>.
Execute Command:
</net2/SunOS5.10_0106_sun4/Solaris_10/Tools/Boot/usr/sbin/install.d/pfins
tall -L /a -p / -t /tmp/.luupgrade.translist.tmp.24446 -o
/net2/SunOS5.10_0106_sun4/Solaris_10/Tools/Boot
/tmp/.luupgrade.profile.flash.24446>.
29. Run the luupgrade command again but this time without the dry
run option.
# luupgrade -f -n sys_env_3 -s /net2/SunOS5.10_0106_sun4 -a \
/master_sys_env_1.flar -l /errorlog
Creating flash profile for BE <sys_env_3>.
Performing the operating system flash install of the BE <sys_env_3>.
CAUTION: Interrupting this process may leave the boot environment
unstable or unbootable.
...
Extracting Flash Archive: 100% completed (of 4640.55 megabytes)
The operating system flash install completed.
The Live Flash Install of the boot environment <sys_env_3> is complete.

30. Use the lustatus command to check the status of the new
environment.
# lustatus
-------------------------- -------- ------ --------- ------ ----------
Note that now sys_env_3 shows being complete, but still not active.
31. Create a profile file to reference in for applying the differential
archive.
# cat /profile
install_type flash_update
archive_location local_file /differ_flar_on_sys_env_1_new_pkg.flar
no_content_check
no_master_check
Go over the contents of the profile file as needed. The no_content_check and no_master_check
keywords are helpful when you are sure of the origin of the master archive previously applied and want to
dispense with minor comparison errors that may prevent a successful application of the differential archive.
32. Use the luupgrade command to apply the differential flash archive
to the new sys_env_3 BE. Reference the profile just created.
# luupgrade -f -n sys_env_3 -s /net2/SunOS5.10_0106_sun4 -j /profile \
-l /errorlog
Performing the operating system flash update of the BE <sys_env_3>.
CAUTION: Interrupting this process may leave the boot environment
unstable or unbootable.
Extracting Flash Archive: 100% completed (of 162.01 megabytes)
The operating system flash update completed.
The Live Flash Update of the boot environment <sys_env_3> is complete.

33. Check the status of the BE.
# lustatus

-------------------------- -------- ------ --------- ------ ----------

34. Make sys_env_3 active.

**********************************************************************
The target boot environment has been activated. It will be used when you
reboot. NOTE: You MUST NOT USE the reboot, halt, or uadmin commands. You
MUST USE either the init or the shutdown command when you reboot. If you
do not use either init or shutdown, the system will not boot using the
target BE.
**********************************************************************
In case of a failure while booting to the target BE, the following

process
needs to be followed to fallback to the currently working boot
environment:
1. Enter the PROM monitor (ok prompt).
2. Change the boot device back to the original boot environment by

typing:
setenv boot-device /pci@1f,0/pci@1/scsi@8/disk@1,0:a
3. Boot to the original boot environment by typing:
boot
**********************************************************************
Activation of boot environment <sys_env_3> successful.
35. Check the status now.

# lustatus

-------------------------- -------- ------ --------- ------ ----------

sys_env_2 yes yes no no -
sys_env_3 yes no yes no -
36. Since the lustatus command reports that the next system reboot
will activate the sys_env_3 BE, note the procedure to fall back to the
current boot environment. Then, at the system console, reboot the
system with the init 6 command.
# init 6
37. When the system comes back up, use the lustatus command to
verify that the sys_env_3 BE is now active.
# lustatus
-------------------------- -------- ------ --------- ------ ----------
38. Verify that the differential archive has been applied by verifying that
the SMCtop package is included in the system.
# pkginfo -l SMCtop
PKGINST: SMCtop
...
Reverting to a previous BE
39. Make sys_env_1 the active and currently running environment

again.
# init 6
40. Use the lustatus command to verify that sys_env_1 is again active
and currently running.
# lustatus
-------------------------- -------- ------ --------- ------ ----------

Note – The ludelete be_name command will delete a boot environment.

It must first be made inactive.

Live Upgrade and Other Configurations
Live Upgrade and Other Configurations

Follow is a list of other features and capabilities of Live Upgrade and
references for further information:
● Creating a Boot Environment With RAID-1 Volume File Systems
5505/6mkv5m1kj?a=view#luoverview-7
● Creating a Boot Environment and Merging File Systems
5505/6mkv5m1lj?a=view
● Creating a Boot Environment and Splitting File Systems
5505/6mkv5m1lk?a=view
● Synchronizing Files Between Boot Environments
5505/6mkv5m1kk?q=Live+Update&a=view
● Creating a Boot Environment and Reconfiguring Swap
5505/6mkv5m1ll?a=view
● x86: Activating a Boot Environment With the GRUB Menu
5505/6mkv5m1mp?a=view

Module 20
Introducing WANBoot
Objectives
The WAN Boot procedure is an automatic installation process much like
the JumpStart installation process. It provides a mechanism for
automatically installing the Solaris 10 OS on multiple systems
simultaneously across a wide area network.

differences in WANboot Flash installation.
20-1
Objectives
Relevance
Discussion – The following question is relevant to understanding how to

use the WANBoot feature of the Solaris 10 OS:
!
? ● How can I use a install systems across a number of networks from a
single web server?


Introducing WANBoot 20-3

Introducing the Basics of WANboot (New in Solaris 9 Updates)
Introducing the Basics of WANboot (New in Solaris 9

Updates)
The WAN Boot procedure uses some of the existing JumpStart framework
but contains enhancements to security and scalability that traditional
JumpStart protocols, such as NFS, could not provide. WAN Boot supports
SPARC® platform or x86 platform servers and SPARC clients. The x86
clients are not supported.
Advantages of the WAN Boot Procedure

System administrators who need to install multiple systems connected by
a wide area network such as the Internet can use the WAN Boot
procedure to automate the installation process. The WAN Boot process
eliminates both the need for operator intervention during the installation
process and the need for a JumpStart server on the same local network as
the client.
The advantages of using the WAN Boot procedure include some of the
same advantages as using a traditional JumpStart for installations.
Advantages provided by WAN Boot include the following:
● Simplifies installations by avoiding the lengthy question-and-answer
session that is part of the interactive installation process.
● Faster than interactive installations – It lets system administrators
install different types of systems simultaneously.
● It allows automatic installation of the Solaris 10 OS and unbundled
software.
The specific advantages of WAN Boot include:

● JumpStart boot services are not required to be on the same subnet as
the installation client.
● WAN Boot client and server can authenticate using SHA hash
algorithms.
● Client download of the Solaris 10 OS can be performed using
HTTPS. WAN Boot provides a secure, scalable process for the
automated installation of systems anywhere the client and server can
connect to the Internet or other WANs.

Features
WAN Boot is part of the Solaris 10 OS but works with a minimum of
OpenBoot programmable read-only memory (PROM) firmware version
4.14 to support new requirements on the client. If a minimum of
OpenBoot PROM revision 4.14 or later is not available, WAN Boot may be
performed with a CDROM-based installation. The new firmware supports
TCP/HTTP connections, SHA-1 authentication, 3DES or AES encryption,
SSL v3 certificates, and several new values and command-line arguments
to support these new features. These new features allow the client to
contact the WAN Boot server and request the download of the new boot
binary wanboot.
The wanboot download can be authenticated with an SHA-1 signature

verification and encrypted with either 3DES or AES encryption. The
wanboot program contains the information necessary to download the
root file system. This information may include certificates and private
keys for secure HTTP connections. New DHCP options provide support
for WAN Boot clients. All WAN Boot communication occurs with HTTP
or HTTPS. NFS is not used.
New features specific to the client for WAN Boot are key management,
signature verification, and new OBP arguments.
WAN Boot Changes

Previously JumpStart functioned with RARP, TFTP, and NFS protocols,
which do not scale for WAN use. These protocols also do not have the
ability to secure the installation process.
WAN Boot utilizes advanced OBP or CDROM capabilities to scale and

secure the installation process. In addition, WAN boot uses standard
HTTP or HTTPS protocols, SHA-1 signatures, and 3DES or AES
encryption to scale and secure the installation process in all scales of
network environments including the Internet.
By using HTTP/HTTPS protocols, WAN Boot requires a web server to

respond to WAN Boot client requests. Due to the nature of HTTP/HTTPS
requests, Flash archives must be available to the web server. Traditional
JumpStart images which performed a pkgadd style install over an NFS
connection do not work over WAN Boot – Flash archives are the only
format supported.

The new client-side obp-tftp package arguments are file, host-ip,

router-ip, subnet-mask, client-id, hostname, httpproxy, tftp-
retries, and dhcp-retries. The arguments are specified on the
command line or listed in the network-boot-arguments NVRAM
variable. Figure 20-1 illustrates the WAN Boot sequence and the actions
taken in each step.
Client WAN LAN

Web Install
server server
1. Boot the client

2. OBP uses configuration information to
request download of wanboot program.
3. OBP downloads and executes the
wanboot
wanboot program.
4. wanboot program requests download
of authentication and configuration
information.
Boot file system
5. Authentication and configuration
information downloaded to wanboot
program.
6. wanboot program requests download
of WANboot miniroot.
7. WANboot miniroot downloaded to
miniroot
wanboot program.
8. wanboot program loads and
executes kernel.
9. Kernel mounts authentication and
configuration information.
10. Installation program requests
download of installation files.
JumpStart Files, archive
11. Installation program installs
Solaris Flash archive.
Figure 20-1 The WAN Boot Sequence

The WAN Boot Process

1. Boot the client.
ok boot net - install
2. OBP uses configuration information to request download of wanboot
program.
The client's Internet protocol (IP) address and client ID are included
with the request to facilitate possible client-specific downloads. The
client ID is computed from the client's Media Access Control (MAC)
address and is configurable.
The download of wanboot may be accompanied by a Hashed
Message Authentication Code (HMAC) SHA-1 signature for
wanboot and Secure Sockets Layer (SSL) certificates for HTTP over
SSL (HTTPS). Any client-specific information or security keys are
obtained from the appropriate global, network, or client-specific
directories under /etc/netboot.
Secure Hash Algorithm 1 (SHA-1) signature keys and Triple Data
Encryption Standard (3DES) or Advanced Encryption Standard
(AES) encryption keys may be created and stored on the WAN Boot
server for use with the client.
The following syntax generates the keys:
# wanbootutil keygen -m
The master HMAC/SHA1 key has been generated
# wanbootutil keygen -c -o net=129.156.198.0,cid=010003BA152A42,type=sha1
A new client HMAC/SHA1 key has been generated
# wanbootutil keygen -c -o net=129.156.198.0,cid=010003BA152A42,type=3des
A new client 3DES key has been generated
The following syntax displays the keys:
#wanbootutil keygen -d -c -o net=129.156.198.0,cid=010003BA152A42,
type=sha1
7fb0895141ecfdff4b7425d0c9f9cf9626b395c8
# wanbootutil keygen -d -c -o net=129.156.198.0,cid=010003BA152A42,
type=3des
07df5e1907ef8a49a2b3c2cb9149fd62fb0b4cb3f440ba68
The keys exist somewhere under the /etc/netboot directory. The
/etc/netboot directory is hierarchical.
The global configuration data resides in /etc/netboot and is shared
with all WAN Boot clients. Any network-specific data resides in
/etc/netboot/a.b.c.d and is shared with all WAN Boot clients on
the a.b.c.d subnet.

Any client-specific data resides in /etc/netboot/a.b.c.d/

clientid and only applies to the client with the clientid on the
a.b.c.d subnet. Client-specific files take precedence over network-
specific files which take precedence over global files.
The following syntax shows an example of what might be found in
the /etc/netboot directory:
# find /etc/netboot -print
/etc/netboot
/etc/netboot/keystore
/etc/netboot/129.156.198.0
/etc/netboot/129.156.198.0/keystore
/etc/netboot/129.156.198.0/010003BA152A42
/etc/netboot/129.156.198.0/010003BA152A42/keystore
These keys may then be stored in the client's OpenBoot PROM (OBP)
or entered on the OBP command line.
The following syntax installs the keys on the client’s OBP:
ok set-security-key wanboot-hmac-sha1
ok set-security-key wanboot-3des
The client is booted from the network with interface settings
obtained from the OBP, the command line, Dynamic Host
Configuration Protocol (DHCP), or the CDROM. Arguments
specified on the command line take precedence over the OBP
variable. A URL value in the file argument means OBP should
execute WAN Boot.
The following syntax shows setting the network parameters in the
OBP:
ok setenv network-boot-arguments
host-ip=129.156.198.25,router-ip=129.156.198.1,subnet-mask=255.255.255.0,
hostname=WANBootclient1,file=http://145.168.198.2/cgi-bin/wanboot-cgi
3. OBP downloads and executes the wanboot program.
The client contacts the wanboot-cgi program on the WAN Boot
server to download the wide area network boot program, wanboot,
from the server using Hyper Text Transfer Protocol (HTTP). The
wanboot program is the boot file system. The wanboot binary must
exist in a location under the web server's documents directory. For
example:
/var/apache/htdocs/wanboot10/wanboot

The client creates a virtual disk in random access memory (RAM)

and writes wanboot to the ramdisk as it is received. If an SHA-1
signature is used, the hash is computed as data is received and if
encryption is used, the client decrypts the data and rewrites it to the
ramdisk.
When the download is complete, the client reads the trailing hash
signature and compares it to the computed hash. The signature is all
zeros if no hash has been created for wanboot. If the downloaded
hash and the computed hash are the same, the download is assumed
to be uncompromised and the wanboot process continues. The client
then mounts the boot file system.
4. The wanboot program requests download of authentication and
configuration information.
The wanboot binary then parses the wanboot.conf file in the correct
location under /etc/netboot to retrieve the rootserver and
rootpath values. The wanboot program uses these values to create
the HTTP/HTTPS URL for requesting the root file system called
miniroot. The wanboot program uses the URL to request the client's
root file system metadata from the wanboot-cgi program on the
WAN Boot server.
5. Authentication and configuration information is downloaded to the
wanboot program.
The metadata consists of the miniroot size and hash signature. The
download may be HMAC SHA-1 signed and 3DES or AES
encrypted.
6. The wanboot program requests download of the WANBoot
miniroot.
The wanboot program uses the URL to request the client's root file
system from the wanboot-cgi program on the WAN Boot server.
7. WANBoot miniroot is downloaded to the wanboot program.
The wanboot process downloads miniroot from the WAN Boot
server and writes it to a ramdisk. If an SHA-1 signature is used, the
hash is computed as data is received. If encryption is used, the client
decrypts the data and rewrites it to the ramdisk.
When the download is complete, the client reads the trailing hash
signature and compares it to the computed hash. The signature is all
zeros if no hash has been created for the root file system. If the
downloaded hash and the computed hash are the same, the
download is assumed to be uncompromised and the wanboot
process continues.

8. The wanboot program loads and executes the kernel.
The wanboot unmounts the boot file system and mounts the miniroot
file system. The kernel from miniroot is then loaded into RAM and
executed.
9. The installation program requests download of the installation files.
The system.conf file in the appropriate location under
/etc/netboot is included with the miniroot and has the locations
of the JumpStart configuration files. The following example shows
the entries in system.conf:
SsysidCF=https://WANBootserv/bootfiles/config
SjumpsCF=https://WANBootserv/bootfiles/config
The JumpStart profile file specifies where to get the Flash archive to
install on the client. The following syntax shows part of the contents
of the JumpStart profile file:
archive_location https://WANBootserv/flashdir/solaris.flar
10. The installation program installs the Solaris Flash archive.
The Flash archive is downloaded and installed on the client.

WAN Boot Server Configuration

Use Figure 20-2 as a reference to help understand where the various files
are located when configuring a WANBoot server.
root (/) Apache will start at boot if this file exists

and has the correct configuration
etc
apache Three
httpd.conf The client parses the information to find
boot root_server and root_file values
netboot
wanboot.conf Five
The client requests location of configuration
system.conf information
var
apache Four
htdocs The wanboot program on client requests
wanboot download of miniroot (approx 200 MB)
miniroot
wanboot
Two
install The client downloads the wanboot
Solaris_10 program (approx 1 MB)
... Seven
flash The client extracts the flash archive
solaris.flar
index.html
config The default file a web browser gets from
check this server
rules Six
The client gets identity info and
profile installation profile
sysidcfg One
The client asks the wanboot-cgi program
cgi-bin
for the location of the wanboot file
wanboot-cgi
bootlog-cgi
The client uses this cgi program to send
back log messages
Figure 20-2 WANBoot Server Configuration File Locations

Configuring a WAN Boot server involves the following three components:

● Configuring the web server
● Configuring the optional DHCP server
● Configuring the JumpStart server
WAN Boot requires a Solaris 10 SPARC or x86 server platform with a web
server supporting at least HTTP 1.1 and also supporting HTTPS if digital
certificates are used. Apache and iPlanet servers have been tested.
If HTTPS is used, the SSL must be configured. WAN Boot requires access
to wanboot, miniroot, custom JumpStart files, and the Flash archive(s).
These are typically stored in the web servers document root directory. It
also requires access to wanboot-cgi and bootlog-cgi programs to serve
CGI requests from WAN boot clients. These are typically stored in the
web server’s cgi-bin directory.
Configuring these components involves two significant problems that are

beyond Sun's control and outside the scope of this module. The first
problem is that even in an all-Sun installation, the administrative tools
used to configure the various parts of the WAN Boot server do not
communicate with each other. For example, add_install_client does
not add macro definitions for a given client to the dhcp_inittab(4) file
but instead creates information that the administrator must manually
incorporate. A second and more difficult problem to control is the fact that
heterogeneous customer environments (wherein the three services might
be supplied by three or more different vendors) are very common.
Thus one finds administrative scripts that, when used, ask the
administrator to perform a second action on a (possibly) different
machine.
Although the steps to configure a WAN Boot server are different than
setting up a JumpStart server, anyone who has configured a JumpStart
server should be able to configure a WAN boot server. Reference the
following URL:
http://docs.sun.com/db/doc/817-5504
To configure the WAN Boot server:

1. Set up the WAN Boot server as a web server with HTTP 1.1 support.
Use the following URLs for information:
● Sun Java™ System web server information:

http://docs.sun.com
http://docs.sun.com/source/816-5683-10/contents.htm
● Apache web server configuration information:
http://httpd.apache.org/docs-project/
2. Optionally, configure the WAN Boot server as a DHCP server. Two
new vendor options support WAN Boot:
● SbootURI Symbol Vendor=SUNW.Sun-Blade-100 <other
architectures>,16,ASCII,1,0
● SHTTPproxy Symbol Vendor=SUNW.Sun-Blade-100 <other
architectures>,17,ASCII,1,0
WAN Boot install clients are named using a network number-client
ID combination that is designed to be unique (client IDs are required
to be unique per network). DHCP originally used this naming
scheme and it works well with the framework of WAN Boot.
3. Configure the WAN Boot server as a JumpStart server. Use the
following URL:
http://docs.sun.com/db/doc/817-5506
The wanboot program must be copied from install media to a
location under the web server's documents directory:
# cp /cdrom/cdrom0/s0/Solaris_10/Tools/Boot/platform/sun4u/wanboot \
/var/apache/htdocs/wanboot10/wanboot
The WAN Boot miniroot file system must be created in a location
under the web server's documents directory:
# /cdrom/cdrom0/s0/Solaris_10/Tools/setup_install_server -w `pwd`/wpath \
`pwd`/ipath; cp `pwd`/wpath/miniroot
/var/apache/htdocs/wanboot10/miniroot
The URL paths to the sysidcfg file, rules.ok file, profile file, and
begin and finish scripts are specified by the SsysidCF and SjumpsCF
parameters in the system.conf file on the miniroot:
SsysidCF=https://WANBootserv/bootfiles/config
SjumpsCF=https://WANBootserv/bootfiles/config

Alternatively, you can use DHCP with the new vendor options SbootURL
and SHTTPproxy. Use the SbootURL option to specify the location of the
wanboot-cgi script. This option is preferable to using the standard
BootFile option. Use the SHTTPproxy option to define the HTTP or
HTTPS proxy if one is to be used. The wanboot and miniroot file systems
must each be small enough to fit into the client's RAM. WAN Boot
requires the same JumpStart files needed for an NFS install, including a
Solaris Flash archive, a sysidcfg file, a rules.ok file, and a profile file.
The JumpStart files (Solaris Flash archive, sysidcfg, rules.ok, and
profile) must be accessible to the web server. Copy these files to a
location under the web server's documents directory:
# cp /export/config /var/apache/htdocs/wanboot10/config
The archive_location keyword in the profile should contain the URL to

the Flash archive:
archive_location https://WANBootserv/flashdir/solaris.flar
The wanboot.conf file must be created and put in the appropriate

subdirectory under /etc/netboot:
● The file /etc/netboot/wanboot.conf is global.
● The subdirectory /etc/netboot/a.b.c.d/wanboot.conf is
network specific.
● The subdirectory
/etc/netboot/a.b.c.d/clientid/wanboot.conf is client specific.
● The file /etc/inet/wanboot.conf.sample is an example file.
● The binary /usr/sbin/bootconfchk is used to check the integrity
of the wanboot.conf file.
The /etc/netboot directory contains configuration information, keys,

certificates, wanboot.conf, and system.conf which is used by wanboot-
cgi to create the boot file system. The /etc/netboot directory must be
created and populated by the system administrator and needs to be
owned or at least readable by the web server user. The /etc/netboot
directory is hierarchical.
The global configuration data resides in /etc/netboot and is shared with

all WAN Boot clients. Network-specific data resides in /etc/netboot/
a.b.c.d and is shared with all WAN Boot clients on the a.b.c.d subnet.
Client-specific data resides in /etc/netboot/a.b.c.d/clientid and

only applies to the client with the clientid on the a.b.c.d subnet.

All of the directories can contain the following files:

● wanboot.conf – the client configuration file for WAN Boot
installation
● system.conf – the configuration file specifying the location of the
client's sysidcfg file and custom JumpStart files
● keystore – the file containing client SHA-1 hashing key, 3DES or
AES-128 encryption key, and an optional SSL private key
● truststore – the file containing the digital certificates of certificate
signing authorities that the client can trust
● certstore – the file containing the client's digital certificate
Client-specific files take precedence over network-specific files which take

precedence over global files.
An example directory structure would look like the following:

/etc/netboot
/etc/netboot/129.156.198.0
/etc/netboot/129.156.198.0/010003BA152A42
/etc/netboot/129.156.198.0/010003BA152A42/truststore
/etc/netboot/129.156.198.0/010003BA152A42/certstore
/etc/netboot/129.156.198.0/010003BA152A42/system.conf
/etc/netboot/129.156.198.0/010003BA152A42/wanboot.conf
/etc/netboot/truststore
/etc/netboot/system.conf
/etc/netboot/wanboot.conf
The wanboot.conf file contains information used to drive the WAN Boot
process. The CGI program wanboot-cgi uses information contained in
these files to determine file paths, encryption, signing policies, and other
characteristics of the operating environment. The following is a sample
available at /etc/inet/wanboot.conf.sample:
#
#
# ident"@(#)wanboot.conf.sample1.204/01/30 SMI"
####################################################################
# wanboot.conf(4): boot configuration file.
#
# Please consult wanboot.conf(4) for further information. Note that

# this interface is "Evolving" as defined by attributes(5).

#
# Anything after a '#' is comment. Values may be quoted
# (for example,"val").
#
# <empty> means there is no value, that is, null. The absence of any
# parameter implies that it takes a default value (<empty> unless
# otherwise specified).
#
# <url> is of the form http://... or https://...
####################################################################
# The path of the bootstrap file (within htdocs) which is served up
# by wanboot-cgi(bootfile).
#
boot_file=/bootfiles/wanboot# <absolute pathname>
# These are used by wanboot-cgi(bootfile|bootfs|rootfs) to determine
# whether boot_file or the bootfs is to be sent encrypted/signed, or
# root_file is to be sent signed; the client must be setup with the
# corresponding encryption/signature key(s) (which cannot be auto-
# matically verified).
#
# If an encryption_type is specified then a signature_type must also
# be specified.
#
encryption_type=3des# 3des | aes | <empty>
signature_type=sha1# sha1 | <empty>
# This is used by wanboot-cgi(bootfs) and wanboot to determine whether
# server authentication should be requested during SSL connection
# setup.
#
server_authentication=yes# yes | no
# This is used by wanboot-cgi(bootfs) and wanboot to determine whether
# client authentication should be requested during SSL connection
# setup. If client_authentication is "yes", then server_authentication
# must also be "yes".
#
client_authentication=yes# yes | no
# wanboot-cgi(bootfs) will construct a hosts file which resolves any
# hostnames specified in any of the URLs in the wanboot.conf file,
# plus those found in certificates, etc. The following parameter
# may be used to add additional mappings to the hosts file.
#
resolve_hosts=# <hostname>[,<hostname>*] | <empty>
# This is used to specify the URL of wanboot-cgi on the server on which
# the root_file exists, and used by wanboot to obtain the root server's
# URL; wanboot substitutes root_file for the pathname part of the URL.

# If the schema is http://... then the root_file will be signed if there

# is a non-empty signature_type. If server_authentication is "yes", the
# schema must be https://...; otherwise it must be http://...
#
root_server=https://host:port/cgi-bin/wanboot-cgi# <url> | <empty>
# This is used by wanboot-cgi(rootfs) to locate the path of the
# rootfs image (within htdocs) on the root_server.
#
root_file=/rootimages/miniroot# <absolute pathname> | <empty>
# This is used by wanboot to determine the URL of the bootserver
# (and whether bootlog traffic should be sent using http or https),
# or whether it should simply be sent to the console.
#
boot_logger=# <url> | <empty>
# This is used by the system startup scripts. If set, it should
# point to a file that contains name value pairs to be used at
# start up time. For example, this file may be used to provide
# install the values for sysidcfg and jumpscfg.
#
system_conf=system.conf

The following keywords are supported in wanboot.conf:

● boot_file – specifies the relative web server path to the wanboot
binary.
● root_server – specifies the location of the CGI program that will
serve up the information about the root file system to be transmitted
to the client.
● root_file – specifies the relative web server path to the WAN Boot
miniroot.
● signature_type – specifies the signing algorithm to be used if a
signature is used when transmitting components to the client. WAN
Boot currently only supports SHA-1 hash signatures.
● encryption_type – specifies the algorithm to use when encrypting
components to be transmitted to the client. WAN Boot currently only
supports 3DES and AES encryption.
● server_authentication – specifies whether server authentication
should be requested during the SSL connection setup. If
server_authentication=yes, then a truststore must exist.
● client_authentication – specifies whether client authentication
should be requested during the SSL connection setup. If
client_authentication=yes, then a certstore must exist.
● boot_logger – specifies the URL (if any) of a system to which
logging messages are sent.
● system_conf – specifies the name of a file in the /etc/netboot
hierarchy that will be incorporated into the boot file system and
which is intended for use by the system startup scripts. This file may
be used to provide the install values for sysidcfg and jumpscfg.
To verify the integrity of wanboot.conf, use the /usr/sbin/ -

bootconfchk command:
# bootconfchk /etc/netboot/129.156.198.0/010003BA152A42/wanboot.conf
The CGI program /usr/lib/inet/wanboot/wanboot-cgi fulfills client

download requests for wanboot and the root file system. The wanboot-
cgi file must be copied to the web server cgi-bin directory.
The CGI program /usr/lib/inet/wanboot/bootlog-cgi fulfills client

requests for logging WAN Boot messages. It must be copied to the web
server cgi-bin directory.

The driver /usr/sbin/wanbootutil serves as driver for wanboot_

keygen(1M), wanboot_keymgmt(1M), and wanboot_p12split(1M). It is
executed by the web server "owner."
The wanbootutil utility uses /usr/lib/inet/wanboot/keygen as a

keyword to create and display encryption and hashing keys anywhere in
the /etc/netboot hierarchy. It is only needed if the keywords
encryption_type or signature_type are set to a non-NULL value in
wanboot.conf. The -d option displays a key. The -m option creates a
master key. The -c option creates and stores a per-client key. The
supported keynames for WAN Boot are wanboot-hmac-sha1 and
wanboot-3des or wanboot-aes.
Signature verification uses a HMAC SHA-1 keyed hash with matching

keys on the server and client. The signature is generated if there is a
nonempty value for wanboot-hmac-sha1. WAN Boot aborts if there is a
signature mismatch.
The /usr/lib/inet/wanboot/keymgmt keyword is used by the

wanbootutil to insert and extract raw keys directly into and from a
specific keystore. Its main purpose is to insert a client's private key into a
client's keystore when client authentication is configured.
The keyword wanboot_keygen is a better choice for SHA-1, 3DES, and

AES keytypes. The -i option works with the -k option to insert a key into
a keystore and the -x option removes it. The -s option specifies a
repository in which a key will be inserted or from which a key will be
extracted.
The wanbootutil utility uses /usr/lib/inet/wanboot/p12split to

split PKCS #12 files into separate key and certificate entries. It creates
truststore, certstore, and client private keys in the /etc/netboot
hierarchy. The extracted client key must be inserted into a keystore using
keymgmt.
The wanbootcgi program uses the /usr/lib/inet/wanboot/encr

program to encrypt the .boot file system before sending it to the client.
The wanbootcgi program uses the /usr/lib/inet/wanboot/hmac

program to generate HMAC SHA-1 hash signatures of components
transmitted to the client.

The WAN Boot web server CGI programs must be copied to the web
server cgi-bin directory:
# cp /usr/lib/inet/wanboot/*-cgi /webhome/cgi-bin/*-cgi
The /usr/sbin/wanbootutil binary with its specific keywords creates

and maintains the SHA-1 signature and/or 3DES or AES encryption keys:
# wanbootutil keygen -m
The master HMAC/SHA1 key has been generated
# wanbootutil keygen -c -o net=129.156.198.0,cid=010003BA152A42,type=sha1
A new client HMAC/SHA1 key has been generated
# wanbootutil keygen -c -o net=129.156.198.0,cid=010003BA152A42,type=3des
A new client 3DES key has been generated
# find /etc/netboot -print
/etc/netboot
/etc/netboot/129.156.198.0
/etc/netboot/129.156.198.0/010003BA152A42
type=sha1
type=3des
# wanbootutil keymgmt -i -k keystore -s \
/etc/netboot/129.156.198.0/010003BA152A42/keystore -o type=rsa
The client's RSA key has been set
# wanbootutil keymgmt -x -f rsafile -s \
etc/netboot/129.156.198.0/010003BA152A42/keystore -o type=rsa
# wanbootutil p12split -i p12file -t \
/etc/netboot/129.156.198.0/010003BA152A42/truststore
# chmod 600 /etc/netboot/129.156.198.0/010003BA152A42/truststore
# wanbootutil p12split -i p12file -c \
/etc/netboot/129.156.198.0/010003BA152A42/certstore -k pkey
# chmod 600 /etc/netboot/129.156.198.0/010003BA152A42/certstore
# wanbootutil keymgmt -i -k keystore -s \
/etc/netboot/129.156.198.0/010003BA152A42/keystore -o type=rsa

The wanboot-cgi uses the encr program to encrypt the boot file system
before sending it to the client:
Usage: encr -o type=<3des|aes> -k key_file
The wanboot-cgi uses the hmac program to generate HMAC SHA-1 hash
signatures of components transmitted to the client:
Usage: hmac [-i input_file] -k key_file

WAN Boot Troubleshooting

● No OBP support for platform
Is the network-boot-arguments NVRAM variable defined?
● OpenBoot PROM cannot download the boot program
Is the boot_file value a URI to the CGI program?
Did you check the web server logs?
● Boot program cannot create ramdisk
Does the client have 256 Mbytes of RAM?
● Boot program cannot download component
Are the values in wanboot.conf correct?
Did you run bootconfchk on wanboot.conf?
● Hash mismatch reported
Is the HMAC SHA-1 key installed on client?
Does the client key match the client's key on the server?
● Boot file system (miniroot) does not execute correctly
Is the encryption key installed on the client?
Have you installed both 3DES and AES keys on server and client?
Does the client key match the client's key on the server?
● Secure connection cannot be made
Are the values in wanboot.conf correct?
Did you run bootconfchk on wanboot.conf?
Are you picking up the correct certificate(s)?
Are the host names in the certificates resolvable?

Exercise: Configuring WANboot

In this lab, you will configure a WAN Boot server to support one
installation client. All steps are performed on the WAN Boot server except
where noted otherwise. The configuration includes the following tasks:
● Configure the WAN Boot server as an Apache web server
● Configure Solaris JumpStart™ and WAN Boot parameters on the
WAN Boot server
● Configure the client using the WAN Boot procedure
Preparation
Instructor Preparation note: Verify the EduJump installation of the timesaver bundle
SA225_B_timesaverflar_SunOS5.10_sun4u_en-US_1_1_S.tar.gz (for SA225) or SA210-
S10_A_timesaverflar_SunOS5.10_sun4u_en-US_1_1_S.tar.gz (for SA210). The postinstall scripts in
these bundles move a small flash archive into the /var/apache/htdocs/flashdir directory.
At the time of this writing, there is a bug that prevents WANBoot from working correctly. The CR # is
6369598, and the result of the boot is that the miniroot loads, but the system fails during the search for the
Jumpstart directory with the message “/usr/sbin/install.d/profind: bad substitution”. This bug
was introduced in Solaris 10 Update 1. It was not a problem in Solaris 10 FCS and will not be a problem
later, in Solaris 10 Update 2 build 4 and beyond. Because this course is based on Solaris 10 Update 1, the
problem will present in this lab.
This lab also requires that Solaris 10 Update 1 DVDs are in the DVD
drives.
This requirement has been specified for the RLDC systems.

Complete the following worksheet before you begin the installation.

● WAN Boot server name (for example, WANBootserv):
______________________________________________________________
● WAN Boot server IP Address:
______________________________________________________________
● Directory containing the web server documents, also known as the
docroot. (default: /var/apache/htdocs):
______________________________________________________________
● Directory under the docroot that contains the Solaris 10 OS Flash
archive. (default:/var/apache/htdocs/flashdir/):
______________________________________________________________
● Directory under the docroot that contains the wanboot program file
and miniroot filesystem.
(default: /var/apache/htdocs/wanboot10):
______________________________________________________________
● Directory under the docroot that contains the sysidcfg, rules, and
profile files. (default: /var/apache/htdocs/config):
______________________________________________________________
● Directory that contains the wanboot.conf and system.conf files
(default: /etc/netboot):
______________________________________________________________
● WAN Boot client name (for example, WANBootclient):
______________________________________________________________
● WAN Boot client IP address (for example, 192.168.1.25):
______________________________________________________________

Task 1– Configuring the Apache Web Server

Perform the following steps to configure and start the Apache web server:
1. Clear out all of the index files in the Apache document root directory.
2. Update the primary Apache configuration file by setting the value of
the ServerName variable to your WAN Boot server’s IP address.
3. Start the web server.
4. Ensure that the web server is bound on port 80.

Files
Perform the following steps to configure the WAN Boot and JumpStart
server files:
1. Create the directories needed for the WAN Boot configuration on the
Apache web server.
wanboot – Contains the wanboot image needed to start the
JumpStart over http.
install – Contains the remote root file system.
miniroot – Is the ramdisk image used to start the client boot
process.
2. Set up the wanboot install server. The -b switch installs the server
only. Since a Flash archive will be used for this exercise, spooling the
entire Solaris 10 OS is not needed. This step will take 15-20 minutes
to complete. Continue with the following steps in a new terminal
window. There is no need to wait until completion to continue.
3. Copy the architecture dependent wanboot image over to the
wanboot directory. Different images must be used for different
architectures.
4. Copy the cgi scripts needed for JumpStart to work and set their
permissions to 755.
wanboot-cgi - serves all requests including parsing of wanboot
server files (wanboot.conf and system.conf) and client
configuration files (profile and sysidcfg)
bootlog-cgi - creates a log of all client activity in the
/tmp/bootlog.client file

5. Configure the install server wanboot parameters in the

wanboot.conf file. All server configuration files are placed in the
/etc/netboot directory.
6. Create the client configuration file pointer parameters in the
system.conf file.
7. Configure the individual client install parameters in the
/var/apache/htdocs/config directory. Use the templates provided
on disk 1 of Solaris 10 Update 1 OS installation CDs.
8. Setup client networking parameters in the sysidcfg file.
9. Setup client install parameters such as software and partitioning
information in the profile file.
10. Instruct the wanboot server to use the profile named "profile" created
in the previous steps for all clients. Be sure that this entry exists at
the top of the file.
11. Run the check utility on the rules and profile files.
12. Check the configuration of the wanboot server with the
bootconfchk utility. Absence of output indicates a successfully
configured wanboot server.
Task 3– Booting the WAN Boot Client

The following steps can be used on any client system, but are mandatory
on all systems below PROM revision 4.14.
Note – Prior to booting the client, make sure that the Install Server setup
complete message has appeared on the server system.
Use the banner command at the ok prompt to show your version of the
PROM.
1. Boot wanboot using the Solaris 10 Update 1 OS CD 1.
2. Enter all of the client networking and Wan Boot server information
at the interactive boot prompt.
3. Check the boot log on the WAN Boot server, or observe the console
messages, and make sure the client system is starting the install over
the http protocol.

Exercise Summary
Exercise Summary

discoveries you had during the lab exercise.
!
?
Manage the discussion based on the time allowed for this module. If you do not have time to spend on
discussion, highlight just the key concepts students should have learned from the lab exercise.
● Experiences
● Interpretations
● Conclusions
● Applications

Exercise Solutions
Exercise Solutions
This section provides the answers to the exercise tasks.
Task 1– Configuring the Apache Web Server

1. Clear out all of the index files in the Apache document root directory.
# cd /var/apache/htdocs
# cp index.html.en index.html
# mkdir INDEX
# mv index.html.* INDEX
2. Update the primary Apache configuration file to reflect the WAN
Boot server's IP address.
# cp /etc/apache/httpd.conf-example /etc/apache/httpd.conf
# vi /etc/apache/httpd.conf
Edit the line that reads:
ServerName 127.0.0.1
Change it to the correct server name for your environment:
ServerName WANBootserv (for example: sys-01)
3. Start the Apache web server.
# /etc/init.d/apache start
httpd starting.
ksh:sys-01# /usr/apache/bin/apachectl start: httpd started
4. Ensure that the web server is bound on port 80.
# netstat -an | grep 80 | grep -i listen
*.80 *.* 0 0 49152 0 LISTEN
Instructor Note: SMF effects all the services that use to live in /etc/inittab, /etc/init.d, and the
/etc/inetd.conf files. The catch is, some applications have not yet been converted. For example, starting
the apache web services continues to use/etc/init.d/apache start method, but will use svcadm enable
network/apache in an upcoming release.

Exercise Solutions

Files
Insert the Solaris 10 Update 1 CD 1 for the Solaris 10 Update 1 DVD.
Perform the following steps to configure the WAN Boot and JumpStart
server files:
1. Create the directories needed for the wanboot configuration on the
Apache web server.
wanboot - Contains the wanboot image needed to start the JumpStart
over http.
install - Contains the remote root file system.
miniroot - Is the ramdisk image used to start the client boot
process.
# cd /var/apache/htdocs
# mkdir wanboot install config miniroot
The following information is not shown in the course either in the SG or in IG. It is tagged so as to be hidden
to all but future course developers (Conditional Comment tag) who might benefit from these notes at some
time.
If the patch to fix the profind error were to be applied, the follow steps would be added to the procedure to
do so. The gist of the fix is to run an additional setup_install_server command to set up an install server
that is writable so that the patch can be applied to it. Then a second setup_install_server command is
issue to set up the wanboot server under the apache area.
The steps are not formally part of the lab because it adds about 2 more hours to the lab and requires 4 more
Gbytes of disk space and the point gained is minor. The lab, as the student will see and do it, shows the
server configuration and the process for booting the client. The only thing missing is a successful client
installation near the end of the procedure.
Discuss this patching procedure if students express an interest in how to get WANboot to work on a Solaris
10 Update 1 system. The patch required has been deposited on the classroom systems, via a lab bundle, in
the /var/sadm/spool directory so if there was interest, time and disk space, you could share these steps
with the students and get the client to successfully install. At the very least, discuss this issue with the
students to make them aware that the problem will go away in update 2 and the procedure in this lab will
produce a successfully installed client at that time. Also mention that the procedure below uses a temp patch
(T patch) and a regular one should be available for customers soon.
1a) This step assumes there is sufficient space (4 GB) in the /export/home file system. If you do not have
sufficient space in that file system, find a large enough file system (on the second disk or elsewhere).
Execute a command similar to the following to install a patchable install server. This command will take
about 2 hours.
# cd /cdrom/cdrom0/s0/Solaris_10/Tools
# ./setup_install_server /export/home/s10u1/dvds/wanbootfix
Verifying target directory...
Calculating the required disk space for the Solaris_10 product

Exercise Solutions
Calculating space required for the installation boot image

Copying the CD image to disk...
Copying Install Boot Image hierarchy...
Install Server setup complete
1b) Execute the following command to set an environment variable to avoid deleting a symbolic link for the
var directory under the miniroot during a subsequent setup_install_server command:
# PKG_NONABI_SYMLINKS="true"
# export PKG_NONABI_SYMLINKS
1c) Add the patch to fix the error in the profind script distributed on the Solaris 10 Update 1 DVD but now
in a writable area:
# patchadd -C /export/home/s10u1/dvds/wanbootfix/Solaris_10/Tools/Boot T119081-14


See /export/home/s10u1/dvds/wanbootfix/Solaris_10/Tools/Boot/var/sadm/patch/119081-14/log for details

SUNWadmc
SUNWadmlib-sysid
SUNWinst
SUNWsibi
At this point the patched area should be used for the following step 2 (not hidden in these instructor notes).
In other words, execute the next setup_install_server command from
/export/home/s10u1/dvds/wanbootfix/Solaris_10/Tools, not from the unpatched area included in the
visible lab, /cdrom/cdrom0/s0/Solaris_10/Tools).
2. Setup the wanboot install server. The -b switch installs the server
only. Since a Flash archive will be used for this exercise, spooling the
entire Solaris 10 OS is not needed. This step will take about 30
minutes to complete. Continue with the following steps in a new
terminal window. There is no need to wait until completion to
continue.
# cd /cdrom/cdrom0/s0/Solaris_10/Tools
# ./setup_install_server -b -w /var/apache/htdocs/wanboot \
/var/apache/htdocs/install
3. Copy the architecture dependent wanboot image over to the
wanboot directory. Different images must be used for different
architectures.
# cd /cdrom/cdrom0/s0/Solaris_10/Tools/Boot/platform/sun4u/
# cp wanboot /var/apache/htdocs/wanboot

Exercise Solutions
4. Copy the cgi scripts needed for JumpStart to work, and set their
permissions to 755.
wanboot-cgi – serves all requests including parsing of wanboot
server files (wanboot.conf and system.conf) and client
configuration files (profile and sysidcfg)
bootlog-cgi – creates a log of all client activity in the
/tmp/bootlog.client file
# cp /usr/lib/inet/wanboot/wanboot-cgi /var/apache/cgi-bin/wanboot-cgi
# chmod 755 /var/apache/cgi-bin/wanboot-cgi
# cp /usr/lib/inet/wanboot/bootlog-cgi /var/apache/cgi-bin
# chmod 755 /var/apache/cgi-bin/bootlog-cgi
5. Configure the install server wanboot parameters in the
wanboot.conf file. All server configuration files are placed in the
/etc/netboot directory.
# mkdir /etc/netboot
# vi /etc/netboot/wanboot.conf
boot_file=/wanboot/wanboot
root_server=http://<WANBooter_IP>/cgi-bin/wanboot-cgi
root_file=/wanboot/miniroot
signature_type=
encryption_type=
server_authentication=no
client_authentication=no
resolve_hosts=
boot_logger=http://WANBooter_IP/cgi-bin/bootlog-cgi
system_conf=system.conf
Note – In the wanboot.conf file above, the boot_logger is set to log all
messages to the server, by default under the /tmp directory. An alternative
is to leave this option blank and watch all messages on the client console.
6. Create the client configuration file pointer parameters in the

system.conf file.
# vi /etc/netboot/system.conf
SsysidCF=http://WANBootserv_IP/config
SjumpsCF=http://WANBootserv_IP/config
7. Configure the individual client install parameters in the
/var/apache/htdocs/config directory. Use the templates provided
on disk 1 of Solaris 10 Update 1 OS installation CDs.
# cp -r /cdrom/cdrom0/s0/Solaris_10/Misc/jumpstart_sample/* \
/var/apache/htdocs/config

Exercise Solutions
# cd /var/apache/htdocs/config
8. Set up client networking parameters in the sysidcfg file.
# vi sysidcfg
timeserver=localhost
system_locale=C
network_interface=<interface_type> { default_route=none
netmask=255.255.255.0 protocol_ipv6=no }
timezone=US/Central
terminal=vt100
name_service=NONE
security_policy=NONE
root_password=your_password
Note – In the above example of the root_password, make sure that you
cut and paste the actual root password out of the /etc/shadow file.
9. Set up client install parameters such as software and partitioning

information in the profile file.
# vi profile
install_type flash_install
archive_location http://WANBootserv_IP/flashdir/Flar_FileName
partitioning explicit
filesys c0t0d0s0 free /
10. Instruct the wanboot server to use the profile named profile
created in the previous steps for all clients. Be sure that this entry
exists at the top of the file.
# vi rules
any - - profile -
11. Run the check utility on the rules and profile files. View the
rules.ok file to make sure the any rule in effect. (You may see an
error reported by the check utility related to the string set_root_pw.
Comment out that line to fix the problem and run check again.
Note – This is a mandatory step. The JumpStart client installation aborts if

you do not run this command.
# ./check
# more rules.ok

Exercise Solutions
12. Check the configuration of the wanboot server with the

bootconfchk utility. Absence of output indicates a successfully
configured wanboot server.
# bootconfchk /etc/netboot/wanboot.conf

Exercise Solutions
Task 3– Booting the WAN Boot Client

The following steps can be used on any client system, but are mandatory
on all systems below PROM revision 4.14.
Note – Prior to booting the client, make sure that the Install Server setup
complete message has appeared on the server system.
Use the banner command at the ok prompt to show your version of the
PROM.
1. Boot wanboot using the Solaris 10 OS Update 1 CD 1.
ok boot cdrom -o prompt -F wanboot - install
2. Enter all of the client networking and Wan Boot server information
at the interactive boot prompt.
boot> prompt
host-ip? WanBootClient1_IP
subnet-mask? 255.255.255.0
router-ip?
hostname? WanBootClient1
http-proxy?
client-id?
aes?
3des?
sha1?
bootserver? http://WANBootserv_IP/cgi-bin/wanboot-cgi
Ignore the error:
Unknown variable '/129.148.192.83/cgi-bin/wanboot-cgi'; ignored
boot> list
host-ip: WanbootClient1_IP
subnet-mask: 255.255.255.0
router-ip: UNSET
hostname: WANBootclient1
http-proxy: UNSET
client-id: UNSET
aes: *HIDDEN*
3des: *HIDDEN*
sha1: *HIDDEN*
bootserver: http://WANBootserv-IP/cgi-bin/wanboot-cgi

Exercise Solutions
boot> go
3. If you configured the boot_logger to log all messages to the
WANBoot server in Task 2, Step 5, check the boot log and make sure
the client system is starting the install over the http protocol.
# tail -f /tmp/bootlog.WanBootClient1
Feb 01 10:31:43 sys-02 wanboot: [ID 848080 user.progress] miniroot: Read
34712 of 247776 kB (14%)
Feb 01 10:31:59 sys-02 wanboot: [ID 193690 user.progress] miniroot: Read
54552 of 247776 kB (22%)
...
Download complete
Note – This lab is using Solaris 10 Update 1. There is a known bug with
this update release that prevents the client from completely installing.
The error message displayed on the client console is as follows:
...
Starting Solaris installation program...
Searching for JumpStart directory...
/usr/sbin/install.d/profind: bad substitution
Warning: Could not find matching rule in rules.ok
This error is fixed and will be available as a patch for Solaris 10 Update 1
installations. The fix will be included in Solaris 10 Update 2.

Sa 210 S10

Încărcat de

Informații document

Descriere originală:

Titlu original

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

Sa 210 S10

Încărcat de

Drepturi de autor:

Formate disponibile

Make the Transition to the

Solaris™ 10 Operating System

Student Guide With Instructor Notes

Sun Microsystems, Inc.

Export Control Classification Number (ECCN) assigned: 26 March, 2006

viii Make the Transition to the Solaris™ 10 Operating System

x Make the Transition to the Solaris™ 10 Operating System

xii Make the Transition to the Solaris™ 10 Operating System

About This Course

Managing File Systems

Installing Software Performing User and Security Administration

Managing Printers Describing Network Basics

Managing Virtual File Systems and Core Dumps

Performing Advance Installation Procedures

Configuring Performing a Using Introducing

Preface-ii Make the Transition to the Solaris™ Operating System

Topics Not Covered

About This Course Preface-iii

How Prepared Are You?

Preface-iv Make the Transition to the Solaris™ Operating System

About This Course Preface-v

How to Use Course Materials

Preface-vi Make the Transition to the Solaris™ Operating System

Additional resources – Indicates other references that provide additional

Demonstration – Indicates a demonstration of the current topic is

Discussion – Indicates a small-group or class discussion on the current

About This Course Preface-vii

Courier italics is used for variables and command-line placeholders

Courier italic bold is used to represent variables whose values are to

Preface-viii Make the Transition to the Solaris™ Operating System

Notes to the Instructor

About This Course Preface-ix

Preface-x Make the Transition to the Solaris™ Operating System

Managing Services With the Service

Upon completion of this module, you should be able to identify features

Discussion – The following question is relevant to understanding the

1-2 Make the Transition to the Solaris™ 10 Operating System

Additional resources – The following references provide additional

Managing Services With the Service Management Facility (SMF) 1-3

The Service Management Facility

Solaris services are modeled by describing them in terms of an SMF

The SMF Architecture

1-4 Make the Transition to the Solaris™ 10 Operating System

Figure 1-1 shows the main components of SMF.

Figure 1-1 The SMF Components

The main components of SMF are the following:

Managing Services With the Service Management Facility (SMF) 1-5

The milestone service is special in that there is no software to run in

1-6 Make the Transition to the Solaris™ 10 Operating System

Solaris uses a URI string called a Fault Managed Resource Identifier

Managing Services With the Service Management Facility (SMF) 1-7

A service provides a known list of capabilities. There are times when it is

The following is an example of a service with multiple instances:

A service can be in one of the following states (see Figure 1-2):

1-8 Make the Transition to the Solaris™ 10 Operating System

Services transition from one state to another either due to explicit

Service put in maintenance state

Dependencies staisfied No improveme

Figure 1-2 SMF Service States

Managing Services With the Service Management Facility (SMF) 1-9

Services are composed of several components, for example:

SMF organizes services using profiles and manifests. A profile is used to