Step by Step Install Ti On Solaris 10

Installing Sun Solaris 10
by Jeff Hunter, Sr. Database Administrator
Contents
1. Overview
2. Using Serial Console Connection
3. Starting the Installation
4. Answering the Screen Prompts
5. Post-Installation Tasks
Overview
This article documents installing the 6/06 (June 2006) release of Solaris 10 from CD-
ROM. For the purpose of this example, I will be installing Solaris 10 on a Sun Blade 150
with the following configuration:
• Sun Blade 150 (UltraSPARC-IIe 650MHz), No Keyboard, OpenBoot 4.6

• 1,792 MB RAM Memory
• Two - 40 GB IDE Western Digital Hard Drives - (/dev/dsk/c0t0d0 and
/dev/dsk/c0t2d0)
• Built-in Ethernet - (eri0)
• CDROM - (/dev/dsk/c0t1d0)
Installing Solaris 10 will require 5 CDs found in the Solaris media kit labeled "Solaris 10
Software" or downloaded from http://www.sun.com/software/solaris/ - (Solaris 10 6/06).
Before starting the installation process, ensure that you have noted the following items:
• Determine the host name of the system you are installing

• Determine the language and locales you intend to use on the system
• If you intend to include the system in a network, gather the following information:
o Host IP address
o Subnet mask
o Type of name service (DNS, NIS, or NIS+, for example)
o Domain name
o Host name of server
o Host IP address of the name server
Using Serial / Console Connection

For a complete discussion of connecting to a Sun serial console from Linux, see my
article "Using Serial Consoles - (Sun Sparcs)".
For this particular installation, I will NOT be using a VGA monitor connected to the
built-in frame-buffer (video card). The installation will be done using the serial port of
the Sun Blade as a console. A serial cable (null modem) will be connected from the serial
port of a Linux machine to the serial port of the Sun Blade. Keep in mind that you will
not be able to make use of the serial console of the Sun Blade if it was booted with the
keyboard/mouse plugged in. In order to make use of the serial console, you will need to
disconnect the keyboard/mouse and reboot the Sun server. On the Sun Blade 100/150, if
the keyboard/mouse are plugged in during the boot phase, all console output will be
redirected to the VGA console.
From the Linux machine, you can use a program called minicom. Start it up with the
command "minicom". Press "Ctrl-A Z" to get to the main menu. Press "o" to configure
minicom. Go to "Serial port setup" and make sure that you are set to the correct "Serial
Device" and that the speed on line E matches the speed of the serial console you are
connecting to. (In most cases with Sun, this is 9600.) Here are the settings I made when
using Serial A / COM1 port on the Linux machine:
+----------------------------------------------------------------------
-+
| A - Serial Device : /dev/ttyS0
|
| B - Lockfile Location : /var/lock
|
| C - Callin Program :
|
| D - Callout Program :
|
| E - Bps/Par/Bits : 9600 8N1
|
| F - Hardware Flow Control : Yes
|
| G - Software Flow Control : No
|
|
|
| Change which setting?
|
+----------------------------------------------------------------------
-+
After making all necessary changes, hit the ESC key to go back to the "configurations"
menu. Now go to "Modem and dialing". Change the "Init string" to "~^M~". Save the
settings (as dflt), and then restart Minicom. You should now see a console login prompt.
[root@bertha1 root]# minicom
Welcome to minicom 2.00.0
OPTIONS: History Buffer, F-key Macros, Search History Buffer, I18n

Compiled on Feb 17 2004, 04:52:10.
Press CTRL-A Z for help on special keys
alex console login: root

Password:
Last login: Tue Nov 4 18:55:41 on console
Nov 7 12:17:24 alex login: ROOT LOGIN /dev/console
Sun Microsystems Inc. SunOS 5.8 Generic Patch October 2001
#
# init 0
INIT: New run level: 0
The system is coming down. Please wait.
System services are now being stopped.
Print services stopped.
Nov 7 12:17:38 alex syslogd: going down on signal 15
The system is down.
syncing file systems... done
Program terminated
ok
Starting the Installation
The installation process starts at the ok prompt. The previous section of this document
provides the steps required to not only gain access to the console port of the Sun SPARC
server, but also how to get the server to an ok prompt. If when logging on, the machine is
already booted into the O/S, (you have a console login like the following: "alex
console login:"), you will need to bring the machine to its EEPROM (ok prompt) by
initiating init 0 like in the Using Serial / Console Connection section above.
The first step in installing Solaris 10 is to boot the machine from Disk 1 of the Solaris 10
Software CDs. You will need to get the machine to the ok prompt. You can do this by
shutting the system down using init 0. Once at the ok prompt, type in boot cdrom. (Or
in some cases, you can use reboot cdrom). From here, the installation program prompts
you for system configuration information that is needed to complete the installation.
If you were performing a network installation, you would type:

ok boot net
In almost all cases, you will be installing the Solaris 10 software on a new system where
it will not be necessary to preserve any data already on the hard drive. Using this
assumption, I will partition the first single 40 GB IDE hard drive (/dev/dsk/c0t0d0) as
the system disk.
Answering the Screen Prompts
Let's start the installation process! Put the Solaris 10 Software (Disk 1 of 5) in the
CDROM tray and boot to it:
Solaris Installation Boot Screen
ok boot cdrom
Resetting ...
Sun Blade 150 (UltraSPARC-IIe 650MHz), No Keyboard

Copyright 1998-2002 Sun Microsystems, Inc. All rights reserved.
OpenBoot 4.6, 1792 MB memory installed, Serial #52928138.
Ethernet address 0:3:ba:27:9e:8a, Host ID: 83279e8a.
Rebooting with command: boot cdrom

Boot device: /pci@1f,0/ide@d/cdrom@1,0:f File and args:
SunOS Release 5.10 Version Generic_118833-17 64-bit
Use is subject to license terms.
Configuring devices.
Using RPC Bootparams for network configuration information.
Attempting to configure interface eri0...
SUNW,eri0 : 100 Mbps full duplex link up
Configured interface eri0
Beginning system identification...
Searching for configuration file(s)...
Search complete.
Discovering additional network configuration...
The boot process may take several minutes to complete, but once done, you will start
answering a series of prompts.
The following section will walk you through many of the screen prompts from the
installation.
The first two prompts are from the command line interface (CLI) and are used to specify
the language and terminal. Use English for the Language. As for a terminal setting, I
commonly telnet to a Linux server (that is connected from the serial port of the Linux
server to the serial port of the Sun machine). From the Linux server, I use "minicom" to
connect from the Linux server to the Sun server. The best terminal for this type of
installation is "DEC VT100":
Language : English
What type of terminal are you using? : 3) DEC VT100
You should be able to use a terminal type of "DEC VT100" or "X Terminal
Emulator (xterms)".
Depending on the terminal being used for installation while using the command line
interface, it may be required to precede any of the function key responses (i.e.
F2_Continue) with the ESC key (i.e. ESC - F2_Continue). For the purpose of this
installation, I am using minicom 2.0 and configured the installation to use a DEC
VT100 terminal. Given this configuration I did not have to precede any of the
function key responses with the ESC key.
Many of the screens to follow will ask you about networking information. When asked if
the system will be connected to a network, answer Yes.
Many of the screens should be easy to complete except for the "Names Services"
section. In almost all cases, you will want to use DNS naming services, but if your
machine is not currently configured within DNS, this section will fail and no
information entered about Names Services will be stored and configured.
If this is the case, you will need to select None under the Names Services section.
The network configuration will then need to be completed after the installation
process by updating certain network files on the local hard drive. This will be
documented in the "Post Installation Procedures" of this document.
Screen 1 : The Solaris Installation Program
This is the Solaris Installation Welcome screen.
Hit F2 to continue
Screen 2 : Identify This System
This screen informs you about how you will need to identify the computer as it applies to
network connectivity.
Hit F2 to continue
Screen 3 : Network Connectivity
Networked
---------
[X] Yes
[ ] No
Hit F2 to continue
Screen 4 : DHCP
Use DHCP
--------
[ ] Yes
[X] No
Hit F2 to continue
Screen 5 : Host Name for eri0
Enter the host name which will identify this system on the network. For the purpose of
this example, I will use the host name "alex".
Host name for eri0: alex

Hit F2 to continue
Screen 6 : IP Address for eri0
Enter the Internet Protocol (IP) address for this network interface.
IP address for eri0: 192.168.1.102

Hit F2 to continue
Screen 7 : Subnet for eri0
On this screen you must specify whether this system is part of a subnet. For the purpose
of this example, this interface will be part of a subnet.
System part of a subnet

-----------------------
[X] Yes
[ ] No
Hit F2 to continue
Screen 8 : Netmask for eri0
Netmask for eri0: 255.255.255.0

Hit F2 to continue
Screen 9 : IPv6 for eri0
In this example, I will not be enabling IPv6.
Enable IPv6 for eri0

--------------------
[ ] Yes
[X] No
Hit F2 to continue
Screen 10 : Set the Default Route for eri0

I will manually specify the IP address of my router.
Default Route for eri0

----------------------
[ ] Detect one upon reboot
[X] Specify one
[ ] None
Hit F2 to continue
Screen 11 : Default Route IP Address for eri0
Router IP Address for eri0: 192.168.1.1
Hit F2 to continue
Screen 12 : Confirm Information for eri0
This is a confirmation screen. Verify all data is correct.
Host name: alex

IP address: 192.168.1.102
System part of a subnet: Yes
Netmask: 255.255.255.0
Enable IPv6: No
Default Route: Specify one
Router IP Address: 192.168.1.1
Hit F2 to continue
Screen 13 : Configure Security Policy
Configure Kerberos Security

---------------------------
[ ] Yes
[X] No
Hit F2 to continue
Screen 14 : Confirm Information
Configure Kerberos Security: No
Hit F2 to continue
Screen 15 : Name Service
Name service
------------
[ ] NIS+
[ ] NIS
[X] DNS
[ ] LDAP
[ ] None
Hit F2 to continue
Screen 16 : Domain Name
Host name: idevelopment.info

Hit F2 to continue
Screen 17 : DNS Server Addresses
Server's IP address: 63.67.120.23

Server's IP address: 63.67.120.14
Server's IP address:
Hit F2 to continue
Screen 18 : DNS Search List
Search domain:
Search domain:
Search domain:
Search domain:
Search domain:
Search domain:
Hit F2 to continue
Name service: DNS

Domain name: idevelopment.info
Server address(es): 63.67.120.23
63.67.120.14
Hit F2 to continue
Screen 20 : Time Zone
Continents and Oceans

---------------------
[ ] Africa
[X] Americas
[ ] Antarctica
[ ] Arctic Ocean
[ ] Asia
[ ] Atlantic Ocean
[ ] Australia
[ ] Europe
[ ] Indian Ocean
[ ] Pacific Ocean
[ ] other - offset from GMT
[ ] other - specify time zone file
Hit F2 to continue
Screen 21 : Country or Region
Countries and Regions

---------------------
[X] United States
[ ] Anguilla
[ ] Antigua & Barbuda
[ ] Argentina
[ ] Aruba
[ ] Bahamas
[ ] Barbados
[ ] Belize
[ ] Bolivia
[ ] Brazil
[ ] Canada
[ ] Cayman Islands
[ ] Chile
[ ] Colombia
[ ] Costa Rica
[ ] Cuba
[ ] Dominica
[ ] Dominican Republic
[ ] Ecuador
[ ] El Salvador
[ ] French Guiana
[ ] Greenland
[ ] Grenada
[ ] Guadeloupe
[ ] Guatemala
[ ] Guyana
[ ] Haiti
[ ] Honduras
[ ] Jamaica
[ ] Martinique
[ ] Mexico
[ ] Montserrat
[ ] Netherlands Antilles
[ ] Nicaragua
[ ] Panama
[ ] Paraguay
[ ] Peru
[ ] Puerto Rico
[ ] St Kitts & Nevis
[ ] St Lucia
[ ] St Pierre & Miquelon
[ ] St Vincent
[ ] Suriname
[ ] Trinidad & Tobago
[ ] Turks & Caicos Is
[ ] Uruguay
[ ] Venezuela
[ ] Virgin Islands (UK)
[ ] Virgin Islands (US)
Hit F2 to continue
Screen 22 : Time Zone
Time zones
----------
[X] Eastern Time
[ ] Eastern Time - Michigan - most locations
[ ] Eastern Time - Kentucky - Louisville area
[ ] Eastern Time - Kentucky - Wayne County
[ ] Eastern Standard Time - Indiana - most locations
[ ] Eastern Standard Time - Indiana - Crawford County
[ ] Eastern Standard Time - Indiana - Starke County
[ ] Eastern Standard Time - Indiana - Switzerland County
[ ] Central Time
[ ] Central Time - Michigan - Wisconsin border
[ ] Central Time - North Dakota - Oliver County
[ ] Mountain Time
[ ] Mountain Time - south Idaho & east Oregon
[ ] Mountain Time - Navajo
[ ] Mountain Standard Time - Arizona
[ ] Pacific Time
[ ] Alaska Time
[ ] Alaska Time - Alaska panhandle
[ ] Alaska Time - Alaska panhandle neck
[ ] Alaska Time - west Alaska
[ ] Aleutian Islands
[ ] Hawaii
Hit F2 to continue
Screen 23 : Date and Time
Date and time: YYYY-MM-DD HH:MM

Year (4 digits) : <enter year>
Month (1-12) : <enter month>
Day (1-31) : <enter day>
Hour (0-23) : <enter hour>
Minute (0-59) : <enter minute>
Hit F2 to continue
Time zone: Eastern Time

(US/Eastern)
Date and time: 2006-11-26 15:11:00
Hit F2 to continue
Screen 25 : Solaris Interactive Installation
There are two ways to install your Solaris software: "Standard" or "Flash". Choose the
"Standard" method (F2_Standard).
Hit F2 to continue
Screen 26 : Eject a CD/DVD Automatically?
During the installation of Solaris software, you may be using one or more CDs/DVDs.
You can choose to have the system eject each CD/DVD automatically after it is installed
or you can choose to manually eject each CD/DVD.
[X] Automatically eject CD/DVD

[ ] Manually eject CD/DVD
Hit F2 to continue
Screen 27 : Reboot After Installation?
After Solaris software is installed, the system must be rebooted. You can choose to have
the system automatically reboot, or you can choose to manually reboot the system if you
want to run scripts or do other customizations before the reboot. You can manually reboot
a system by using the reboot(1M) command.
[X] Auto Reboot

[ ] Manual Reboot
Hit F2 to continue
Screen 28 : Solaris Interactive Installation
This screen recognizes if a previous version of Solaris is installed and whether you would
like to upgrade or not. Always select the install option (F4_Initial).
Hit F4 to continue
Screen 29 : Initializing
The system is being initialized.
Loading install media, please wait...
Screen 30 : License
Read through the software license agreement.
Hit F2 to accept the license and continue
Screen 31 : Select Geographic Regions
Select the geographic regions for which support should be installed.

--------------------------------------------------------------------
> [ ] Australasia
> [ ] Asia
> [ ] Eastern Europe
> [ ] Northern Europe
> [ ] Northern Africa
> [ ] Middle East
> [ ] Southern Europe
> [ ] South America
> [ ] Central America
> [ ] Central Europe
V [/] North America
[ ] Canada-English (ISO8859-1)
[ ] Canada-French (ISO8859-1)
[ ] French
[ ] Mexico (ISO8859-1)
[ ] Spanish
[X] U.S.A. (UTF-8)
[X] U.S.A. (en_US.ISO8859-1)
> [ ] Western Europe
Hit F2 to continue
Screen 32 : Select System Locale
Select the initial locale to be used after the system has been
installed.
-----------------------------------------------------------------------
--
[X] POSIX C ( C )
North America
[ ] U.S.A. (UTF-8) ( en_US.UTF-8 )
[ ] U.S.A. (en_US.ISO8859-1) ( en_US.ISO8859-1 )
[ ] U.S.A. (en_US.ISO8859-15) ( en_US.ISO8859-15 )
Hit F2 to continue
Screen 33 : Select Products
Select the products you would like to install.

----------------------------------------------
V [X] Solaris 10 Extra Value Software................. 87.26 MB
[X] Sun Validation Test Suite 6.2................... 69.92 MB
[X] Sun Install Check 2.0.2......................... 17.34 MB
> [ ] Java Enterprise System.......................... 0.00 MB
Hit F2 to continue
Screen 34 : Additional Products
To scan for additional products, select the location you wish to scan.
Web Start Ready product scan location:

--------------------------------------
[X] None
[ ] CD/DVD
[ ] Network File System
Hit F2 to continue
Screen 35 : Select Software
Select the Solaris software to install on the system.

-----------------------------------------------------
[ ] Entire Distribution plus OEM support ....... 5641.00 MB
[X] Entire Distribution ........................ 5593.00 MB
[ ] Developer System Support ................... 5468.00 MB
[ ] End User System Support .................... 4452.00 MB
[ ] Core System Support ........................ 958.00 MB
[ ] Reduced Networking Core System Support ..... 916.00 MB
Hit F2 to continue
Screen 36 : Select Disks
You must select the disks for installing Solaris software. If there are several disks
available, I always install the Solaris software on the boot disk c0t0d0. NOTE: **
denotes current boot disk
----------------------------------------------------------
Disk Device Available Space

===============================================
[X] ** c0t0d0 38162 MB (F4 to edit)
[ ] c0t2d0 38162 MB
Total Selected: 38162 MB

Suggested Minimum: 4319 MB
I generally select F4 to edit the c0t0d0 disk to ensure that the root directory is going to be
located on this disk.
----------------------------------------------------------
On this screen you can select the disk for installing the
root (/) file system of the Solaris software.
Original Boot Device : c0t0d0
Disk
==============================
[X] c0t0d0 (F4 to select boot device)
On this screen, I typically select F4 to select boot device to ensure the root file system
will be located on slice zero, c0t0d0s0.
----------------------------------------------------------
On this screen you can select the specific slice for the root (/) file
system. If you choose Any of the Above, the Solaris installation program
will choose a slice for you.
Original Boot Device : c0t0d0s0
[X] c0t0d0s0
[ ] c0t0d0s1
[ ] c0t0d0s2
[ ] c0t0d0s3
[ ] c0t0d0s4
[ ] c0t0d0s5
[ ] c0t0d0s6
[ ] c0t0d0s7
[ ] Any of the Above
Hit F2 to after selecting Disk Slice
Hit F2 to continue with your Boot Disk selection
Screen 37 : Reconfigure EEPROM?
Do you want to update the system's hardware (EEPROM) to always boot from c0t0d0?
Hit F2 to Reconfigure EEPROM and Continue
Screen 38 : Preserve Data?
Do you want to preserve existing data? At least one of the disks you've selected for
installing Solaris software has file systems or unnamed slices that you may want to save.
Hit F2 to continue
Screen 39 : Automatically Layout File Systems?
Do you want to use auto-layout to automatically layout file systems? Manually laying out
file systems requires advanced system administration skills.
I typically perform an "Auto" File System Layout (F2_Auto Layout).
Hit F2 to Perform Auto Layout.
Screen 40 : Automatically Layout File Systems
On this screen you must select all the file systems you want auto-layout to create, or
accept the default file systems shown.
File Systems for Auto-layout

========================================
[X] /
[ ] /opt
[ ] /usr
[ ] /usr/openwin
[ ] /var
[X] swap
Hit F2 to continue
Screen 41 : 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 5267 MB
swap c0t0d0s1 513 MB
overlap c0t0d0s2 38162 MB
/export/home c0t0d0s7 32381 MB
I generally select F4 (F4_Customize) to edit the partitions for disk c0t0d0. If this is a
workstation, I make only three partitions:
• / : I often get the sizes for the individual filesystems (/usr, /opt, and /var)
incorrect. This is one reason I typically create only one partition as / that will be
used for the entire system (minus swap space). In most cases, I will be installing
additional disks for large applications like the Oracle RDBMS, Oracle Application
Server, or other J2EE application servers.
• overlap : The overlap partition represents entire disk and is slice s2 of the disk.
• swap : The swap partition size depends on the size of RAM in the system. If you
are not sure of its size, make it double the amount of RAM in your system. I
typically like to make swap 2GB.
-------------------------------------------------
Boot Device: c0t0d0s0
=================================================
Slice Mount Point Size (MB)
0 / 36112
1 swap 2049
2 overlap 38162
3 0
4 0
5 0
6 0
7 0
=================================================
Capacity: 38162 MB
Allocated: 38161 MB
Rounding Error: 1 MB
Free: 0 MB
Hit F2 to continue
This is what the File System and Disk Layout screen looks like now.
File sys/Mnt point Disk/Slice Size

=============================================================
/ c0t0d0s0 36112 MB
overlap c0t0d0s2 38162 MB
Hit F2 to continue
Screen 42 : Mount Remote File Systems?
Do you want to mount software from a remote file server? This may be necessary if you
had to remove software because of disk space problems.
Hit F2 to continue
Screen 43 : Profile
Installation Option: Initial

Boot Device: c0t0d0
Client Services: None
Locales: U.S.A. (UTF-8)

U.S.A. (en_US.ISO8859-1)
System Locale: C ( C )
Software: Solaris 10, Entire Distribution
File System and Disk Layout: / c0t0d0s0 36112 MB

Products: Solaris 10 Extra Value Sof ...> 87.26 MB

Sun Validation Test Suite 6 69.92 MB
Sun Install Check 2.0.2 17.34 MB
Hit F2 to Begin the Installation
Screen 44 : Initial Installation Progress
Afterwards it starts configuring disks, making partitions, and installing software

indicating the progress.
Preparing system for Solaris install

Configuring disk (c0t0d0)
- Creating Solaris disk label (VTOC)
Creating and checking UFS file systems

- Creating / (c0t0d0s0)
==================================================================
Solaris Initial Install
MBytes Installed: 422.08

MBytes Remaining: 3648.09
Installing: JavaVM run time environment
*****
| | | | | |
0 20 40 60 80 100
==================================================================
Solaris 10 software installation succeeded
Customizing system files

- Mount points table (/etc/vfstab)
- Unselected disk mount points
(/var/sadm/system/data/vfstab.unselected)
- Network host addresses (/etc/hosts)
- Network host addresses (/etc/hosts)
- Environment variables (/etc/default/init)
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)
Install of CD 1 complete.
Executing SolStart postinstall phase...
Executing finish script "patch_finish"...
Finish script patch_finish execution completed.

Executing JumpStart postinstall phase...
The begin script log 'begin.log'

is located in /var/sadm/system/logs after reboot.
The finish script log 'finish.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]
rebooting...
Resetting ...
Sun Blade 150 (UltraSPARC-IIe 650MHz), No Keyboard

OpenBoot 4.6, 1792 MB memory installed, Serial #52928138.
Ethernet address 0:3:ba:27:9e:8a, Host ID: 83279e8a.
Rebooting with command: boot

Boot device: /pci@1f,0/ide@d/disk@0,0:a File and args:
SunOS Release 5.10 Version Generic_118833-17 64-bit
Use is subject to license terms.
Hostname: alex
Configuring devices.
SUNW,eri0 : 100 Mbps full duplex link up
Loading smf(5) service descriptions: 91/91
Creating new rsa public/private host key pair
Creating new dsa public/private host key pair
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] : no
For more information about how the NFS version 4 default domain
name is derived and its impact, refer to the man pages for
nfs(4)
and nfsmapid(1m), and the System Administration Guide: Network
Services.
Starting Solaris Install Launcher in Command Line Mode.
Screen 45 : Continue Installation (Part 2)
After the system reboots, the installer will start the Solaris Install Launcher in command
line mode. You will then be asked for disk 2 of 5.
==================================================================
Please specify the media from which you will install Solaris 10
Software 2 for
SPARC Platforms.
Alternatively, choose the selection for "Skip" to skip this disc and go
on to
the next one.
Media:
1. CD/DVD
2. Network File System
3. Skip
Media [1]: 1
Please insert the CD/DVD for Solaris 10 Software 2 for SPARC Platforms.
After you insert the disc, please press Enter.
Enter S to skip this disc and go on to the next one.

To select a different media, enter B to go Back.
<Replace disk 1 with disk 2 and hit ENTER to continue>
Reading Solaris 10 Software 2 for SPARC Platforms.... /
Launching installer for Solaris 10 Software 2 for SPARC Platforms.

Please
Wait...
The following items will be installed:
Product: Solaris 10 packages (part 2)

Location: /
Size: 887.16 MB
-------------------------------------
Solaris 10 packages (part 2) 887.16 MB
Ready to Install
1. Install Now
2. Start Over
3. Exit Installation
What would you like to do [1]? 1
Solaris 10 packages (part 2)

|-1%--------------25%-----------------50%-----------------
75%--------------100%|
Pausing for 30 seconds at the "Summary" screen. The wizard will

continue to
'c' to
continue. [c]
You will then be asked for disk 3 of 5.
Software 3 for
SPARC Platforms.
on to
the next one.
Media:
1. CD/DVD
3. Skip
Media [1]: 1

[]

Please
Wait...

Location: /
Size: 726.4 MB
-------------------------------------
Ready to Install
1. Install Now
2. Start Over

|-1%--------------25%-----------------50%-----------------
75%--------------100%|

continue to
'c' to
continue. [c]
Software 4 for
SPARC Platforms.
on to
the next one.
Media:
1. CD/DVD
3. Skip
Media [1]: 1

[]

Please
Wait...
Java Accessibility Bridge for GNOME loaded.

Location: /
Size: 557.77 MB
-------------------------------------
Ready to Install
1. Install Now
2. Start Over

|-1%--------------25%-----------------50%-----------------
75%--------------100%|

continue to
'c' to
continue. [c]
Software 5 for
SPARC Platforms.
on to
the next one.
Media:
1. CD/DVD
3. Skip
Media [1]: 1

[]

Please
Wait...

Location: /
Size: 733.65 MB
-------------------------------------
Product: Sun Validation Test Suite 6.2

Location: /opt
Size: 58.84 MB
--------------------------------------
Test binaries 44.77 MB
Man Pages and Documentation 8.69 MB
Core Framework 5.39 MB
Product: Sun Install Check 2.0.2

Location: /opt
Size: 17.06 MB
--------------------------------
SUNWinck - Sun Install Check 256.6 KB
SUNWeke - Embedded Knowledge Engine 4.29 MB
SUNWicisr - Sun Install Check Input Source (Root) 9.76 MB
SUNWicis - Sun Install Check Input Source 2.78 MB
SUNWinckr - Sun Install Check (Root) 785 bytes
Ready to Install
1. Install Now
2. Start Over

|-1%--------------25%-----------------50%-----------------
75%--------------100%|
Installing Sun Validation Test Suite 6.2

|-1%--------------25%-----------------50%-----------------
75%--------------100%|
Installing Sun Install Check 2.0.2

|-1%--------------25%-----------------50%-----------------
75%--------------100%|

continue to
'c' to
continue. [c]
Launching installer. Please Wait...
Installing Additional Software

|-1%--------------25%-----------------50%-----------------
75%--------------100%|

continue to
'c' to
continue. [c]
Pausing for 90 seconds at the "Reboot" screen. The wizard will

continue to
'c' to
continue. [c]
Nov 26 17:43:40 alex reboot: rebooted by root

Nov 26 17:43:41 alex syslogd: going down on signal 15
rebooting...
Resetting ...
Post-Installation Tasks
After successfully installing the Solaris operating platform software, there may be several
tasks that need to be performed depending on your configuration.
• Networking:
If you will be using networking database files for your TCP/IP networking
configuration, several files will need to be manually created and/or modified. I
provided a step-by-step document on how to manually configure TCP/IP
networking files to manually enable TCP/IP networking using files: Configuring
TCP/IP on Solaris - TCP/IP Configuration Files - (Quick Config Guide)
• Solaris 10 Patch Cluster:
It is advisable to install the latest Sun Solaris Patch Cluster to ensure a stable
operating environment. I provided a step-by-step document on how to download
and install the latest Sun Solaris 10 Patch Cluster: Patching Sun Solaris 10
Patching Sun Solaris 9

Overview
This article documents the process of downloading and installing the latest Sun Solaris 9
Patch Cluster.
Starting the Installation
The Sun Solaris 9 Patch Cluster can be downloaded from the following URL:
sunsolve.sun.com/pub-cgi/show.pl?target=patches/patch-access
Download and unzip the file 9_Recommended.zip to a temporary directory. It will create
the directory called 9_Recommended. Change to this directory and run the
install_cluster shell script. The process may take up to several hours depending on
the system.
# su -
# unzip 9_Recommended.zip
# cd 9_Recommended
# ./install_cluster
During the patch process you may encounter several failures with either error code 2
and/or error code 8. These are normal. They represent "package already at current rev"
and "underlying package not installed". Anything other than 2 or 8 you should look more
closely at.
KVM Switches For the Home and the Enterprise - (Avocent)
Contents
1. Introduction
2. SwitchView® 1000
3. AutoView® 1415
Figure 1 - Example KVM Switch

Click to enlarge
Introduction
Businesses of all sizes and even many home offices face the difficulty of managing an
ever growing number of servers. These may include mail servers, file servers, web
servers, application servers, and database servers. Although each server may be
accessible through the network for management purposes (Telnet or SSH), many
administrators need direct access to the console. When managing a very small number of
servers, it might make sense to connect each server with its own monitor, keyboard, and
mouse in order to access its console. However, as the number of servers to manage
increases, this solution becomes unfeasible. A more practical solution would be to
configure a dedicated computer which would include a single monitor, keyboard, and
mouse that would have direct access to the console of each server. This solution is made
possible using a Keyboard, Video, Mouse Switch — better known as a KVM Switch -
(see Figure 1).
A KVM switch is a hardware device that allows a user to control multiple computers
from a single keyboard, video monitor and mouse. The maximum number of computers
that can be controlled from a single KVM switch depends on the number of available
ports provided with the switch. Generally, the more available ports (and number of
advanced features), the more expensive the switch. Scores of vendors provide economical
switches which include 2, 4, 8, or even 16 available ports which many small businesses
will find practical. For larger IT shops, several high end vendors provide switches with a
capacity of 32 or 64 available ports as well as the option to daisy-chain switches together.
For example, the SwitchView® 1000 switch from Avocent Corporation features up to 16
attached switches (via a daisy-chain cable) which provides for a maximum capacity of
256 servers, while the 8-port switch has a 128 server limit. Other combinations are
possible as well — for example, a 16-port and 8-port SwitchView 1000 switch can be
daisy-chained to connect a maximum of 24 servers!
As illustrated in Figure 1, a user connects a keyboard, monitor, and mouse to the KVM
switch, then uses special cables to connect the KVM switch to the servers to be managed.
Control is switched from one computer to another by the use of buttons on the KVM
switch with the KVM passing the signals between the computers and the keyboard,
monitor, and mouse depending on which computer is currently selected. Most KVM
switches also allow control to be switched through keyboard commands such as hitting a
certain HotKey Sequence (often Scroll Lock) rapidly two or three times.
As with any computer device, not all KVM switches are made the same. Some vendors
offer high-end data center KVM switches with advanced capabilities while others market
smaller switches made for the SOHO. Finding the right KVM switch for your
environment can sometimes be tricky. While it may be easy to find a switch from a
reputable vendor that offers the appropriate number of available ports, careful planning is
imperative to ensure the KVM solution you chose works for your environment. For
example, a data center with a mix of Windows, Mac, Sun, and Linux will want to make
certain the vendor provides support for this type of diverse environment. Vendors like
Belkin and Rose Electronics, for example, are notorious for not working well in a Linux
environment.
See the article "Erratic Mouse Behavior with Mouse on Linux and Belkin KVM
Switch" which discusses the difference between Basic PS/2 Mouse Mode and
Advanced PS/2 Mouse Mode.
KVM switching devices use two different types of technology — Analog KVM and
KVM over IP
Analog KVM Switches
With Analog KVM switching, the keyboard, video and mouse signals are passed from a
user console to a specific target (server) connected to the switch. This provides easy plug
and play installation operating completely independent of software and network operating
systems, and provides real-time access between a user and multiple computers. Analog
KVM switches are optimized for environments where users and systems reside in the
same location and is ideal for accessing centralized multi-PC and multi-rack
environments. Vendors like Avocent offer analog KVM solutions with their
SwitchView®, AutoView®, and AMX® line of KVM switches.
KVM over IP Switches
KVM over IP digitizes the keyboard, video and mouse data and uses IP technology to
move the KVM data. KVM over IP connects directly to KVM signals on any computer
(target server) and is completely non-invasive to the computer — no additional software
or hardware is required. This technology leverages a customer's already existing network
infrastructure and supports both local and remote users. Remote users would access the
KVM switching device by navigating to a web page. This provides users with the
flexibility to access managed servers over an internet while not requiring them to be
tethered to a user console in order to access the switch.
KVM over IP works in heterogeneous hardware environments and is ideal for managing
multi-location data centers and branch offices. Avocent KVM over IP solutions, for
example, include full multi-location failover, a direct interface into the new server
management standard (IPMI), and the ability to map local storage media to a remote
location.
This article highlights two popular 8-port analog KVM switches from Avocent — a world
class leader in KVM switch technology. Avocent offers a wide range of affordable and
high-quality switches backed by quality customer service and seamless integration in a
mixed operating environment (Windows, Sun, Mac, and Linux).
SwitchView® 1000
The Avocent
SwitchView®
1000 switch is a 4,
8, or 16-port
keyboard, video,
and mouse (KVM)
device that
Figure 2 - Front of the SwitchView® 1000 supports both USB
Click to enlarge and PS/2
interfaces.
The images included in this section are of the SwitchView® 1000 8-port KVM
Switch (8SV1000-001).
This single user switch has an On-Screen Display (OSD) that supports a 2048 x 1536
high video resolution which is ideal for even the most demanding server room graphics
applications. With a 1U high design, the compact SwitchView 1000 switch does not
compete for valuable rack space in SMB server rooms.
The time-out and password protection feature of the SwitchView KVM provides users
with the benefit of added security when accessing business-critical servers. Setting the
time-out and password can be done using the "OSD Setup Menu".
Installation Tasks
Installing the SwitchView 1000 switch takes only minutes. The SwitchView 1000 can be
rack mounted using the included brackets or used on a table top with the supplied rubber
feet.
The first step is to connect the power cord into the back to the SwitchView 1000 switch
and then to an appropriate power source.
Next, connect the local keyboard, monitor, and mouse of the User Computer Console to
the rear of the
SwitchView 1000
switch. This is the
local computer
(sometimes called
the console) users
will utilize to Figure 3 - Back of the SwitchView® 1000
access the servers Click to enlarge
connected to the SwitchView 1000 switch. The SwitchView 1000 switch provides two
types of interfaces for the local keyboard and mouse — PS/2 and USB. If you are
installing the SwitchView 1000 to a PS/2 interface, it is required to power down all
servers that may already be connected to the switch before connecting the local PS/2
keyboard and mouse to ensure proper installation. If you will be using the USB interface
to connect the user computer, then you do not need to power down servers that may
already be connected before installing the local keyboard and mouse.
Note that the PS/2 and USB interfaces for the local keyboard and mouse cannot be
used simultaneously. You must use either the PS/2 or USB interface — not both.
Finally, connect all of the servers to be managed to an available port on the back of the
SwitchView 1000 switch using the cable appropriate for the server's interface. The
SwitchView 1000 switch uses a special three-in-one combo KVM cable that supports
PS/2 or USB target devices. The DB25 end will plug into an available port on the
SwitchView 1000 switch while the keyboard, monitor, and mouse end plugs into the
server. Note that servers configured with a USB interface for the keyboard and mouse
will only use the one USB connector on the three-in-one combo KVM cable — the
purple mouse connector should not be connected to the server when using the USB
interface.
Although I have never experienced a problem with mouse failures when hot-
plugging a Linux system directly to the SwitchView 1000 switch, it can happen. If
the mouse ever fails or becomes locked, simply use the hotkey sequence ScrLk +
ScrLk + M to reset the mouse or power off the Linux server before connecting it to
the SwitchView 1000.
After all of the servers are connect, power them all up. Both keyboard and mouse
recognition should now be activated and the SwitchView 1000 switch ready for use.
Basic Operations
After powering on all connected servers and the user computer, one of the first things you
will notice is that the "Title Bar" is activated by default. This is the blue box in the upper
right corner of the screen that displays the default Port Name of the currently selected
server. To some people, having the Title Bar on all the time is annoying. To toggle the
Title Bar On/Off, use the hotkey sequence ScrLk + ScrLk + T.
The two consecutive ScrLk (Scroll Lock) keystrokes should be pressed within two
seconds and then followed by the command key which also must be pressed within
two seconds.
To switch between servers, use the buttons on the front of the SwitchView 1000 switch or
the OSD menu. To access the OSD menu, use the hotkey sequence ScrLk + ScrLk +
Spacebar. From the OSD menu, use the Up/Down arrow keys to select the server (port)
to switch to. To deactivate the OSD menu at any time, press ESC (the escape key).
The OSD menu also allows you to assign server names for each port, configure time-outs,
set autoscan capabilities, apply firmware upgrades, and much more. The manual included
with the SwitchView 1000 provides a detailed description for every feature available
from the OSD menu.
Cascading SwitchView Switches
Another popular feature of the SwitchView 1000 is that it supports up to 16 levels of

attached switches using the supplied daisy-chain cable. For example, users can daisy-
chain a maximum of 16 SwitchView 1000 16-port switches (via a daisy-chain cable) to
support up to 256 servers! Other example configurations include 16 SwitchView 1000 8-
port switches which has a 128 server limit or even mixing a single 16-port and 8-port
SwitchView 1000 for a maximum of 24 servers. Cascading multiple switches is a
straightforward task. Simply plug one end of the daisy-chain cable into the "Daisy Chain
Out" port on the rear of the primary SwitchView 1000 switch. Then connect the other end
of the daisy-chain cable into the "Daisy Chain In" port of the secondary SwitchView
1000 switch. Repeat this task for any subsequent SwitchView 1000 switches. Plug the
"Ground Terminator" into the "Daisy Chain Out" port on the rear of the last daisy-
chained SwitchView 1000 switch. When cascading multiple SwitchView 1000 switches,
each switch in the daisy-chain will perform "Auto Initialization" which means users are
free from the hassle of complicated configuration tasks.
SwitchView® 1000 Quick Facts
The SwitchView 1000 is a single user, rack mount

KVM switch with 4, 8 or 16-ports specifically
designed for SMB server rooms
1U design is a space saver in SMB server rooms
Supports PC, Mac, and Sun servers configured with a
USB or PS/2 interface
Supports a local / single user console configured with
either PS/2 or USB interface
Servers connect to the KVM switch using a three-in-
one combo KVM cable that supports PS/2 or USB
target devices
On-Screen Display (OSD) provides simple control
through an on screen menu
Supports 2048 x 1536 high video resolution which is
ideal for even the most demanding server room
graphics applications
Daisy-chaining with auto initialization means users can
connect multiple switches together without
complicated configuration
Time-out and password protection feature provides
users with the benefit of added security when accessing
business-critical servers
Programmable autoscan allows users to customize
scanning times between attached systems
Flash upgradeable means that the product never goes
out of date
Cables for the SwitchView® 1000
Cable PS2/USB for Cable PS2/USB for
Cable PS2/USB for SV1000
SV1000 SV1000
(15FT)
(6FT) (9FT)
Click to enlarge Click to enlarge Click to enlarge

AutoView® 1415
Focused primarily
on midsize data
centers, Avocent
offers the
AutoView® line if
KVM switches.
AutoView KVM
switching systems
Figure 4 - Front of the AutoView® 1415
provide users with
Click to enlarge
advanced cabling
options, local virtual media support, and easier access to servers and other network
devices.
Sun keyboard localization is built-in to support international markets. Users can make use
of PS/2 keyboards with Sun target and Sun keyboard transaction. This allows special Sun
keys to be emulated using specific keystrokes on the PS/2 keyboard.
One of the key features of the AutoView KVM switching systems is advanced cable
management. The AVRIQ intelligent modules with CAT 5 design dramatically reduce
bulky cable clutter, while providing optimal resolution and video settings. The AVRIQ
intelligent modules also offer built-in memory which simplifies configuration by
assigning and retaining unique server names and Electronic ID (EID) numbers for each
attached server. Every AVRIQ module is powered directly from the server and provides
Keep Alive functionality even if the AutoView switch is powered down.
For more information about module and cable options for the AutoView KVM
switching systems, please see the section labeled "AutoView Modules and
Cables".
Also available with all AutoView KVM switching systems is a graphical / multilingual
On-Screen Display (OSD) named OSCAR®. OSCAR is an advanced graphical OSD that
eases system configuration and makes it easy for users to switch, monitor, and locate
target devices. The OSCAR OSD supports multiple languages and is fast and easy to use
because of its mouse-driven functionality.
With the powerful user access control (controlled through OSCAR), an administrator has
complete control over the KVM switch settings and allows granting KVM access to only
certain users. The administrator can also limit the user accounts KVM access to only
specific targets on the switch.
Avocent offers a wide variety of AutoView models from single to dual user support along
with 8-port and 16-port configurations. The table below presents all available AutoView
KVM switching systems - (seven at the time of this writing):
Available AutoView® KVM Switching Systems

Users Computers Platforms Key Features
Provides support for user's USB and/or
AutoView PS/2, USB, Sun PS/2 keyboards and mice.
Single 8
1415 and Serial Support for USB, PS/2, Sun, and serial
target devices.
Dual 8
target devices.
Dual 16
target devices.
AutoView PS/2, USB, Sun Capable of Local virtual media, local
Dual 16
2020 and Serial USB and PS/2 peripheral support.
AutoView PS/2, USB, Sun Local virtual media, local USB and PS/2
Dual 16
2030 and Serial peripheral support.
AutoView PS/2, USB, Sun Single-user IP connectivity with on-
Single 16
3100 and Serial board Web interface.
AutoView PS/2, USB, Sun Dual-user IP connectivity with on-board
Dual 16
3200 and Serial Web interface.
This section and the images included describe the AutoView® 1415 8-port KVM
Switch (AV1415-001).
The Avocent AutoView 1415 is an 8-port single-user KVM switch which provides user
support for USB
and/or PS/2
keyboards and
mice for the user
console. This
KVM switch also
provides support
for USB, PS/2,
Sun, and serial Figure 5 - Back of the AutoView® 1415
target devices. Click to enlarge
The AutoView 1415 has a graphical On-Screen Display (OSCAR) and supports high
video resolutions ideal for even the most demanding server room graphics applications.
Achieve video resolutions of up to 1280 x 1024 with a 100 foot (30 meter) cable and up
to 800 x 600 with a 50 foot (15 meter) cable. Obviously the video resolution will vary
depending on the length of cable between the switch and target (server).
Installation Tasks
Installing the AutoView 1415 switch takes only minutes. The AutoView 1415 can be rack
mounted using the included brackets or used on a table top with the supplied rubber feet.
The first step is to connect the power cord into the back to the AutoView 1415 switch and
then to an appropriate power source. Turn on the power to the AutoView 1415 switch.
Next, connect the local keyboard, monitor, and mouse of the User Computer Console to
the local analog port labeled A on the rear of the AutoView 1415 switch. This is the local
computer (sometimes called the console) users will utilize to access the servers connected
to the AutoView 1415 switch. The AutoView 1415 switch provides two types of
interfaces for the local keyboard and mouse — PS/2 and USB.
Finally, connect all of the servers to be managed to an available Avocent Rack Interface
(ARI) port on the back of the AutoView 1415 switch using with an AVRIQ module or an
IAC module. For more information about module and cable options for the AutoView
KVM switching systems, please see the section labeled "AutoView Modules and Cables".
To connect a server (target) using an AVRIQ module:
1. Locate the AVRIQ module(s) that will be used to connect the servers to the
AutoView switch.
2. Attach the appropriately color-coded cable ends to the keyboard, video, and
mouse ports on the first server being connected to the switch.
3. Attach one end of a CAT 5 or CAT 6 cable to the RJ-45 connector on the
AVRIQ module.
4. Connect the other end of the CAT 5 or CAT 6 cable to the desired ARI port
on the back of the AutoView switch.
5. Repeat steps 2 through 4 for each server being connected to the switch.
To connect a server (target) using an IAC module:
1. Locate the IAC module(s) that will be used to connect the servers to the
AutoView switch.
2. Attach the appropriately color-coded cable ends of the IAC module to the
keyboard, video, and mouse ports on the first server being connected to the
switch.
3. Attach the other end of the IAC module to an open ARI port on the back of
the AutoView switch.
4. Repeat steps 1 through 3 for each server being connected to the switch.
The AutoView switching system enables users to auto detect and manually configure
each port on the AutoView switch using the OSCAR interface setup and configuration.
Cascading AutoView Switches
As with the SwitchView 1000, the AutoView switching systems can support up to 16
levels of attached switches providing users access up to 256 servers. Users can cascade
multiple 1415/1515/2015 switches as well as adding legacy switches. In a cascaded
switching system, an Avocent Rack Interface (ARI) port on the back of the main
AutoView switch will be connected to the Avocent Console Interface (ACI) port on each
cascaded AutoView switch. Each cascaded switch can then be connected to a server with
an AVRIQ module or IAC. Chapter 2 in the AutoView Switch Installer/User Guide
provides detailed instructions cascading AutoView switches.
Basic Operations
Controlling target servers from the AutoView 1415 switch is done from the keyboard,
video, and mouse connected to the analog port in the rear of the switch. The AutoView
1415 switch users the OSCAR GUI interface which features intuitive menus to configure
the system and selected servers.
To access the main dialog box, press Print Screen to launch the OSCAR interface.
By default, the OSCAR interface can be initiated by pressing either Print Screen
or by pressing the Control key twice within one second. Using the Setup - Menu
option in OSCAR, users can also configure the OSCAR interface to be invoked by
pressing the Alt key twice or the Shift key twice. Turning off all options will
leave Print Screen as the default option.
From the OSCAR main window, users can view connected servers by name, port, or even
by Electronic ID Number (EID) which is enabled in each AVRIQ module and IAC. The
Port column indicates the Avocent Rack Interface (ARI) port which the server is
connected to. Also available to the right of each server is a set of icons representing the
status of each connected server — online, offline and not available, cascaded status, or
the AVRIQ module is being upgrade. It also displays which server (or servers if
broadcasting is enabled) is being accessed.
Notice that OSCAR provides default names for each server which can be which can be
changed to reflect the actual name of the server if desired.
Using the arrow keys from the Main dialog, select a server and press [ENTER] or double-
click with the mouse. After selecting a server, the switch will reconfigure the keyboard
and mouse to the proper settings for that server. Note that while this is the most popular
way to select which server to work with, there are other options. For example, pressing
Print Screen and Backspace toggles the user between the previous and current
connections. Another method, referred to as Soft Switching, allows the user to press Print
Screen and then type the first few characters of the servers name or the port number. To
soft switch by name, the display order of the server list must be by name. To soft switch
by port number, the display order of the server list must be by port number. Finally, users
can completely disconnect from a server by pressing Print Screen followed by Alt+0.
This leaves the user in a free state, which no server selected. This option is also available
from the OSCAR main dialog window. Note that the status flag on the desktop displays
as Free.
Using the OSCAR interface, users have access to a wide variety of setup and
configuration options. For example, providing a user friendly and unique name for each
server in the server list, configuring security, setting up custom scan patterns, choosing
the language supported by the OSD, and choosing the appropriate keyboard country code
settings. Other advanced features are also available like setting up broadcasting to
simultaneously control multiple servers through keyboard and mouse actions and
identifying the appropriate number of ports on an attached cascaded switch.
Chapter 3 in the AutoView Switch Installer/User Guide provides a wealth of information

on configuring as well as basic operations of the switch.
Flash Upgrades
Flash upgrades are available to all AutoView switching systems to ensure the switch is
always running the most current version of the firmware. All firmware upgrade files are
available from http://www.avocent.com/support under the section Popular Links / All
Product Upgrades. Users will need to connect the serial port (COM port) of an available
PC (running Microsoft Windows) to the serial port on the back of the switch using a null
model serial cable (DB-male). After downloading the upgrade file to the connected
Microsoft Windows PC, run it and select the appropriate COM Port from the COM Port
menu. Clicking Update will upgrade the firmware. After the firmware is updated, an
Update Completed message is displayed. Clicking the Close button exits the application
and the switch automatically reboots. Appendix A in the AutoView Switch Installer/User
Guide provides detailed instructions for upgrading the firmware of the switch. With a 1U
high design, the compact AutoView 1415 switch does not compete for valuable rack
space in SMB server rooms.
Integrates with Avocent AutoView 3100 and 3200 KVM switches. Allows users to add
alternative method of access via an IP network Operating System (OS) independent.
Ensures connection to the attached servers regardless of the health or type of OS.
AutoView® 1415 Quick Facts
The AutoView 1415 is a single user, rack mount KVM

switch with 8 ports specifically designed for SMB
server rooms
1U design is a space saver in SMB server rooms
Supports PS/2, USB, Sun, and serial target (server)
devices
Supports a local / single user console configured with
either PS/2 or USB interface
Unique cable design based on CAT 5 to help reduce
bulky cable clutter
Servers connect to the KVM switch using either an
Integrated Access Cable (IAC) or a AVRIQ Server
Interface Module (with a user supplied CAT 5 cable up
to 100 feet)
High-quality, multi-language, graphical On-Screen
Display (OSD) named OSCAR® making it easy for
users to switch, monitor, and locate target devices
Time-out and password protection feature provides
users with the benefit of added security when accessing
business-critical servers
Programmable autoscan allows users to customize
scanning times between attached systems
Flash upgradeable means that the product never goes
out of date
Sun keyboard localization: Supports international
markets
Sun keyboard translation: Allows users to use PS/2
keyboards with Sun targets
Integrates with Avocent AutoView 3100 and 3200
KVM switches
Operating System (OS) independent
AutoView Modules and Cables
The AutoView switching solutions provide support for USB and/or PS/2 keyboards and
mice for the user console and USB, PS/2, Sun or serial support for target devices — all in
a single solution switch. All AutoView KVM switches include two unique and advanced
cabling options for target devices:
Integrated Access Cables (IAC) provide keyboard, video and mouse

connectivity for both PS/2 and USB interfaces in one slim CAT 5 cable with
lengths of 7, 10 and 15 feet. This unique cable design reduces cable bulk
plus saves time and money. The IAC is simply an AVRIQ Server Interface
Module already wired with a CAT 5 cable. The Avocent model number for
PS/2 and USB integrated access cables are:
PS2IAC-7 - (7 feet - P2/2) USBIAC-7 - (7 feet - USB)
Users can also purchase just the AVRIQ Server Interface Modules. These
modules provide support for PS/2, USB, Sun, and serial targets as well as
cable lengths greater than 15 feet (but less than 100 feet) between the target
device and the switch. The AVRIQ server interface module connects to the
target server. Users then connect their own CAT 5 or CAT 6 network cable
(up to 100 feet) from the AVRIQ server interface module to the AutoView
KVM switch.
Both cabling options automatically assign and retain unique server names for each
attached server, which simplifies installation and eases re-configuration.
Modules and Cables for the AutoView® 1415

AVRIQ-PS2 AVRIQ-SRL AVRIQ-USB

AVRIQ-VSN PS2IAC-X USBIAC-X
USBIAC-7 - (7 feet)
USBIAC-10 - (10 feet)
PS2IAC-7 - (7 feet) USBIAC-15 - (15 feet)
PS2IAC-10 - (10 feet)
PS2IAC-15 - (15 feet)
Booting Options and Using EEPROM

EEPROM Command
The eeprom command is located in /usr/sbin/eeprom. The eeprom command is used to

display or change the values of parameters in the EEPROM. It processes parameters in
the order given. When processing a parameter accompanied by a value, eeprom makes
the indicated alteration to the EEPROM; otherwise it displays the parameter's value.
When given no parameter specifiers, eeprom displays the values of all EEPROM
parameters. A '-' (hyphen) flag specifies that parameters and values are to be read from
the standard input (one parameter or parameter = value per line). Only the super-user
(root) may alter the EEPROM contents.
When the eeprom command is executed in user mode, the parameters with a trailing
question mark (?) need to be enclosed in double quotation marks (" ") to prevent the shell
from interpreting the question mark. Preceding the question mark with an escape
character (\) will also prevent the shell from interpreting the question mark.
The remainder of this section descibes some of the common usages of the eeprom
command in Solaris.
Query Values
To query all current EEPROM values, simply use the eeprom command with no
arguments. If you only want to determine one EEPROM value, specify it as an argument.
Here are two examples of using the eeprom command:
# eeprom auto-boot?
auto-boot?=true
# eeprom
test-args: data not available.
diag-passes=1
pci-probe-list=7,c,3,8,d,13,5
local-mac-address?=false
fcode-debug?=false
ttyb-rts-dtr-off=false
ttyb-ignore-cd=true
ttya-rts-dtr-off=false
ttya-ignore-cd=true
silent-mode?=false
scsi-initiator-id=7
oem-logo: data not available.
oem-logo?=false
oem-banner: data not available.
oem-banner?=false
ansi-terminal?=true
screen-#columns=80
screen-#rows=34
ttyb-mode=9600,8,n,1,-
ttya-mode=9600,8,n,1,-
output-device=screen
input-device=keyboard
load-base=16384
auto-boot?=true
boot-command=boot
diag-file: data not available.
diag-device=disk net
boot-file: data not available.
boot-device=disk net
use-nvramrc?=false
nvramrc: data not available.
security-mode=none
security-password: data not available.
security-#badlogins=0
mfg-mode=off
diag-level=max
diag-switch?=false
error-reset-recovery=boot
auto-boot?
Used to control the auto-boot feature. This option controls whether the system directly
boots up. You can disable auto-boot so next time it stays at the ok prompt for starting
installations. Use the following command and reboot the system:
# eeprom "auto-boot?"=false
Configuring Telnet / FTP to login as root (Solaris)
Now before getting into the details of how to configure Solaris for root logins, keep in
mind that this is VERY BAD security. Make sure that you NEVER configure your
production servers for this type of login.
Configure Telnet for root logins
Simply edit the file /etc/default/login and comment out the following line as
follows:
# If CONSOLE is set, root can only login on that device.
# Comment this line out to allow remote login by root.
#
# CONSOLE=/dev/console
Configure FTP for root logins
First remove the 'root' line from /etc/ftpusers.
Also, don't forget to edit the file /etc/ftpaccess and comment out the 'deny-uid' and
'deny-gid' lines. If the file doesn't exist, there is no need to create it.
NOTE: If you are using Solaris 9 or Solaris 10, the ftp* files are located in /etc/ftpd
Configuring Power Management (Sun Blades Only)
Hard drive and system power management are adjustable with the dtpower application
with Solaris 8 7/01 release and higher. However, the power management features were
not present in Solaris 8 10/00 and Solaris 8 1/01 releases. By default, power management
is enabled on all new Sun Blade systems. (I really wish Sun would change this!)
When the system is in low-power mode, the hard drive eventually spins down to conserve
power. Later, when you perform a task that accesses the hard drive, the hard drive spins
up again. You might have to wait a few seconds for the hard drive to spin up to full speed.
If you find that the delay is inconvenient, you can turn off Energy Star power
management using one of the two methods provided below:
Method #1
• You can disable the Energy Star power management feature by using the dtpower
application.
Login as the "root" account and at the system prompt type:
# /usr/openwin/bin/dtpower
The dtpower application is displayed.
Under the Current power saving scheme menu, select Disabled.
Press the OK button.
Method #2
The main configuration file for controller Power Management is /etc/power.conf.
• As the root user ID, edit the /etc/power.conf file as follows to disable all
Automatic Power Management:
#
# Copyright (c) 1996 - 2001 by Sun Microsystems, Inc.
# All rights reserved.
#
#pragma ident "@(#)power.conf 1.14 99/10/18 SMI"
#
# Power Management Configuration File
#
# Statefile Path
statefile /usr/.CPR
# Auto-Shutdown Idle(min) Start/Finish(hh:mm) Behavior

autoshutdown 30 9:00 9:00 noshutdown
device-dependency-property removable-media /dev/fb

autopm disable
system-threshold always-on
• Run the command:
# /usr/sbin/pmconfig
This utility is run from the command line after manual changes have been made to
the /etc/power.conf file. For editing changes made to the /etc/power.conf
file to take effect, users must run pmconfig.
pmconfig is also run at each system boot.
Using Package Manager on Solaris
Adding a Package
# pkgadd -d samba-2.0.5-sol7-sparc-local
Checking for Packages
# pkginfo | grep -i samba
application SMCsamba samba
Removing a Package
# pkgrm SMCsamba
Diagnostic Command - (Sun Solaris)

prtdiag
Use the following command to obtain detailed diagnostics information about your system
configuration:
# /usr/platform/ùname -i`/sbin/prtdiag -v
System Configuration: Sun Microsystems sun4u Sun Blade 150

(UltraSPARC-IIe 650MHz)
System clock frequency: 93 MHZ
Memory size: 1.75GB
==================================== CPUs
====================================
E$ CPU CPU Temperature
CPU Freq Size Impl. Mask Die Ambient
--- -------- ---------- ------ ---- -------- --------
0 650 MHz 512KB US-IIe 3.3 56 C 29 C
================================= IO Devices
=================================
Bus Freq
Brd Type MHz Slot Name Model
--- ---- ---- ---------- --------------------------------
----------------------
0 pci 33 7 isa/dma-isadma (dma)
0 pci 33 7 isa/serial-su16550 (serial)
0 pci 33 7 isa/serial-su16550 (serial)
0 pci 33 8 sound-pci10b9,5451.10b9.5451.1 (+
0 pci 33 12 network-pci108e,1101.1 (network)
SUNW,pci-eri
0 pci 33 12 firewire-pci108e,1102.1001 (fire+
0 pci 33 13 ide-pci10b9,5229.c3 (ide)
0 pci 33 19 SUNW,m64B (display)
ATY,RageXL
============================ Memory Configuration

============================
Segment Table:
-----------------------------------------------------------------------
Base Address Size Interleave Factor Contains
-----------------------------------------------------------------------
0x0 256MB 1 Label DIMM0
0xc0000000 512MB 1 Label DIMM3
=============================== usb Devices

===============================
Name Port#
------------ -----
device 4
=============================== device#4 Devices

===============================
Name Port#
------------ -----
keyboard mouse
============================ Environmental Status
============================
Fan Speeds:
----------------------------
Fan Device Speed
----------------------------
system 100%
================================ HW Revisions
================================
ASIC Revisions:
---------------
ebus: Rev 1
System PROM revisions:

----------------------
OBP 4.6.5 2002/06/03 16:49
POST 2.0.1 2001/08/23 17:13
prtconf
Use the following command to obtain detailed system information about your Sun Solaris
installation:
# /usr/sbin/prtconf
System Configuration: Sun Microsystems sun4u

Memory size: 1792 Megabytes
System Peripherals (Software Nodes):
SUNW,Sun-Blade-100
packages (driver not attached)
SUNW,builtin-drivers (driver not attached)
deblocker (driver not attached)
disk-label (driver not attached)
terminal-emulator (driver not attached)
obp-tftp (driver not attached)
dropins (driver not attached)
kbd-translator (driver not attached)
ufs-file-system (driver not attached)
chosen (driver not attached)
openprom (driver not attached)
client-services (driver not attached)
options, instance #0
aliases (driver not attached)
memory (driver not attached)
virtual-memory (driver not attached)
pci, instance #0
ebus, instance #1
flashprom (driver not attached)
eeprom (driver not attached)
idprom (driver not attached)
isa, instance #0
dma, instance #0
floppy, instance #0
parallel (driver not attached)
power, instance #0
serial, instance #0
serial, instance #1
network, instance #0
firewire, instance #0
usb (driver not attached)
pmu, instance #0
i2c, instance #0
temperature, instance #0
card-reader (driver not attached)
dimm (driver not attached)
ppm, instance #0
beep, instance #0
fan-control, instance #0
sound (driver not attached)
ide, instance #0
disk (driver not attached)
cdrom (driver not attached)
dad, instance #0
dad, instance #1
sd, instance #0
pci (driver not attached)
SUNW,m64B, instance #0
SUNW,UltraSPARC-IIe, instance #0
pseudo, instance #0
Configuring apropos and whatis - (The windex file)

Overview
Many UNIX users are familiar with the apropos and whatis commands.
The whatis command is used to display a one-line summary about a keyword as in the
following example:
# whatis scsi
scsi scsi (4) - configuration files for SCSI target
drivers
The apropos command is used to locate commands by keyword lookup. The apropos
utility displays the man page name, section number, and a short description for each man
page whose NAME line contains keyword as in the following example:
# apropos IDE
dad dad (7d) - driver for IDE disk devices
uata uata (7d) - IDE Host Bus Adapter Driver
Creating /usr/share/man/windex
Before using either the apropos, whatis, or make -k commands, it is necessary to create
the system generated index file: /usr/share/man/windex. Failing to have this file
generated will result in the following error when attempting to use any of the above
commands:
# apropos IDE
/usr/share/man/windex: No such file or directory
To create the /usr/share/man/windex, use the catman, as in the following example:
# /usr/bin/catman -w
This utility will search the MANPATH and create the windex file. If you would like to
specify which directories yourself, you can use the -M switch.
Using Serial Consoles - (Solaris / Linux)

Overview
The following article documents some of the tips for connecting the serial port of a UNIX
Server (Sun SPARC / Linux) to the serial port (console) of a Sun Server. This is often
helpful and even necessary when performing routine administrative tasks or initiating
critical and/or long running processes. Access to the serial console for many Sun servers
is the only way to perform administrative tasks given these servers do not come with a
frame buffer (i.e. video card).
There are times when I need to initiate a long running job but cannot remain connected to
the network for the duration of its execution. In cases like this, I can connect to the serial
console of the Sun server, initiate the job and disconnect. The job will remain running
even when I drop my connection to the serial port. I can, at a later time, reconnect to the
serial console to determine the results.
The first two sections of this article explain the applications (programs) used from a Sun
SPARC server and then a Linux server for obtaining a serial console connection. The
remainder of this article attempts to describe the details (cables, connections, adapters) of
obtaining a serial console connection to/from different Sun SPARC servers.
Connect From Sun SPARC Serial Port

From a Sun machine, if you wanted to access the serial console of another computer (ie.
Linux, Sun, etc.), you would use the tip command. The configuration file for tip is
/etc/remote. In most cases, you will be concerned with the hardwire entry in this file.
First, connect the two machines by their serial ports (null modem if required), and from
the Sun SPARC (Solaris) machine, type the following at the command-line to connect to
the serial console of the other machine (Solaris / Linux):
# tip hardwire
Below is an example /etc/remote file from the Sun SPARC (Solaris) machine that
contains the hardwire entry to go through serial port B (/dev/term/b). If you wanted to
change this entry to go out through serial port A instead, change "/dev/term/b" to
"/dev/term/a".
cuab:dv=/dev/cua/b:br#2400
dialup1|Dial-up system:\
:pn=2015551212:tc=UNIX-2400:
hardwire:\
:dv=/dev/term/b:br#9600:el=^C^S^QÛ^D:ie=%$:oe=^D:
tip300:tc=UNIX-300:
tip1200:tc=UNIX-1200:
tip0|tip2400:tc=UNIX-2400:
tip9600:tc=UNIX-9600:
tip19200:tc=UNIX-19200:
UNIX-300:\
:el=^DÛ^C^S^QÔ@:du:at=hayes:ie=#$%:oe=^D:br#300:tc=dialers:
UNIX-1200:\
:el=^DÛ^C^S^QÔ@:du:at=hayes:ie=#$%:oe=^D:br#1200:tc=dialer
s:
UNIX-2400:\
s:
UNIX-9600:\
s:
UNIX-19200:\
:el=^DÛ^C^S^QÔ@:du:at=hayes:ie=#$%:oe=^D:br#19200:tc=diale
rs:
VMS-300|TOPS20-300:\
:el=^ZÛ^C^S^QÔ:du:at=hayes:ie=$@:oe=^Z:br#300:tc=dialers:
VMS-1200|TOPS20-1200:\
:el=^ZÛ^C^S^QÔ:du:at=hayes:ie=$@:oe=^Z:br#1200:tc=dialers:
dialers:\
:dv=/dev/cua/b:
--------------------------------------------------------------------
The attributes are:
dv device to use for the tty

el EOL marks (default is NULL)
du make a call flag (dial up)
pn phone numbers (@ =>'s search phones file; possibly taken from
PHONES environment variable)
at ACU type
ie input EOF marks (default is NULL)
oe output EOF string (default is NULL)
cu call unit (default is dv)
br baud rate (defaults to 300)
fs frame size (default is BUFSIZ) -- used in buffering writes
on receive operations
tc to continue a capability
Connect to a Sun Serial Console from Linux
Linux provides two methods (programs) that can be used to connect to a serial console of
a Sun server.
Connecting Using minicom
The first application I'll talk about is "minicom". Most Linux distributions (i.e. Red Hat)
already include minicom. If your particular distribution does not include minicom, you
can download it from the following URL: http://www.pp.clinet.fi/~walker/mcdevel.html.
Once you have Minicom installed, start it up with the command "minicom". Press "Ctrl-
A Z" to get to the main menu. Press "o" to configure minicom. Go to "Serial port setup"
and make sure that you are set to the correct "Serial Device" and that the speed on line E
matches the speed of the serial console you are connecting to. (In most cases with Sun,
this is 9600.) Here are the settings I made when using my Serial A / COM1 port on my
Linux box:
+----------------------------------------------------------------------
-+
| A - Serial Device : /dev/ttyS0
|
| B - Lockfile Location : /var/lock
|
| C - Callin Program :
|
| D - Callout Program :
|
| E - Bps/Par/Bits : 9600 8N1
|
| F - Hardware Flow Control : Yes
|
| G - Software Flow Control : No
|
|
|
| Change which setting?
|
+----------------------------------------------------------------------
-+
After making all necessary changes, hit the ESC key to go back to the "configurations"
menu. Now go to "Modem and dialing". Change the "Init string" to "~^M~". Save the
settings (as dflt), and then restart Minicom. You should now see a login prompt.
Connecting Using UUCP
Another common application to use in Linux for connecting to a serial console is UUCP.
Most Linux distributions include the UUCP application. Start UUCP with the command
"cu -l [device] -s [speed]", where [device] is the serial port you are using, such as
ttyS0 (COM1) or ttyS1 (COM2), and [speed] is the speed of the serial console that you
are connecting to.
Here is an example:
# cu -l /dev/ttyS0 -s 9600
You may need to hit enter before you see the login prompt. If you see a bunch of weird
characters, then you probably specified the wrong speed.
To exit, just type "~.".
Sun Blade 100/150
• Connecting to a Blade 100/150

To obtain a serial console connection to a Sun Blade 100/150 you will need the
following (These procedures will work to an Ultra 5/10 as well):
o Connect the serial port of your local PC/workstation to the DB9 Serial port
on the back of the Sun Blade (or Ultra 5/10) using a serial cable (straight
through).
o You will need to use a null modem adapter.
o Communication settings:
Bits per second: 9600

Data bits: 8
Parity: None
Stop bits: 1
Flow Control: Hardware
NOTE: You will not be able to make use of the serial console if the Sun server was booted
with the keyboard/mouse plugged in. In order to make use of the serial console, you will
need to disconnect the keyboard/mouse and reboot the Sun server. On the Sun Blade
100/150, if the keyboard/mouse are plugged in during the boot phase, all console output
will be redirected to the VGA console.
• Connecting from a Blade 100/150
To obtain a serial connection from a Sun Blade 100/150 to another server

(possibly another Sun SPARC machine) you will need the following (These
procedures will work from an Ultra 5/10 as well):
o On the back of a Sun Blade 100/150 (or Ultra 5/10) there is only one serial
port that is dedicated to serial A (/dev/ttya). This serial port is typically
being used by the console and will often require you to use Serial B
(/dev/ttyb). This is where it gets fun. There is a second serial port
connector located on the motherboard (actually the PCI riser card) labeled
J13. The PCI riser card is a PWA-GROVER-PLUS_RISERCARD
411707500011 and requires a special cable. The special cable connects to
the PCI riser card (J13) on one end while the other end is a DB9 male port
that will use one of your available PCI dust cover slots. This is the only
way I have found to make a connection from a Sun Blade (or Ultra 5/10);
using serial port B out which requires this special cable to be installed in
order to have access to serial port B.
Click here or here to see an exploded view of an Ultra 10 Workstation -

System Breakdown. The special cable I am refering to is Sun
Manufacturing Part# 370-3165 - Serial B and Parallel Cable Assembly -
(Code 3a) in the Ultra 10 Workstation System Breakdown. I needed to
order the Ultra 10 Cable Service Kit/FRU (370-3267) in order to obtain
this cable. You can order this kit from Ajava, Partsolver, Trident Computer
Resources, Inc., Asset Conversion Specialists, Inc., or Sun Microsystems.
o After installing the the Serial B and Parallel Cable Assembly in your Sun
Blade, you will have access to serial port B (/dev/ttyb). Connect the new
DB9 serial port (serial B) from the Sun Blade to the back of the server
(Sun, Linux) you want to make a serial console connection to. In most
cases, this will be using a straight through serial cable.
o For most connections to a Sun SPARC, you will need to use a null modem
adapter.
o From the Sun Blade (or Ultra 5/10) use the tip program to initiate the
serial console connection to the other server. Ensure that you edit the
/etc/remote file from the Sun Blade you are connecting from and change
the hardwire entry to use serial B - /dev/term/b.
# tip hardwire
Sun E450
• Connecting to a Sun E450
To obtain a serial console connection to a Sun E450 you will need the following:
o Connect the serial port of your local PC/workstation to the DB25 Serial
A/B port on the back of the Sun E450 using a serial cable (straight
through). There is only one serial port on the back of an E450 that
contains both Serial A and Serial B. When you plug directly into the serial
port on the back of the E450, you are accessing Serial A.
Data bits: 8
Parity: None
Stop bits: 1
• Connecting from a Sun E450
To obtain a serial connection from a Sun E450 to another server (possibly another
Sun SPARC machine) you will need the following:
o On the back of a Sun E450, there is only one DB25 (female) serial port
(labeled Serial A/B) that is used to contain wiring for both Serial A and
Serial B. The system provides two serial communications ports through a
single, shared DB25 connector located on the rear panel. If you are to plug
a serial cable directly into the DB25 serial port on the back of an E450,
you will only be accessing the primary port (Serial A). This will not work
to get a serial connection out from since it is reserved for the console of
the machine. You will need to obtain access to Serial B (which is
contained within the shared Serial A/B port) by using a special Y-Cable
(serial splitter). In order to access the secondary port (Serial B), a serial
port splitter cable (Sun Part#: X985A or 530-1869) must be attached to the
rear panel serial port A/B connector. The serial splitter connects to the
Serial A/B - DB25 (female) connection on the back of the E450 to give
you two DB25 (female) connections - one for Serial A and the other for
Serial B. Here are several places where I found the serial splitter:
 Sun Store - (Spare Parts)
 Ultra Spec Cables
 Computer Giants
 anything & everything 4 SUN Microsystems Computers
 Sun E450 Serial Port and Cable Pinouts (From Stokely Consulting)
You will need to use Serial Port B to make a connection from the E450 to
another server. Connect the Sun E450 from its Serial B to the back of the
other server (Sun, Linux) you want to make a serial console connection to.
In most cases, this will be using a straight through serial cable.
If you are connecting from the Sun E450 to another machine (i.e. Sun
Blade, Sun Ultra, etc) that has a normal DB9 male port, you can use a
Belkin F2L088-06 DB9 Female/DB25 Male Modem Cable (often with a
null modem adapter):
 Belkin Pro Series AT Serial Modem Cable 6ft

 Belkin PRO Series - Serial cable - DB-9 (F) - DB-25 (M) - 6 ft
 Belkin F2L088-06 DB9 Female/DB25 Male Modem Cable
 Belkin Pro Series AT Serial DB9F to DB25M 6' Modem cable
adapter.
o From the E450 use the tip program to initiate the serial console
connection to the other server. Ensure that you edit the /etc/remote file
from the machine you are connecting from (the E450) and change the
hardwire entry to use serial B - /dev/term/b.
# tip hardwire
Sun E250
• Connecting to a Sun E250
To obtain a serial console connection to a Sun E250 you will need the following:
o Connect the serial port of your local PC/workstation to the DB25 Serial A
port on the back of the Sun E250 using a serial cable (straight through).
There are two DB25 serial ports on the back of an E250. Make sure you
connect to Serial A.
Data bits: 8
Parity: None
Stop bits: 1
• Connecting from a Sun E250
To obtain a serial connection from a Sun E250 to another server (possibly another
o On the back of a Sun E250, there are two DB25 (female) Serial Ports for
Serial A and Serial B. Serial A is used for other machines to obtain a serial
console connection into the E250. You will need to use Serial Port B to
make a connection from the E250 to another server. Connect the Sun E250
from its second serial port (serial B) to the back of the server (Sun, Linux)
you want to make a serial console connection to. In most cases, this will
be using a straight through serial cable.
If you are connecting from the Sun E250 to another machine (i.e. Sun
Blade, Sun Ultra, etc) that has a normal DB9 male port, you can use a
Belkin F2L088-06 DB9 Female/DB25 Male Modem Cable (often with a
null modem adapter):
 Belkin Pro Series AT Serial Modem Cable 6ft

 Belkin PRO Series - Serial cable - DB-9 (F) - DB-25 (M) - 6 ft
 Belkin F2L088-06 DB9 Female/DB25 Male Modem Cable
 Belkin Pro Series AT Serial DB9F to DB25M 6' Modem cable
adapter.
o From the E250 use the tip program to initiate the serial console
connection to the other server. Ensure that you edit the /etc/remote file
from the machine you are connecting from (the E250) and change the
hardwire entry to use serial B - /dev/term/b.
# tip hardwire
Sun V100
• Connecting to a Sun V100
To obtain a serial console connection to a Sun V100 you will need the following:
o Connect the serial port of your local PC/workstation to the serial port
(serial port B) on the back of the Sun V100. The Sun V100 has two serial
ports on the back of it. To make a serial connection to the Sun V100, you
will be connecting to Serial A (LOM A). This is the "Lights Out
Management" port used for issuing LOM commands.
Depending on the type of device you use to connect to the Sun V100
server, you may need to use either a DB25 or DB9 serial adapter (both
included with the Sun V100).
o Connecting Sun SPARC to Sun V100
To connect to a Solaris tip session or to a VT100 terminal, you need to

use either the DB25 (25-Pin DSUB Male to 8-POS RJ-45 Female) adapter
that is supplied by Sun (Sun Part# 530-2889) with the V100, or an
alternative adapter that performs the same pin crossovers. The Sun-
supplied DB25 adapter (530-2889) enables you to connect to any Sun
system.
Insert one end of the standard RJ-45 patch cable supplied with the Sun
Fire V100 server into Serial A (LOM). Insert the other end of the RJ-45
patch cable into the supplied DB25 adapter. Finally, attach the adapter to
the appropriate port in your serial device.
Pin Crossovers in the Sun DB-25 (25-Pin) Adapter

Serial Port (RJ-45 Connector) Pin 25-Pin Connecter
Pin 1 (RTS) Pin 5 (CTS)
Pin 2 (DTR) Pin 6 (DSR)
Pin 3 (TXD) Pin 3 (RXD)
Pin 4 (Signal Ground) Pin 7 (Signal Ground)
Pin 6 (RXD) Pin 2 (TXD)
Pin 7 (DSR) Pin 20 (DTR)
Pin 8 (CTS) Pin 4 (RTS)
o Connecting PC, Laptop or handheld computer to Sun V100
Some devices, such as a PC, laptop or handheld computer, require you to

use either a male or female DB-9 adapter. The Sun DB9 adaptor (Sun Part:
530-3100-xx) is a 9-Pin DSUB female to 8-POS RJ-45 female adapter
included with the Sun V100. The following table is the pin crossovers:
Insert one end of the standard RJ-45 patch cable supplied with the Sun
Fire V100 server into Serial A (LOM). Insert the other end of the RJ-45
patch cable into the supplied DB9 adapter. Finally, attach the adapter to
the appropriate port in your serial device.
Pin Crossovers in the DB-9 (9-Pin) Adapter

Serial Port (RJ-45 Connector) Pin 9-Pin Connector
Pin 1 (RTS) Pin 8 (CTS)
Pin 2 (DTR) Pin 6 (DSR)
Pin 3 (TXD) Pin 2 (RXD)
Pin 6 (RXD) Pin 3 (TXD)
Pin 7 (DSR) Pin 4 (DTR)
Pin 8 (CTS) Pin 7 (RTS)
o You will NOT need to use a null modem adapter for either the DB25 or
DB9 connections.
o Communication settings for both DB25 and DB9 connections:
Data bits: 8
Parity: None
Stop bits: 1
• Connecting from a Sun V100
To obtain a serial connection from a Sun V100 to another server (possibly another
o ...
o ...
o ...
Determine Which Package a Particular File Belongs To -

(Sun Solaris)
Use the pkgchk command to determine which package a particular file belongs to. The
syntax is:
# /usr/sbin/pkgchk -l -p /absolute/path/todir
For example,
# /usr/sbin/pkgchk -l -p /usr/bin/pgrep
Pathname: /usr/bin/pgrep
Type: regular file
Expected mode: 0555
Expected owner: root
Expected group: bin
Expected file size (bytes): 14688
Expected sum(1) of contents: 63968
Expected last modification: Mar 16 05:53:45 AM 2000
Referenced by the following packages:
SUNWcsu
Current status: installed
You can also simply query the packages directory as follows:
# grep /usr/bin/pgrep /var/sadm/install/contents

/usr/bin/pgrep f none 0555 root bin 14688 63968 953204025 SUNWcsu
Cannot open '/etc/path_to_inst' - (Solaris)

For those who have ever come across the error: Cannot open '/etc/path_to_inst',
this article provides an easy way in which to rebuild this file.
The error indicates that the system can not find the /etc/path_to_install file. It is
possible that the file may be really missing or corrupted and needs to be rebuild.
To rebuild this file, boot the system with -ar option as follows:
ok>boot -ar
Press enter to select default values for the questions asked during booting and select yes
to rebuild /etc/path_to_install
The /etc/path_to_inst on your system does not exist or is empty. Do you
want to
rebuild this file [n]? y
The system will continue booting after rebuilding the file.
Using NFS - (Solaris)

This brief article touches on several of the important commands that are used to NFS a
file system on Solaris. Now keep in mind that with most Solaris configurations; enabling
a Sun Solaris server to mount or share a file system, the required daemons will already be
running. If not, this article may help you with this process.
The first thing to ensure is that the proper daemons for running NFS are started. If unsure,
I will typically just run them when I cannot determine whether or not they are running:
$ su -
$ cd /usr/lib/nfs
$ ./mountd
$ ./nfsd
NOTE:
• mountd: RPC server that answers requests for NFS access information and file
system mount requests
• nfsd: The daemon that handles client file system requests
Sharing A File System
The following example will share a file system /software so that others may be able to
mount it:
# share /software
If I want to check all file systems being shared from my system:
# share
- /software rw ""
How to NFS A File System
Now, from another machine, I want to NFS the file system that is being shared above:
# mount -F nfs alex:/software /mnt/software
How to Unmount an NFS File System
Finally, let's unmount the previously mounted file system:
# umount /mnt/software
Introduction to Solaris Volume Manager - (Solaris 9)

Overview
Solaris Volume Manager is a software product packaged with included with the Sun
Solaris 9 operating system that allows the System Administrator to manage a large
number of disks and the data contained on those disks.
NOTE: Solaris 8 included a product known as "Solstice DiskSuite" and came on an
extra CD (that you might only get with the server media set, I'm not sure). In Solaris
9 it has been renamed to "Solaris Volume Manager" and included in the OS, but is
basically just the next rev of DiskSuite.
Here's a link to a Sun white paper that talks about it:
wwws.sun.com/software/whitepapers/solaris9/volume_manager.pdf
There are many uses for Volume Manager but most tasks center around the following:
• Large storage capacity

• Data availability
• I/O performance enhancements
The Volume Manager software uses virtual disks to manage physical disks. In Volume
Manager, a virtual disk is called a volume.
NOTE: If you have ever worked with Solstice DiskSuite with Solaris 8 and lower,
you should note that the virtual disks were named metadevices back then. It is for
these historical reasons that some command-line utilities also refer to a volume as a
metadevice.
A volume is functionally the same as a physical disk from the applications view.
DiskSuite converts all I/O requests directed at a volume into I/O requests to the
underlying member disks. Volume Manager volumes are built from slices (disk
partitions).
Take for example a situation in where you wanted to create more storage capacity, it is
simple to use Volume Manager to "fool" the system into thinking that a large collection of
small slices is one large physical disk. After you have created a volume from these slices,
you can immediately begin using it just as any "real" disk; create a filesystem on it, use it
to store database files, etc. But using mirrors and RAID5 metadevices, Volume Manager
can also increase the availability of data. Mirrors and RAID5 volumes replicate data so
that it is not destroyed if the disk on which it is stored fails.
Volume Manager includes a graphical user interface (GUI) program named Solaris
Management Console that can be used to build volumes. However, as you become more
familiar Volume Manager, you will soon realize that Solaris Management Console cannot
perform all administration Volume Manager tasks. In these cases and for system
administrators that prefer to work from the command line, Volume Manager includes a
command line interface set of tools.
Within the Creating / Removing Volumes - (Using Volume Manager Commands) section, I
will include articles on Creating, Deleting, and Modifying all types of Volume Manager
objects.
These articles will provide a comprehensive overview for creating Volume Manager
volumes (stripes, concatenations, mirrors, etc) using the Volume Manager command-line
tools.
For the most up-to-date source of document for Sun Solaris, navigate to docs.sun.com.
Sun Admin Guide for Solaris Volume Manager - (Solaris 9):
docs.sun.com/db/doc/806-6111
Transitioning to Solaris' Volume - (Solaris 9):
http://wwws.sun.com/software/whitepapers/solaris9/transition_volumemgr.pdf
DiskSuite - (Solaris 8):
docs.sun.com/db/coll/260.1?q=disksuite&s=t
Installing Solaris Volume Manager - (Solaris 9)

Volume Manager is included and automatically installed with the Solaris 9 operating
environment using either the Entire+OEM, Entire, Developer, or End User install option.
NOTE: Users of Solaris 8 will recall that Solstice DiskSuite 4.2.1 had to be installed
manually after installing the Solaris operating environment!
Here is a listing of the packages related to Solaris 9 Volume Manager:
• SUNWmdr - Solaris Volume Manager driver

• SUNWmdu - Solaris Volume Manager commands
• SUNWmdx - Solaris Volume Manager drivers (64-bit)
• SUNWlvma - Solaris Volume Management APIs
• SUNWlvmg - Solaris Volume Management Application
• SUNWlvmr - Solaris Volume Management (root)
• SUNWvolg - Volume Management Graphical User Interface
Command Line Interface - Overview
Volume Manager Command Description

growfs(1M)
Expands a UFS file system in a non-destructive
fashion.
The mdlogd daemon and mdlogd.cf configuration file
mdlogd(1M) enable DiskSuite to send generic SNMP trap
messages.
metaclear(1M) Deletes active metadevices and hot spare pools.
metadb(1M) Creates and deletes state database replicas.
metadetach(1M)
Detaches a metadevice from a mirror, or a logging
device from a trans metadevice.
metahs(1M) Manages hot spares and hot spare pools.
metainit(1M) Configures metadevices.
metaoffline(1M) Places submirrors offline.
metaonline(1M) Places submirrors online.
metaparam(1M) Modifies metadevice parameters.
metarename(1M) Renames and switches metadevice names.
metareplace(1M)
Replaces slices of submirrors and RAID5
metadevices.
metaroot(1M) Sets up system files for mirroring root (/).
metaset(1M) Administers disksets.
metastat(1M) Displays status for metadevices or hot spare pools.
metasync(1M) Resyncs metadevices during reboot.
metatool(1M) Runs the DiskSuite Tool graphical user interface.
metattach(1M)
Attaches a metadevice to a mirror, or a logging
device to a trans metadevice.
Starting the Volume Manager Console GUI - (Solaris 9

Volume Manager)
by Jeffrey Hunter, Sr. Database Administrator
Solaris Volume Manager includes a graphic user interview (GUI) named Enhanced
Storage which is part of the Solaris Management Console.
To start the Volume Manager GUI:
1. First, start the Solaris Management Console (SMC) on the host system using the
following command:
# /usr/sbin/smc
NOTE: The first time the SMC is started on the host, it may take several minutes.
2. Expand the item This Computer

3. Expand the item Storage
4. Double-click the item Enhanced Storage. (You may be prompted for the root
password for the host.)
5. Double-click the appropriate icon to manage volumes, hot spare pools, state
database replicas, and disk sets.
Here is a screenshot of the Solaris Management Console and the Enhanced Storage Tool:
Creating Volumes - (Using Solaris 9 Volume Manager

Commands)
Contents
1. Overview
2. Examining the Disks In Our Example
3. Partitioning the Disks
4. State Database - (State Database Replicas)
o Creating the (Initial) First Four State Database Replicas
o Creating the Next Seven State Database Replicas
o Creating Two State Database Replicas On the Same Slice
o Query All State Database Replicas
o Deleting a State Database Replica
5. Creating a Stripe - (RAID 0)
6. Creating a Concatenation - (RAID 0)
7. Creating Mirrors - (RAID 1)
o Create a Mirror From Unused Slices
o Create a Mirror From a File System That Can Be Unmounted
o Create a Mirror From a File System That Cannot Be Unmounted
o Create a Mirror From swap
o Create a Mirror From root (/)
8. Creating a RAID 5 Volume - (RAID 5)
9. Creating Hot Spare
Overview
This article provides a comprehensive overview for creating Volume Manager
components (volumes, disk sets, state database replicas, hot spare pools) using the
Volume Manager command-line tools. Most of the information can also be found in the
"Solaris 9 Volume Manager Administration Guide" (Part No: 816-4519-10, April 2003).
Examining the Disks In Our Example
This article is all about providing definitions and examples of Volume Manager's
command line tools.
For all examples in this document, I will be utilizing a Sun Blade 150 connected to a Sun
StorEDGE D1000 Disk Array containing twelve 9.1GB / 10000 RPM / UltraSCSI disk
drives for a total disk array capacity of 108GB. The disk array is connected to the Sun
Blade 150 using a Dual Differential Ultra/Wide SCSI (X6541A) host adapter. In the Sun
StorEDGE D1000 Disk Array, the system identifies the drives as follows:
Controller 1 Controller 2
c1t0d0 - (d0) c2t0d0 - (d0)
c1t1d0 - (d0) c2t1d0 - (d1)
c1t2d0 - (d1) c2t2d0 - (d1)
c1t3d0 - (d20) c2t3d0 - (d20)
c1t4d0 - (d3) c2t4d0 - (d3)
c1t5d0 - (d3) c2t5d0 - (d4)
d0 : RAID 0 - Stripe
d1 : RAID 0 - Concatenation
d20 : RAID 1 - Mirror
d3 : RAID 5
d4 : Hot Spare
From the configuration above, you can see we have plenty of disk drives to utilize for our
examples! For the examples in this article, I will only be using several of the disks within
the D1000 array - in many cases, just enough to demonstrate the use of the Volume
Manager commands and component configuration.
Partitioning the Disks
Volumes in Volume Manager are built from slices (disk partitions). If the disks you plan
on using as volumes have not been partitioned, do so now. For the twelve 9.1GB disk
drives within the D1000 Disk Array, I use the same partition sizes and layout. By
convention, I will use slice 7 for the entire disk for storing the actual data. I will also use
slice 7 to store the state database replicas for each of the tweleve disks. Also by
convention, I will use slice 2 as the backup partition.
The following is the partition tables from one of the twelve hard drives:
format> verify
Primary label contents:
Volume name = < >

ascii name = <SUN9.0G cyl 4924 alt 2 hd 27 sec 133>
pcyl = 4926
ncyl = 4924
acyl = 2
nhead = 27
nsect = 133
Part Tag Flag Cylinders Size Blocks
0 unassigned wm 0 0 (0/0/0) 0
2 backup wm 0 - 4923 8.43GB (4924/0/0) 17682084
7 usr wm 0 - 4922 8.43GB (4923/0/0) 17678493
Use the format(1M) command to edit the partition table, label the disks, and set the
volume name.
State Database - (State Database Replicas)
The Solaris Volume Manager state database is used by Volume Manager to store
configuration and state information about volumes, hot spares, and disk sets. Before
creating volumes you will need to create state database replicas. The state database
replicas ensure that the data in the state database is always valid. When the state database
is updated, each state database replica is also updated.
At a bare minimum, Volume Manager requires a minimum of three state database

replicas. If your system looses a state database replica, Volume Manager will attempt to
determine which state database replcas are still valid. Before any of the state database
replicas can be considered valid, Volume Manager requires that a majority (half + 1) of
the state database replicas be available and in agreement before any of them are
considered valid. Solaris Volume Manager calls this algorithm a majority consensus
algorithm. The system will not reboot without one more than half the total state database
replicas. Instead, it will go into single-user mode for administrative tasks.
State database replicas are created on disk slices using the metadb command. Keep in
mind that state database replicas can only be created on slices that are not in use. (i.e.
have no file system or being used to store RAW data). You cannot create state database
replicas on slices on partitions that contain a file system, root (/), /usr, or swap. State
database replicas can be created on slices that will be part of a volume, but will need to
be created BEFORE adding the slice to a volume.
In the following example, I will create one state database replica on each of the first 11
disk drives in the D1000 Disk Array using the metadb command. On the twelfth disk, I
will give an example of how to create two state database replicas on the same slice. In
total I will be creating 13 state database replicas on 12 twelve disks. The replicas will be
created on slice 7 for each disk. (This is the slice that we created to be be used for each
disk in the disk array.) I will create the 13 state database replicas on the tweleve disks
using the following methods:
1. The first four initial state database replicas on the first four disks in the disk array
using the -a and -f command line options to the metadb command.
2. Then create seven more replicas just using the -a option to the metadb command.
3. Then use the -c option to the metadb command on the twelfth disk to give an
example of how to create two replicas on a single slice.
Creating the (Initial) First Four State Database Replicas
# metadb -a -f c1t0d0s7 c1t1d0s7 c1t2d0s7 c1t3d0s7
• The -a switch tells metadb to attach a new database device. The

/etc/lvm/mddb.cf file is automatically updated with the new information to tell
the system to reattach the devices at boot-time. An alternate way to create replicas
in DiskSuite 4.2.1 was by defining them in the /etc/lvm/md.tab file and
specifying the assigned name at the command line in the form, mddbnn, where nn
is a two-digit number given to the replica definitions. I do not believe this file is
used in Solaris 9 Volume Manager. Refer to the md.tab(4) man page for
instructions on setting up replicas in that file.
• The -f option is used to create the initial state database. It is also used to force the
deletion of replicas below the minimum of one. (The -a and -f options should be
used together only when no state databases exist.)
Creating the Next Seven State Database Replicas
# metadb -a c1t4d0s7 c1t5d0s7 c2t0d0s7 c2t1d0s7 c2t2d0s7 c2t3d0s7

c2t4d0s7

the system to reattach the devices at boot-time. An alternate way in DiskSuite
4.2.1 to create replicas was by defining them in the /etc/lvm/md.tab file and
Creating Two State Database Replicas On the Same Slice
# metadb -a -c2 c2t5d0s7

the system to reattach the devices at boot-time. An alternate way in DiskSuite
4.2.1 to create replicas was by defining them in the /etc/lvm/md.tab file and
• The -c switch is used to determine the number of database replicas that will be
created on each of the specified slices. In our case, we're creating two replicas on
one slice.
Query All State Database Replicas
# metadb
flags first blk block count

a m p luo 16 8192
/dev/dsk/c1t0d0s7
a p luo 16 8192
/dev/dsk/c1t1d0s7
a p luo 16 8192
/dev/dsk/c1t2d0s7
a p luo 16 8192
/dev/dsk/c1t3d0s7
a p luo 16 8192
/dev/dsk/c1t4d0s7
a p luo 16 8192
/dev/dsk/c1t5d0s7
a p luo 16 8192
/dev/dsk/c2t0d0s7
a p luo 16 8192
/dev/dsk/c2t1d0s7
a p luo 16 8192
/dev/dsk/c2t2d0s7
a p luo 16 8192
/dev/dsk/c2t3d0s7
a p luo 16 8192
/dev/dsk/c2t4d0s7
a p luo 16 8192
/dev/dsk/c2t5d0s7
a p luo 8208 8192
/dev/dsk/c2t5d0s7
Deleting a State Database Replica
# metadb -d c2t4d0s7
• The -d deletes all replicas that are located on the specified slice. The
/etc/system file is automatically updated with the new information and the
/etc/lvm/mddb.cf file is updated.
Ok, now lets put it back!
# metadb -a c2t4d0s7
Creating a Stripe - (RAID 0)
A RAID 0 volume (often called just a stripe) are one of the three types of simple volumes:
• Striped Volumes - (or stripes)

• Concatenated Volumes - (or concatenations)
• Concatenated Striped Volumes - (or contatenated stripes)
These components are made from slices. Simple volumes can be used directly or as the
basic building block for mirrors.
NOTE: Sometimes a striped volume is called a stripe. Other times, stripe refers to the
component blocks of a striped concatenation. To "stripe" means to spread I/O requests
across disks by chunking parts of the disks and mapping those chunks to a virtual device (a
volume). Both striping and concatenation are classified as RAID Level 0.
The data in a striped volume is arranged across two or more slices. The striping alternates
equally-sized segments of data across two or more slices to form one logical storage unit.
These segments are interleaved round-robin, so that the combined space is made
alternately from each slice. Sort of like a shuffled deck of cards.
1. The following example creates a striped volume using 3 slices named

/dev/md/rdsk/d0 using the metainit command. Of the twelve disks available in
the D1000 Disk Array, I will be using slices c1t0d0s7, c2t0d0s7, c1t1d0s7 as
follows:
2. # metainit d0 1 3 c1t0d0s7 c2t0d0s7 c1t1d0s7 -i 32k
d0: Concat/Stripe is setup
3. Use the metastat command to query your new volume:

4. # metastat d0
5. d0: Concat/Stripe
6. Size: 52999569 blocks (25 GB)
7. Stripe 0: (interlace: 64 blocks)
8. Device Start Block Dbase Reloc
9. c1t0d0s7 10773 Yes Yes
10. c2t0d0s7 10773 Yes Yes
11. c1t1d0s7 10773 Yes Yes
12.
13.Device Relocation Information:
14.Device Reloc Device ID
15.c1t0d0 Yes
id1,sd@SSEAGATE_ST39102LCSUN9.0GLJR76697000019460DB4
16.c2t0d0 Yes
id1,sd@SSEAGATE_ST39102LCSUN9.0GLV00222700001005J6Q7
c1t1d0 Yes
id1,sd@SSEAGATE_ST39102LCSUN9.0GLJR58209000019461YK2
Let's explain the details of the above example. First notice that the new striped
volume, d0, consists of a single stripe (Stripe 0) made of three slices (c1t0d0s7,
c2t0d0s7, c1t1d0s7). The -i option sets the interlace to 32KB. (The interlace
cannot be less than 8KB, nor greater than 100MB.) If interlace were not specified
on the command line, the striped volume would use the default of 16KB. When
using the metastat command to verify our volume, we can see from all disks
belonging to Stripe 0, that this is a stripped volume. Also, that the interlace is 32k
(512 * 64 blocks) as we defined it. The total size of the stripe is 27,135,779,328
bytes (512 * 52999569 blocks).
17. Now that we have created our simple volume (a RAID 0 stripe), we can now
pretend that the volume is a big partition (slice) on which we can do the usual file
system things. Let's now create a UFS file system using the newfs command. I
want to create a UFS file system with an 8KB block size:
18.# newfs -i 8192 /dev/md/rdsk/d0
19.newfs: /dev/md/rdsk/d0 last mounted as /db0
20.newfs: construct a new file system /dev/md/rdsk/d0: (y/n)? y
21.Warning: 1 sector(s) in last cylinder unallocated
22./dev/md/rdsk/d0: 52999568 sectors in 14759 cylinders of 27
tracks, 133 sectors
23. 25878.7MB in 923 cyl groups (16 c/g, 28.05MB/g, 3392 i/g)
24.super-block backups (for fsck -F ufs -o b=#) at:
25. 32, 57632, 115232, 172832, 230432, 288032, 345632, 403232,
460832, 518432,
26.Initializing cylinder groups:
27...................
28.super-block backups for last 10 cylinder groups at:
29. 52459808, 52517408, 52575008, 52632608, 52690208, 52747808,
52805408,
52863008, 52920608, 52978208,
30. Finally, we mount the file system on /db0 as follows:

31.# mkdir /db0
# mount -F ufs /dev/md/dsk/d0 /db0
32. To ensure that this new file system is mounted each time the machine is started,
insert the following line into you /etc/vfstab file (all on one line with tabs
separating the fields):
/dev/md/dsk/d0 /dev/md/rdsk/d0 /db0 ufs 2

yes -
Creating a Concatenation - (RAID 0)
The method used for creating a Concatenated Volume is very similar to that used in
creating a Striped Volume - both use the metainit command (obviously using different
options) and the same method for creating and mounting a UFS file system for.
A Solaris 9 Volume Manager Concatenated Volume (often called just a Concatenation) is

one of three types of simple volumes.
• Striped Volumes - (or stripes)
• Concatenated Volumes - (or concatenations)
• Concatenated Striped Volumes - (or contatenated stripes)
These components are made from slices. Simple volumes can be used directly or as the
basic building block for mirrors.
The data for a concatenated volume is organized serially and adjacently across disk
slices, forming one logical storage unit. Many system administrators use a concatenated
volume to get more storage capacity by logically combining the capacities of several
slices. It is possible to add more slices to the concatenated volume as the demand for
storage grows. A concatenated volume enables you to dynamically expand storage
capacity and file system sizes online! With a concatenated volume you can add slices
even if the other slices are currently active.
NOTE: You can also create a concatenated volume from a single slice. You could, for
example, create a single-slice concatenated volume. Later, when you need more storage,
you can add more slices to the concatenated volume.
1. The following example creates a concatenated volume using 3 slices named

/dev/md/rdsk/d1 using the metainit command. Of the twelve disks available in
the D1000 Disk Array, I will be using slices c2t1d0s7, c1t2d0s7, c2t2d0s7 as
follows:
2. # metainit d1 3 1 c2t1d0s7 1 c1t2d0s7 1 c2t2d0s7
3. Use the metastat command to query your new (or in our example all) volumes:
4. # metastat
5. d1: Concat/Stripe
6. Size: 53003160 blocks (25 GB)
7. Stripe 0:
9. c2t1d0s7 10773 Yes Yes
10. Stripe 1:
12. c1t2d0s7 10773 Yes Yes
13. Stripe 2:
15. c2t2d0s7 10773 Yes Yes
16.
17.d0: Concat/Stripe
18. Size: 52999569 blocks (25 GB)
19. Stripe 0: (interlace: 64 blocks)
21. c1t0d0s7 10773 Yes Yes
22. c2t0d0s7 10773 Yes Yes
23. c1t1d0s7 10773 Yes Yes
24.
27.c2t1d0 Yes
id1,sd@SSEAGATE_ST39102LCSUN9.0GLJP46564000019451VGF
28.c1t2d0 Yes
id1,sd@SSEAGATE_ST39102LCSUN9.0GLJU8183300002007J3Z2
29.c2t2d0 Yes
id1,sd@SSEAGATE_ST39102LCSUN9.0GLJM7285500001943H5XD
30.c1t0d0 Yes
id1,sd@SSEAGATE_ST39102LCSUN9.0GLJR76697000019460DB4
31.c2t0d0 Yes
id1,sd@SSEAGATE_ST39102LCSUN9.0GLV00222700001005J6Q7
c1t1d0 Yes
id1,sd@SSEAGATE_ST39102LCSUN9.0GLJR58209000019461YK2
Let's explain the details of the above example. First notice that the new
concatenated volume, d1, consists of three stripes (Stripe 0, Stripe 1, Stripe 2,)
each made from a single slice (c2t1d0s7, c1t2d0s7, c2t2d0s7 respectively). When
using the metastat command to verify our volumes, we can see this is a
concatenation from the fact of having multiple Stripes. The total size of the
concatenation is 27,137,617,920 bytes (512 * 53003160 blocks).
32. Now that we have created our simple volume (a concatenation), we can now
pretend that the volume is a big partition (concatenation) on which we can do the
usual file system things. Let's now create a UFS file system using the newfs
command. I want to create a UFS file system with an 8KB block size:
tracks, 133 sectors
38. 32, 57632, 115232, 172832, 230432, 288032, 345632, 403232,
460832, 518432,
40...................
42. 52459808, 52517408, 52575008, 52632608, 52690208, 52747808,
52805408,
52863008, 52920608, 52978208,

44.# mkdir /db1

yes -
Creating Mirrors - (RAID 1)

A mirror is a volume just like any other volume (stripe, concatenation) and is made of
one or more submirrors. A submirror is made of one or more striped or concatenated
volumes. Mirroring data provides you with maximum data availability by maintaining
multiple copies of your data (also called RAID 1). RAID 0 does, however, require an
investment in disks. To setup RAID 0, you will need at least twice as much disk space as
the amount of data you will have to mirror. Keep in mind also, that since Solaris Volume
Manager must write to all submirrors, the process of mirroring can also increase the
amount of time it takes for write requests to be written to disk.
Before creating a mirror, create the striped or concatenated volumes that will make up the
mirror.
Any file system including root (/), swap, and /usr, or any application such as a database,
can use a mirror. Basically, you can mirror any file system, including existing file
systems. You can also mirror large applications, such as the data files for a database.
When creating a mirror, first create a one-way mirror, then attach a second submirror.
This starts a resync operation and ensures that data is not corrupted.
To mirror an existing file system, use an additional slice of equal or greater size than the
slice already used by the mirror. You can use a concatenated volume or striped volume of
two or more slices that have adequate space to contain the mirror.
You can create a one-way mirror for a future two- or three-way mirror.
You can create up to a three-way mirror. However, two-way mirrors usually provide
sufficient data redundancy for most applications, and are less expensive in terms of disk
drive costs. A three-way mirror enables you to take a submirror offline and perform a
backup while maintaining a two-way mirror for continued data redundancy. While any
submirror is offline, all reading and writing to the submirror is stopped. This enables
system administrators to take backups of other system administration responsibilities.
Remember, the submirror is in a read-only state. While the submirror is offline, Solaris
Volume Manager is keeping track of all writes to the mirror. When the submirror is
brought back online, only portions of the mirror that were written while the submirror
was offline are resynchronized.
Use the same size slices when creating submirrors. Using different size slices creates
unused space in the mirror.
Avoid having slices of submirrors on the same disk. Also, when possible, use disks
attached to different controllers to avoid single points-of-failure. For maximum
protection and performance, place each submirror on a different physical disk and, when
possible, on different disk controllers. For further data availability, use hot spares with
mirrors.
In some cases, mirroring can improve read performance. Write performance, however,
will always degrade. If an application is multi-threaded or can take advantage of
asynchronous I/O, you will see performance gains. If an application is only single-
threaded reading from the volume, you will see no performance gains.
Adding additional state database replicas before creating a mirror can increase the
mirror's performance. As a general rule, add one additional replica for each mirror you
add to the system.
If possible create mirrors from disks consisting of the same disk geometries. The
historical reason is that UFS uses disk blocks based on disk geometries. Today, the issue
is centered around performance: a mirror composed of disks with different geometries
will only be as fast as its slowest disk.
This section will contain the following five examples for creating different types of two-
way mirrors:
1. Create a Mirror From Unused Slices

2. Create a Mirror From a File System That Can Be Unmounted
3. Create a Mirror From a File System That Cannot Be Unmounted
4. Create a Mirror From swap
5. Create a Mirror From root (/)
To perform the above mirror examples, I will be using the two disks: c1t3d0 and c2t3d0.
After creating each two-way mirror example, I will be deleting the newly created mirror
to get ready for the next example.
Create a Mirror From Unused Slices
1. Use the metainit command to create two volumes - each new concatenation
volume (d21 and d22) consists of a single slice (c1t3d0s7 and c2t3d0s7)
respectively:
2. # metainit d21 1 1 c1t3d0s7
3. d21: Concat/Stripe is setup
4.
6. Using the metainit -m command to create a one-way mirror (named d20) from one
of the submirrors.
7. # metainit d20 -m d21
d20: Mirror is setup
8. Finally, use the metattach command to create the two-way mirror (named d20)
from the second submirror (d22).
9. # metattach d20 d22
d20: submirror d22 is attached
We now have a two-way mirror, d20. The metainit command was first used to
create the two submirrors (d21 and d22), which are actually concatenations. The
metainit -m command was then used to create a one-way mirror from the d21
concatenation. We then used the metattach command to attach d22, creating a
two-way mirror and causing a mirror resync. (Any data on the attached
submirror is overwritten by the other submirror during the resync.) The system
verifies that the objects are set up.
10. Use the metastat command to query your new volume:

11.# metastat d20
12.d20: Mirror
13. Submirror 0: d21
14. State: Okay
16. State: Resyncing
17. Resync in progress: 26 % done
18. Pass: 1
19. Read option: roundrobin (default)
20. Write option: parallel (default)
21. Size: 17667720 blocks (8.4 GB)
22.
23.d21: Submirror of d20
24. State: Okay
25. Size: 17667720 blocks (8.4 GB)
26. Stripe 0:
27. Device Start Block Dbase State Reloc Hot Spare
28. c1t3d0s7 10773 Yes Okay Yes
29.
30.
33. Size: 17667720 blocks (8.4 GB)
34. Stripe 0:
35. Device Start Block Dbase State Reloc Hot Spare
36. c2t3d0s7 10773 Yes Okay Yes
37.
38.
41.c1t3d0 Yes
id1,sd@SSEAGATE_ST39102LCSUN9.0GLJV45682000029500HYF
c2t3d0 Yes
id1,sd@SSEAGATE_ST39102LCSUN9.0GLJE46028000019291ARS
Let's explain the details of the above example. First notice that the new mirror
volume, d20, consists of two submirrors, (d21 and d22) each made from a single
slice (c1t3d0s7, c2t3d0s7 respectively). When using the metastat command to
verify our volumes, we can see this is a mirror. The total size of the mirror is
9,045,872,640 bytes (512 * 17667720 blocks).
42. Now that we have created our simple volume (a mirror), and the mirror resync is
complete, we can now pretend that the volume is just a regular partition (slice) on
which we can do the usual file system things. Let's now create a UFS file system
using the newfs command. I want to create a UFS file system with an 8KB block
size:
tracks, 133 sectors
48. 32, 57632, 115232, 172832, 230432, 288032, 345632, 403232,
460832, 518432,
49. 17123360, 17180960, 17238560, 17296160, 17353760, 17411360,
17468960,
17526560, 17584160, 17641760,

51.# mkdir /db20

yes -
53. The volume, /db20 is now ready for use!
Create a Mirror From a File System That Can Be Unmounted
1. The procedures document in this section can be used to mirror a file system that
can be unmounted during normal operation. While most file systems can be
unmounted during normal operation, there are some which cannot be unmounted
like root /, /usr, /opt or swap. Procedures for mirroring those file systems which
cannot be unmounted during normal operation are documented in the next section.
2. First, identify the slice that contains the file system to me mirrored. For this
example, I will be using /dev/dsk/c1t3d0s7 that contains an existing file system
that I want to have mirrored. This is a file system that can be unmounted.
The slice /dev/dsk/c1t3d0s7 contains an 8K UFS file system and is mounted on

/db20.
3. Use the metainit -f to put the mounted file system's slice in a single slice (one-
way) concat/stripe. (This will be submirror1) The following command creates one
stripe that contains one slice. The new volume will be named d21:
4. # metainit -f d21 1 1 c1t3d0s7
5. Create a second concat/stripe. (This will be submirror2)
7. Use the metainit -m command to create a one-way mirror with submirror1.

9. Unmount the file system
# umount /db20
10. Edit the /etc/vfstab file so that the existing file system entry now refers to the
newly created mirror. In the following example snippet, I commented out the
original entry for the c1t3d0s7 slice and added a new entry that refers to the
newly created mirrored volume (d20) to be mounted to /db20:
11.# /dev/dsk/c1t3d0s7 /dev/rdsk/c1t3d0s7 /db20 ufs 2
yes -
yes -
12. Remount the file system:
# mount /db20
13. Use the metattach command to attach submirror2

14.# metattach d20 d22
15. After attaching d22 (submirror2), this triggers a mirror resync. Use the metastat
command to view the progress of the mirror resync:
16.# metastat d20
17.d20: Mirror
19. State: Okay
23. Pass: 1
26. Size: 17470215 blocks
27.
29. State: Okay
31. Stripe 0:
32. Device Start Block Dbase State Hot
Spare
33. c1t3d0s7 3591 Yes Okay
34.
35.
39. Stripe 0:
Spare
c2t3d0s7 3591 Yes Okay
41. From the above example, we didn't create a multi-way mirror right away. Rather,
we created a one-way mirror with the metainit command then attach the
additional submirrors with the metattach command. When the metattach
command is not used, no resync operations occur and data could become
corrupted. Also, do not create a two-mirror for a file system without first
unmounting the file system , editing the /etc/vfstab file to reference the
mirrored volume, and then mount the file system to the new mirrored volume
before attaching the second submirror.
Create a Mirror From a File System That Cannot Be Unmounted
1. The procedures in this section can be used to mirror file systems, such as /usr
and /opt - those that cannot be unmounted during normal system usage.
2. First, identify the slice that contains the file system to me mirrored. For this
example, I will be using the /usr file system which is located on c0t0d0s6 that I
want to have mirrored. This is a file system that cannot be unmounted.
The slice /dev/dsk/c0t0d0s6 contains an 8K UFS file system and is mounted on

/usr. This will be made into submirror1 (d21) using the metainit command. For
submirror2 (to make our two-way mirror) I will be using /dev/dsk/c2t3d0s7.
3. Use the metainit -f to put the mounted file system's slice in a single slice (one-


9. Edit the /etc/vfstab file so that the file system (/usr) now refers to the newly
created mirror. In the example snippet, I commented out the original entry for the
c0t0d0s6 slice and added a new entry that refers to the newly created mirror to be
mounted to /usr:
10.# /dev/dsk/c0t0d0s6 /dev/rdsk/c0t0d0s6 /usr ufs 1
no -
/dev/md/dsk/d20 /dev/md/rdsk/d20 /usr ufs 1
no -
11. Reboot the system
# reboot

15.# metastat d20
16.d20: Mirror
18. State: Okay
22. Pass: 1
26.
28. State: Okay
30. Stripe 0:
Spare
32. c0t0d0s6 0 No Okay
33.
34.
38. Stripe 0:
Spare
40. From the above example, we didn't create a multi-way mirror right away for the
/usr file system. Rather, we created a one-way mirror with the metainit command
then attach the additional submirrors with the metattach command (after
rebooting the server). When the metattach command is not used, no resync
operations occur and data could become corrupted. Also, do not create a two-
mirror for a file system without first editing the /etc/vfstab file to reference the
mirror volume and then rebooting the server before attaching the second
submirror.
Create a Mirror From swap
1. The procedures in this section of the documentation can be used to mirror the
swap file system. The swap file system, like /usr and /opt, cannot be unmounted
during normal system usage.
2. First, identify the slice that contains the swap file system to me mirrored. For this
example, the swap file system it is located on c0t0d0s3 that I want to have
mirrored. This is a file system that cannot be unmounted.
The slice /dev/dsk/c0t0d0s3 contains the swap file system. This will be made
into submirror1 (d21) using the metainit command. For submirror2 (to make our
two-way mirror) I will be using /dev/dsk/c2t3d0s7.
3. Use the metainit -f to put the mounted file system (swap) in a single slice (one-


9. Edit the /etc/vfstab file so that the swap file system now refers to the newly
created mirror. In the example snippet, I commented out the original swap entry
for the c0t0d0s3 slice and added a new entry that refers to the newly created
mirror:
10.# /dev/dsk/c0t0d0s3 - - swap - no -
/dev/md/dsk/d20 - - swap - no -
# reboot

15.# metastat d20
16.d20: Mirror
18. State: Okay
22. Pass: 1
26.
28. State: Okay
30. Stripe 0:
Spare
33.
34.
38. Stripe 0:
Spare
40. Verify that the swap file system is mounted on the d20 volume:
41.# swap -l
42.swapfile dev swaplo blocks free
/dev/md/dsk/d20 85,20 16 2101184 2101184
43. From the above example, we didn't create a multi-way mirror right away for the
swap file system. Rather, we created a one-way mirror with the metainit
command then attach the additional submirrors with the metattach command
(after rebooting the server). When the metattach command is not used, no resync
operations occur and data could become corrupted. Also, do not create a two-
mirror for a file system without first editing the /etc/vfstab file to reference the
mirror volume and then rebooting the server before attaching the second
submirror.
Create a Mirror From root (/)
1. Use the following procedures to mirror the root (/) file system on a SPARC
system.
NOTE: The task for using the command-line to mirror root (/) on an x86 system is
different from the task used for a SPARC system.
When mirroring root (/), it is essential that you record the secondary root slice name to
reboot the system if the primary submirror fails. This information should be written down,
not recorded on the system, which may not be available in the event of a disk failure.
2. Use the metainit -f to put the root (/) slice in a single slice (one-way) concat.
(submirror1). (This will be submirror1)
The following command creates one stripe that contains one slice. The new
volume will be named d21:
# metainit -f d21 1 1 c0t0d0s0



7. Run the metaroot command. This will update both the /etc/vfstab and
/etc/system files to reflect the new rootslice the system will boot from:
# metaroot d20
8. Run the lockfs command:
# lockfs -fa
# reboot

12. Record/document the alternate boot path in the case of failure.

13.# ls -l /dev/rdsk/c0t2d0s0
lrwxrwxrwx 1 root root 42 Nov 12 09:35 /dev/rdsk/c0t2d0s0 ->
../../devices/pci@1f,0/ide@d/dad@2,0:a,raw
NOTE: The -f option forces the creation of the first concatenation, d21, which contains
the mounted file system root (/) on /dev/dsk/c0t0d0s0. The second concatenation, d22,
is created from /dev/dsk/c0t2d0s0. (This slice must be the same size or greater than that
of d21) The metainit command with the -m option creates the one-way mirror d20 using
the concatenation containing root (/). Next, the metaroot command edits the /etc/vfstab
and /etc/system files so that the system may be booted with the root file system (/) on a
volume. (It is a good idea to run lockfs -fa before rebooting.) After a reboot, the
submirror d22 is attached to the mirror, causing a mirror resync. (The system verifies that
the concatenations and the mirror are set up, and that submirror d22 is attached.) The ls -l
command is run on the root raw device to determine the path to the alternate root device in
case the system needs to be booted from it.
Creating a RAID5 Volume - (RAID 5)
A RAID5 volume uses storage capacity equivalent to one slice in the volume to store
redundant information about user data stored on the remainder of the RAID5 volume's
slices. The redundant information is distributed across all slices in the volume. Like a
mirror, a RAID5 volume increases data availability, but with a minimum of cost in terms
of hardware.
The system must contain at least three state database replicas before you can create
RAID5 volumes.
A RAID5 volume can only handle a single slice failure.
Follow the 20-percent rule when creating a RAID5 volume: because of the complexity of
parity calculations, volumes with greater than about 20 percent writes should probably
not be RAID5 volumes. If data redundancy is needed, consider mirroring.
There are drawbacks to a slice-heavy RAID5 volume: the more slices a RAID5 volume
contains, the longer read and write operations will take if a slice fails.
A RAID5 volume must consist of at least three slices.
A RAID5 volume can be grown by concatenating additional slices to the volume. The
new slices do not store parity information, however they are parity protected. The
resulting RAID5 volume continues to handle a single slice failure.
The interlace value is key to RAID5 performance. It is configurable at the time the
volume is created; thereafter, the value cannot be modified. The default interlace value is
16 Kbytes. This is reasonable for most applications.
Use the same size disk slices. Creating a RAID5 volume from different size slices results
in unused disk space in the volume.
Do not create a RAID5 volume from a slice that contains an existing file system. Doing
so will erase the data during the RAID5 initialization process.
RAID5 volumes cannot be striped, concatenated, or mirrored.
1. The following example creates a RAID 5 volume using 3 slices that will be
named /dev/md/rdsk/d3 with the metainit command. Of the twelve disks
available in the D1000 Disk Array, I will be using slices c1t4d0s7, c2t4d0s7,
and c1t5d0s7 as follows:
2. # metainit d3 -r c1t4d0s7 c2t4d0s7 c1t5d0s7
d3: RAID is setup
Let's explain the details of the above example. The RAID5 volume d3 is created
with the -r option from three slices. Because no interlace is specified, d3 uses the
default of 16 Kbytes. The system verifies that the RAID5 volume has been set up,
and begins initializing the volume.
3. Use the metastat command to query your new RAID5 volumes. After running the
above command, the volume will go through an initialization state. This may take
several minutes to complete. When using the metastat command, you will be able
to view how far of the initialization is completed. You must wait for the
initialization to finish before you can use the new RAID5 volume. The following
screenshot shows the RAID5 volume during its initialization phase:
4. # metastat d3
5. d3: RAID
6. State: Initializing
7. Initialization in progress: 32.0% done
8. Interlace: 32 blocks
9. Size: 35331849 blocks (16 GB)
10.Original device:
11. Size: 35334720 blocks (16 GB)
12. Device Start Block Dbase State Reloc Hot
Spare
13. c1t4d0s7 11103 Yes Initializing Yes
16.
19.c1t4d0 Yes
id1,sd@SSEAGATE_ST39102LCSUN9.0GLJP248260000194511NU
20.c2t4d0 Yes
id1,sd@SSEAGATE_ST39102LCSUN9.0GLJP1841500002945H5FE
c1t5d0 Yes
id1,sd@SSEAGATE_ST39102LCSUN9.0GLJE34597000029290C8N
When the disks within the RAID5 volume are completed with their initialization
phase, this is what it will look like:
# metastat d3
d3: RAID
State: Okay
Interlace: 32 blocks
Size: 35331849 blocks (16 GB)
Original device:
Size: 35334720 blocks (16 GB)
Device Start Block Dbase State Reloc Hot
Spare
c1t4d0s7 11103 Yes Okay Yes
Device Relocation Information:
Device Reloc Device ID
c1t4d0 Yes
id1,sd@SSEAGATE_ST39102LCSUN9.0GLJP248260000194511NU
c2t4d0 Yes
id1,sd@SSEAGATE_ST39102LCSUN9.0GLJP1841500002945H5FE
c1t5d0 Yes
id1,sd@SSEAGATE_ST39102LCSUN9.0GLJE34597000029290C8N
21. Now that we have created our RAID5 volume, we can now pretend that the
volume is a big partition (slice) on which we can do the usual file system things.
Let's now create a UFS file system using the newfs command. I want to create a
UFS file system with an 8KB block size:
24.Warning: 1 sector(s) in last cylinder unallocated
tracks, 133 sectors
28. 32, 57632, 115232, 172832, 230432, 288032, 345632, 403232,
460832, 518432,
30.............
32. 34765088, 34822688, 34880288, 34933280, 34990880, 35048480,
35106080,
35163680, 35221280, 35278880,

34.# mkdir /db3

yes -
Creating a Hot Spare
Removing Volumes - (Using Solaris 9 Volume Manager

Commands)
Contents
1. Overview
2. Examining the Disks In Our Example
3. Removing a State Database Replica
4. Removing a Stripe - (RAID 0)
5. Removing a Concatenation - (RAID 0)
6. Removing Mirrors - (RAID 1)
o Unmirror a File System that Can be Unmounted
o Unmirror a File System that Cannot be Unmounted
o Unmirror swap
o Unmirror root (/)
7. Removing a RAID5 Volume - (RAID 5)
8. Removing a Hot Spare
Overview
This article provides a comprehensive overview for removing Volume Manager

components (volumes, disk sets, state database replicas, hot spare pools) using the Solaris
9 Volume Manager command-line tools. Most of the information can also be found in the
"Solaris 9 Volume Manager Administration Guide" (Part No: 816-4519-10, April 2003).
Examining the Disks In Our Example
This article is all about providing definitions and examples of Volume Manager's
command line tools.
If you followed the examples in the article, "Creating Volumes - (Using Solaris 9 Volume
Manager Commands)", most of the disk configuration described below should already
exist.
For all examples in this document, I will be utilizing a Sun Blade 150 connected to a Sun
StorEdge D1000 Disk Array containing twelve 9GB / 10000 RPM / UltraSCSI disk
drives for a total disk array capacity of 108GB. The disk array is connected to the Sun
Blade 150 using a Dual Differential Ultra/Wide SCSI (X6541A) Host Adapter. In the Sun
StorEdge D1000 Disk Array, the system identifies the drives as follows:
Controller 1 Controller 2
c1t0d0 - (d0) c2t0d0 - (d0)
c1t1d0 - (d0) c2t1d0 - (d1)
c1t2d0 - (d1) c2t2d0 - (d1)
c1t3d0 - (d20) c2t3d0 - (d20)
c1t4d0 - (d3) c2t4d0 - (d3)
c1t5d0 - (d3) c2t5d0 - (d4)
d0 : RAID 0 - Stripe
d1 : RAID 0 - Concatenation
d20 : RAID 1 - Mirror
d3 : RAID 5
d4 : Hot Spare
Removing a State Database Replica
# metadb -d c2t4d0s7
The -d deletes all replicas that are located on the specified slice. The /etc/lvm/mddb.cf
file is automatically updated with the new information.
To remove ALL of the database replica with one command, you will need to use the -f
option. The following example will remove all database state replicas from all twelve
drives:
# metadb -f -d /dev/dsk/c1t0d0s7 /dev/dsk/c1t1d0s7 /dev/dsk/c1t2d0s7 \

/dev/dsk/c1t3d0s7 /dev/dsk/c1t4d0s7 /dev/dsk/c1t5d0s7 \
/dev/dsk/c2t0d0s7 /dev/dsk/c2t1d0s7 /dev/dsk/c2t2d0s7 \
/dev/dsk/c2t3d0s7 /dev/dsk/c2t4d0s7 /dev/dsk/c2t5d0s7
Removing a Stripe - (RAID 0)
The process for removing a RAID 0 Striped Volume is fairly easy and straightforward.
The same method can be used for a concatenated and RAID 5 volumes as well.
The following example unmounts the file system from the mount point, /db0, and then
uses the metaclear command to permanently remove the volume from the system. Keep
in mind that this example will remove the volume d0 from the system and all data stored
on it!
1. First unmount the file system:
# umount /db0
2. Next, remove the entry you made to the /etc/vfstab file for automatically
mounting the /dev/md/dsk/d0 volume:

yes -
3. Now remove the directory (/db0) that was used to mount the file system:
# rmdir /db0
4. Finally, to remove the striped volume, use the metaclear command as follows:
5. # metaclear d0
d0: Concat/Stripe is cleared
6. You can now use the metastat command to verify that the striped volume was
removed:
7. # metastat d0
metastat: alex: d0: unit not set up
Removing a Concatenation - (RAID 0)
The process for removing a Concatenated Volume is fairly easy and straightforward. The
same method can be used for a RAID 0 striped or RAID 5 volume as well.
The following example unmounts the file system from the mount point, /db1, and then
uses the metaclear command to permanently remove the volume from the system. Keep
in mind that this example will remove the volume d1 from the system and all data stored
on it!
# umount /db1

yes -
# rmdir /db1
4. Finally, to remove the concatenated volume, use the metaclear command as

follows:
5. # metaclear d1
6. You can now use the metastat command to verify that the concatenated volume
was removed. Notice that the d1 volume no longer exists:
7. # metastat d1
Removing a Mirror - (RAID 1)
This section will contain the following four examples for unmirroring / removing mirrors:
1. Unmirror a File System that Can be Unmounted

2. Unmirror a File System that Cannot be Unmounted
3. Unmirror swap
4. Unmirror root (/)
Unmirror a File System that Can be Unmounted
The process for unmirroring a regular file system (one that can be unmounted) is fairly
easy and straightforward.
In this example, I have a two-way mirrored volume named d20. It consists of two
submirrors d21 and d22. This two-way mirror was created from an already existing UFS
file system mounted on /dev/dsk/c1t3d0s7. For the purpose of this example, I want to
unmirror the file system while preserving the data, remove all volumes that were
involved in the mirrored volume, and return the file system back to normal to where it
existed; mounted on /dev/dsk/c1t3d0s7.
The following example unmounts the file system (/db20) from the mirrored volume, d20.
We then need to detach both submirrors (d21 and d22) from the mirror using the
metadetach command. Finally, we use the metaclear command to permanently remove
all volume components from the system. Keep in mind that this example will remove the
mirrored volume d20 (plus the submirrors d21 and d22) but will preserve the data that
exists on /dev/dsk/c1t3d0s7 - it just will not be mirrored!
# umount /db20
2. Next, remove the entry (or comment it out) you made to the /etc/vfstab file for
automatically mounting the /dev/md/dsk/d20 volume. Then put the entry that
mounted the /dev/dsk/c1t3d0s7 slice / file system back in the /etc/vfstab file
that mounted it to /db20:
3. /dev/dsk/c1t3d0s7 /dev/rdsk/c1t3d0s7 /db20 ufs 2
yes -
# /dev/md/dsk/d20 /dev/md/rdsk/d20 /db20 ufs 2
yes -
4. Now lets check the mirror (d20) to determine how many submirrors it contains
and what their names are:
5. # metastat d20
6. d20: Mirror
7. Submirror 0: d21
8. State: Okay
9. Submirror 1: d22
10. State: Okay
11. Pass: 1
15.
17. State: Okay
19. Stripe 0:
Spare
21. c1t3d0s7 3591 Yes Okay
22.
23.
25. State: Okay
27. Stripe 0:
Spare
29. To remove the mirror volume and submirrors, use the metadetach and metaclear
commands as follows:
30.# metadetach d20 d22
31.d20: submirror d22 is detached
32.
34.metadetach: alex: d20: attempt to detach last running submirror
35.
36.# metaclear d22
37.d22: Concat/Stripe is cleared
38.
39.# metaclear d20
40.d20: Mirror is cleared
41.
42.# metaclear d21
43. You can now use the metastat command to verify that the mirrored and
contactenated volumes were removed:
44.# metastat d20 d21 d22
45.metastat: alex: d20: unit not set up
46.
48.
49. You should now be able to mount the file system on /dev/dsk/c1t3d0s7 back to
/db20. Keep in mind, that all data has been preserved, but will no longer be
mirrored.
# mount /db20
Unmirror a File System that Cannot be Unmounted
The process for unmirroring a file system (one that cannot be unmounted) is fairly easy
and straightforward. Keep in mind that this process can be used for the /usr, /opt, var,
and swap file systems.
In this example, I will unmirror the /usr file system. The twist here is that the /usr file
system (just like /opt and swap) cannot be unmounted during normal system usage. The
/usr file system is currently mounted on a two-way mirrored volume named d20 that
consists of two submirrors d21 and d22. Before I created this two-way mirror for the
/usr file system, the file system was mounted on the slice /dev/dsk/c0t0d0s6. For the
purpose of this example, I want to unmirror the file system while preserving the data for
the /usr file system, remove all volumes that were involved in the mirrored volume, and
return the file system back to normal to where it existed; mounted on
/dev/dsk/c0t0d0s6. The second part of the mirror (submirror2) is /dev/dsk/c2t3d0s7
and will be made available for other uses after it is no longer part of the mirror.
1. First, run the metastat command to verify that at least one submirror is in the
"Okay" state.
2. # metastat d20
3. d20: Mirror
4. Submirror 0: d21
5. State: Okay
6. Submirror 1: d22
7. State: Okay
8. Pass: 1
12.
14. State: Okay
16. Stripe 0:
Spare
19.
20.
22. State: Okay
24. Stripe 0:
Spare
26. Next, run the metadetach command on the mirror that contains the /usr file
system. In this case, I will detach d22 to make a one-way mirror:
d20: submirror d22 is detached
mounted the /dev/dsk/c0t0d0s6 slice back in the /etc/vfstab file that
mounted it to /usr. Keep in mind that this step can be used for /usr, /opt, var,
and swap file systems. For the root / file system, you would use the metaroot
command.
29./dev/dsk/c0t0d0s6 /dev/rdsk/c0t0d0s6 /usr ufs 1
no -
# /dev/md/dsk/d20 /dev/md/rdsk/d20 /usr ufs 1
no -
# reboot
31. To remove the mirror volume and submirrors, use the metaclear command as
follows:
32.# metaclear -r d20
35.
36.# metaclear d22
contactenated volume were removed:
40.
42.
Unmirror swap
The process for unmirroring the swap file system (one that cannot be unmounted) is fairly
easy and straightforward. Keep in mind that this process can be used for the /usr, /opt,
var, and swap file systems.
In this example, I will unmirror the swap file system. The twist here is that the swap file
system (just like /opt and /var) cannot be unmounted during normal system usage. The
swap file system is currently mounted on a two-way mirrored volume named d20 that
consists of two submirrors d21 and d22. Before I created this two-way mirror for the
swap file system, the file system was mounted on the slice /dev/dsk/c0t0d0s3. For the
purpose of this example, I want to unmirror the swap file system, remove all volumes that
were involved in the mirrored volume, and return the file system back to normal to where
it existed; mounted on /dev/dsk/c0t0d0s3. The second part of the mirror (submirror2)
is /dev/dsk/c2t3d0s7 and will be made available for other uses after it is no longer part
of the mirror.
"Okay" state.
2. # metastat d20
3. d20: Mirror
4. Submirror 0: d21
5. State: Okay
6. Submirror 1: d22
7. State: Okay
8. Pass: 1
12.
14. State: Okay
16. Stripe 0:
Spare
19.
20.
22. State: Okay
24. Stripe 0:
Spare
26. Next, run the metadetach command on the mirror that contains the swap file
mounted the /dev/dsk/c0t0d0s6 slice back in the /etc/vfstab file that
mounted it to /usr. Keep in mind that this step can be used for /usr, /opt, var,
and swap file systems. For the root / file system, you would use the metaroot
command.
29./dev/dsk/c0t0d0s3 - - swap - no -
# /dev/md/dsk/d20 - - swap - no -
# reboot
31. Verify that the swap file system is mounted on the original slice
/dev/dsk/c0t0d0s3:
32.# swap -l
33.swapfile dev swaplo blocks free
/dev/dsk/c0t0d0s3 136,3 16 2101184 2101184
follows:
38.
39.# metaclear d22
43.
45.
Unmirror root (/)
The process for unmirroring the root file system (keeping in mind that it cannot be
unmounted) is fairly easy and straightforward. Keep in mind that this process is very
similar to that used for the /usr, /opt, var, and swap file systems.
In this example, I will unmirror the root (/) file system. The twist here is that the root file
system (just like /opt and swap) cannot be unmounted during normal system usage. The
root file system is currently mounted on a two-way mirrored volume named d20 that
consists of two submirrors d21 and d22. Before I created this two-way mirror for the root
file system, the file system was mounted on the slice /dev/dsk/c0t0d0s0. For the
purpose of this example, I want to unmirror the file system while preserving the data for
the root file system, remove all volumes that were involved in the mirrored volume, and
return the file system back to normal to where it existed; mounted on
/dev/dsk/c0t0d0s0. The second part of the mirror (submirror2) is /dev/dsk/c0t2d0s0
and will be made available for other uses after it is no longer part of the mirror.
"Okay" state.
2. # metastat d20
3. d20: Mirror
4. Submirror 0: d21
5. State: Okay
6. Submirror 1: d22
7. State: Okay
8. Pass: 1
12.
14. State: Okay
16. Stripe 0:
Spare
19.
20.
22. State: Okay
24. Stripe 0:
Spare
c0t2d0s0 0 No Okay
26. Next, run the metadetach command on the mirror that contains the root file
28. The metaroot command is then run, using the rootslice that the system is going to
boot from. This edits the /etc/system and /etc/vfstab files to remove
information specifying the mirroring of root (/):
# metaroot /dev/dsk/c0t0d0s0
# reboot
follows:
34.
35.# metaclear d22
39.
41.
Removing a RAID5 Volume - (RAID 5)
The process for removing a RAID5 Volume is fairly easy and straightforward. The same
method can be used for a sriped and concatenated volume as well.
The following example unmounts the file system from the newly created volume, /d3,
and then uses the metaclear command to permanently remove the volume from the
system. Keep in mind that this example will remove the volume /d3 from the system and
all data stored on it!
# umount /db3

yes -
# rmdir /db3
4. Finally, to remove the RAID5 volume, use the metaclear command as follows:
5. # metaclear d3
d3: RAID is cleared
6. You can now use the metastat command to verify that the RAID5 volume was
removed:
7. # metastat d3
Removing a Hot Spare
Adding SCSI Host Adapter (X6541A) into a Blade 100/150

Overview
A Sun Blade 100/150 can accept the following PCI SCSI host adapters:
Option # Top Level Part # Manufacturing Part # Description Substitute Part #
Single-Ended Ultra/Wide
X1032A 595-4258 501-5656 SCSI/FastEthernet (SunSwift 501-2741
PCI)
Dual Ultra-2 SCSI/Dual
X2222A 595-5624 501-5727 n/a
FastEthernet PCI Adapter
Single-Channel Single-Ended
X5010A 595-5377 375-0097 n/a
Ultra/Wide SCSI (PCI)
Dual Single-Ended
X6540A 595-4399 375-0005 n/a
Ultra/Wide SCSI (PCI)
Dual Differential Ultra/Wide
X6541A 595-4414 375-0006 n/a
SCSI (PCI)
In this article I will be documenting the steps for installing and configuring a Dual
Differential Ultra/Wide SCSI (PCI) host adapter (X6541A) in a Sun Blade 150 running
Solaris 8.
The above host adapters are designed to be installed in SPARC systems running at least
Solaris 2.5.1 Hardware:4/97 operating system.
The host adapters support up to 15 targets on each SCSI bus.
Installing the Dual Differential Ultra/Wide SCSI (PCI)
The following section documents the steps necessary to install a Dual Differential
Ultra/Wide SCSI (PCI) (X6541A) in a Sun Blade 150.
1. Check OS version
Check the file /etc/release to ensure you are running Solaris 2.5.1 or higher.
# cat /etc/release
Solaris 8 2/02 s28s_u7wos_08a SPARC

Copyright 2002 Sun Microsystems, Inc. All Rights Reserved.
Assembled 18 December 2001
2. Exit the OS and power down the system
Use either the shutdown command (if this is a server with active users that should
be warned) or init 0 (if this is a stand along server). When at the ok prompt
power down the system.
3. Unpack host adapter
The following items should be included with your host adapter package:
1. PCI UltraSCSI host adapter

2. 2 meter UltraSCSI-compliant cable
3. Electrostatic discharge (ESD) kit
4. Open the computer
5. Attach the wrist strap
Attach the wrist strap between your wrist and a metal part of the system chassis.
6. Disconnect power cord from computer

7. Remove the filler panel for the desired slot
In most cases this will be just one screw to remove in order to remove the filler
panel for the desired PCI slot.
8. Make sure that the switches and jumpers are correctly set.
For the single-ended host adapter, confirm the following settings:
o Make sure that all elements of switches U1 and U2 are off.

o Make sure that jumper TP9 is open.
For the differential host adapter, confirm the following settings:
o Make sure that all jumpers (TP1, TP2, TP3, TP5, TP6) are open.
2. Install the host adapter
Install the host adapter into the PCI slot in your system. Ensure to secure the card
in with the screw used in the removed filler panel. Using excessive force can bend
or damage the pins.
3. Close up system
Close up the system and remove the anti-static wrist strap.
4. Reconnect power cable

5. Connect the SCSI cables
Connect the SCSI cable to your newly installed SCSI host adapter and then to the
SCSI peripheral(s).
6. Power on peripherals / system
Power on your peripherals and then your system.
NOTE: If your system starts to reboot, interrupt the reboot process by pressing the
Stop and A keys together. If this is not possible, allow the system to complete the
boot process and then bring the system to the ok prompt by using init 0.
7. Make sure the host adapter is recognized by the system
Use the probe-scsi-all command to display the SCSI devices connected to

your system. For example:
ok probe-scsi-all
/pci@1f,2000/scsi@2
Target 8
Unit 0 Disk SEAGATE ST34371W SUN4.2G8254
/pci@1f,2000/scsi@2,1
Target 1
Unit 0 Disk SEAGATE ST34371W SUN4.2G8254
In the example, the first SCSI port (scsi@2) has one disk drive connected (target
8). The second SCSI port (scsi@2,1) also has one disk drive connected (target 1).
8. Reboot your system (using the -r option)
ok boot -r
9. Test the installation with SunVTS
You can use the SunVTS diagnostic program exercise your system to verify the
functionality, reliability, and configuration of the new host adapter card. It is
recommended to run the SunVTS program before attempting to utilize the new
host adapter for any applications.
The SunVTS program needs to be run as the root userid.
# su
Bring up the SunVTS program (GUI Window):
# /opt/SUNWvts/bin/sunvts
1. Select a disk drive (any disk) that is attached to the host adapter card you
just installed.
2. Start the test by hitting the "Start" button.
3. Verify that no errors have occurred by checking the SunVTS status
window.
4. If no problems occur, stop SunVTS by hitting the "Stop" button and exit
from the SunVTS application.
Your host adapter card is ready to run applications!
Adding Second IDE Hard Drive into a Blade 100/150

There are seven steps, all relatively easy.
1. Install the physical hard drive. Basic instructions are in the Sun Blade 100/150
Service Manual, available from the Sun website:
o Sun Blade 100 Service Manual - (Section 7.3.3, page 7-7)
o Sun Blade 150 Service Manual - (Section 7.3.3, page 7-8)
2. Reboot the machine and get to the ok prompt. In most cases, you can just init 0.
(Ignore error messages about a bad label on the disk, if any)
3. At the ok prompt, probe the new IDE device using probe-ide then reboot the
system using the rescan option "-r" as show in the following example:
4. ok probe-ide
5. This command may hang the system if a Stop-A or halt command
6. has been executed. Please type reset-all to reset the system
7. before executing this command.
8. Do you wish to continue? (y/n) y
9. Device 0 ( Primary Master )
10. ATA Model: WDC WD400BB-22DEA0
11.
12. Device 1 ( Primary Slave )
13. Removable ATAPI Model: LTN486S
14.
15. Device 2 ( Secondary Master )
16. ATA Model: WDC WD400BB-22DEA0
17.
18. Device 3 ( Secondary Slave )
19. Not Present
20.
ok boot -r
21. Next is to partition the disk. Under Solaris, the command to partition disks is:
format. This is an interactive tool similar to FDISK under MS-DOS. In most
cases, you will be allocating all available space to one partition. If this is the case,
simply allocate all cylinders to a partition on slice 7 of the disk. You will also see
that slice 2 is already labeled "backup". You can just leave this as is. When the
partition table is ready, then write the table to disk and label the disk. Labeling the
disk can also be done within the interactive format session.
22. Put a UFS filesystem on the disk using the newfs command. The device name
should be /dev/rdsk/c0t2d0s7 if you partitioned as above.
# newfs /dev/rdsk/c0t2d0s7
23. Create a mount point that will be used to mount the new disk somewhere in you
current filesystem. For example, if you wanted to mount the new disk on /db2:
# mkdir /db2
24. Edit /etc/vfstab and add a line for the new filesystem. It should look like this
(all one line with tabs separating the fields):
25.#device device mount FS fsck
mount mount
26.#to mount to fsck point type pass
at boot options
27.#
28.#/dev/dsk/c1d0s2 /dev/rdsk/c1d0s2 /usr ufs 1
yes -
29.fd - /dev/fd fd - no -
30./proc - /proc proc - no -
31./dev/dsk/c0t0d0s3 - - swap - no -
32./dev/dsk/c0t0d0s0 /dev/rdsk/c0t0d0s0 / ufs 1
no -
33./dev/md/dsk/d0 /dev/md/rdsk/d0 /db0 ufs 2 yes -
34./dev/md/dsk/d1 /dev/md/rdsk/d1 /db1 ufs 2 yes -
35./dev/dsk/c0t2d0s7 /dev/rdsk/c0t2d0s7 /db2 ufs 2
yes -
swap - /tmp tmpfs - yes -
This will mount the filesystem to /db2 at boot time.

That's it! It doesn't take long. The hardest part is getting the drive installed into the
chassis without damaging all the various cables.
To check your disk configuration use the format command. In the example below, I
include settings on a Sun Blade 150 configured with two 40GB IDE disks. First login as
the root userid and perform the following. Notice that by convention, slice 2 is always
used as a backup partition and is always the size of the entire disk.
# format
Searching for disks...done
AVAILABLE DISK SELECTIONS:

0. c0t0d0 <WDC WD400BB-22DEA0 cyl 19156 alt 2 hd 16 sec 255>
/pci@1f,0/ide@d/dad@0,0
Specify disk (enter its number): 0
selecting c0t0d0
[disk formatted, no defect list found]
Warning: Current Disk has mounted partitions.
format> verify
Volume name = < >

ascii name = <WDC WD400BB-22DEA0 cyl 19156 alt 2 hd 16 sec 255>
pcyl = 19158
ncyl = 19156
acyl = 2
nhead = 16
nsect = 255
0 root wm 0 - 18640 36.27GB (18641/0/0) 76055280
1 swap wu 18641 - 19155 1.00GB (515/0/0) 2101200
2 backup wm 0 - 19155 37.27GB (19156/0/0) 78156480
format> disk
AVAILABLE DISK SELECTIONS:

Specify disk (enter its number)[0]: 1
selecting c0t2d0
[disk formatted, no defect list found]
Warning: Current Disk has mounted partitions.
format> verify
Volume name = < >

ascii name = <WDC WD400BB-22DEA0 cyl 19156 alt 2 hd 16 sec 255>
pcyl = 19158
ncyl = 19156
acyl = 2
nhead = 16
nsect = 255
2 backup wm 0 - 19155 37.27GB (19156/0/0) 78156480
7 unassigned wm 0 - 19155 37.27GB (19156/0/0) 78156480
Partition Examples - (Sun)

Overview
This document provides several example disk-partitioning examples that can be used for
installing Sun Solaris on. Along with each partitioning example, I provide the filesystems
mounted on those partitions.
Example #1
/dev/dsk/c0t0d0s3 swap
/dev/dsk/c0t0d0s0 / ufs
/dev/dsk/c0t0d0s6 /usr ufs
/dev/dsk/c0t0d0s1 /var ufs
/dev/dsk/c0t0d0s5 /opt ufs
/dev/dsk/c0t0d0s7 /db ufs
swap /tmp tmpfs
Volume name = < >
ascii name = <ST315310A cyl 29649 alt 2 hd 16 sec 63>
pcyl = 29651
ncyl = 29649
acyl = 2
nhead = 16
nsect = 63
0 root wm 0 - 304 150.12MB (305/0/0)
307440
1 var wm 305 - 1320 500.06MB (1016/0/0)
1024128
2 backup wm 0 - 29648 14.25GB (29649/0/0)
29886192
3 swap wu 1321 - 5482 2.00GB (4162/0/0)
4195296
4 unassigned wm 0 0 (0/0/0)
0
5 usr wm 5483 - 8530 1.47GB (3048/0/0)
3072384
6 usr wm 8531 - 11578 1.47GB (3048/0/0)
3072384
7 usr wm 11579 - 29648 8.69GB (18070/0/0)
18214560
Example #2
swap /tmp tmpfs
Volume name = < >
pcyl = 38792
ncyl = 38790
acyl = 2
nhead = 16
nsect = 63
0 root wm 2 - 306 150.12MB (305/0/0)
307440
1 var wm 307 - 2338 1000.12MB (2032/0/0)
2048256
2 backup wm 0 - 38789 18.64GB (38790/0/0)
39100320
3 swap wm 2339 - 6500 2.00GB (4162/0/0)
4195296
4 usr wm 6501 - 9548 1.47GB (3048/0/0)
3072384
5 usr wm 9549 - 12596 1.47GB (3048/0/0)
3072384
6 usr wm 12597 - 38789 12.59GB (26193/0/0)
26402544
7 unassigned wm 0 - 1 0.98MB (2/0/0)
2016
Example #3
swap /tmp tmpfs
/dev/dsk/c0t2d0s7 /image ufs
Disk 1
Volume name = < >

pcyl = 38792
ncyl = 38790
acyl = 2
nhead = 16
nsect = 63
0 root wm 2 - 306 150.12MB (305/0/0)
307440
1 var wm 307 - 2338 1000.12MB (2032/0/0)
2048256
2 backup wm 0 - 38789 18.64GB (38790/0/0)
39100320
3 swap wm 2339 - 6500 2.00GB (4162/0/0)
4195296
4 usr wm 6501 - 9548 1.47GB (3048/0/0)
3072384
5 usr wm 9549 - 12596 1.47GB (3048/0/0)
3072384
6 usr wm 12597 - 38789 12.59GB (26193/0/0)
26402544
7 unassigned wm 0 - 1 0.98MB (2/0/0)
2016
Disk 2
Volume name = < >

pcyl = 57461
ncyl = 57459
acyl = 2
nhead = 16
nsect = 255
0
0
2 backup wu 0 - 57458 111.79GB (57459/0/0)
234432720
0
0
0
0
7 unassigned wm 0 - 57458 111.79GB (57459/0/0)
234432720
Determining Disk Throughput - (Sun)

Overview
This document provides several example on how to test and determine disk throughput.
Write Example #1
Here is an easy solution to determine the time (and throughput) on how long it would
take to write 1GB of data to a file. Keep in mind that you will also want to perform (and
time) a sync after the write has completed:
# rm -f /u07/app/test/gigfile
# sync; time dd ibs=1048576 obs=1048576 count=1024 if=/dev/zero

of=/u07/app/test/gigfile
1024+0 records in
1024+0 records out
real 0m36.41s
user 0m13.36s
sys 0m17.73s
# time sync
real 0m0.15s
user 0m0.00s
sys 0m0.04s
From the above, we can estimate that I am getting roughly 28.01 MB/sec.
1024 MB / (36.41 + 0.15) (s) = 28.01 MB/sec.
NFS a Remote File System on Solaris

This short article demonstrates how to mount a remote file system on Solaris. Before
getting into the details, you must be logged into Solaris as the root user account.
The syntax to mount a remote file system using NFS is as follows:
mount -F nfs <remote file system> <mount point>

The following example will mount the file system /share2 located on the host cartman
to the mount point /cartman:
mount -F nfs cartman:/share2 /cartman
You can also enable the above mount command to occur on each startup of the system,
you can insert the following line into your /etc/vfstab file:
#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 -
#
# ----------------------------------------------
# DEFINE THE swap PARTITION
# ----------------------------------------------
/dev/dsk/c0t0d0s1 - - swap - no -
#
# ----------------------------------------------
# MOUNT THE root PARTITION
# ----------------------------------------------
/dev/dsk/c0t0d0s0 /dev/rdsk/c0t0d0s0 / ufs 1
no -
#
# ----------------------------------------------
# MOUNT THE swap PARTITION
# ----------------------------------------------
#
# ----------------------------------------------
# MOUNT /u01
# ----------------------------------------------
/dev/dsk/c0t2d0s7 /dev/rdsk/c0t2d0s7 /u01 ufs 2
yes -
#
# ----------------------------------------------
# MOUNT /cartman VIA NFS
# ----------------------------------------------
cartman:/share2 - /cartman nfs
- yes rw,soft
#
# ----------------------------------------------
# THE ENTRIES BELOW ARE FOR THE (D1000) EXAMPLES
# ----------------------------------------------
/dev/md/dsk/d0 /dev/md/rdsk/d0 /db0 ufs 2 yes -
#
# -- ALL ORACLE DATA FILES
# /dev/md/dsk/d0 /dev/md/rdsk/d0 /db0 ufs 2 yes
-
# -- ORACLE CONTROL and ONLINE REDO LOG FILES
# /dev/md/dsk/d1 /dev/md/rdsk/d1 /u03 ufs 2 yes
-
-
-
Sample /etc/vfstab File - (Solaris)

by Jeffrey Hunter, Sr. Database Administrator
There are many times that I need a sample /etc/vfstab around just as a reference when
configuring a new Solaris machine - and here is one:
#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 -
#
# ---------------------------------------------------------
# DEFINE THE swap PARTITION
# ---------------------------------------------------------
/dev/dsk/c0t0d0s1 - - swap - no -
#
# ---------------------------------------------------------
# MOUNT THE root PARTITION
# ---------------------------------------------------------
/dev/dsk/c0t0d0s0 /dev/rdsk/c0t0d0s0 / ufs 1
no -
#
# ---------------------------------------------------------
# MOUNT THE swap PARTITION
# ---------------------------------------------------------
#
# ---------------------------------------------------------
# MOUNT /cartman VIA NFS
# ---------------------------------------------------------
cartman:/share2 - /cartman nfs
- yes rw,soft
#
# ---------------------------------------------------------
# MOUNT /u01
# ---------------------------------------------------------
/dev/dsk/c0t2d0s7 /dev/rdsk/c0t2d0s7 /u01 ufs
2 yes -
#
# ---------------------------------------------------------
# CONTROL 1 / REDO G1 M1 / REDO G2 M1 / REDO G3 M1
#
# metainit d0 1 1 c1t0d0s7 -i 32k
# ---------------------------------------------------------
/dev/md/dsk/d0 /dev/md/rdsk/d0 /u03 ufs
2 yes -
#
# ---------------------------------------------------------
#
# ---------------------------------------------------------
2 yes -
#
# ---------------------------------------------------------
#
# ---------------------------------------------------------
2 yes -
#
# ---------------------------------------------------------
# ALL ORACLE DATA FILES
#
# metainit d3 1 9 c2t1d0s7 c1t2d0s7 c1t3d0s7 c1t4d0s7 c1t5d0s7 c2t2d0s7
c2t3d0s7 c2t4d0s7 c2t5d0s7 -i 32k
# ---------------------------------------------------------
2 yes -
#
fsck Process
It's not uncommon under Solaris to get some fsck errors, especially if you powered off a
machine without doing a proper shutdown (or it crashed). The "FREE BLKS" errors is
extremely minor, you can safely just say "Y" to fixing those errors. This shouldn't happen
every time you boot, though, unless you aren't shutting down properly. It's also possible
to say "fsck -y" and then it will fix everything without prompting you.
Do not try to fsck a currently mounted filesystem - that will always produce an error
(and is a bad idea) because the filesystem data structures are "open" and there may be
changes in memory that have not been written to the disk yet. The proper way is to fsck
a filesystem when it's not mounted. How do you do that if it's the root filesystem you
want to fsck? Well, the OS does it at boot by mounting / readonly, fscking it, and then
remounting it read/write. My approach would be to boot off the CD ("boot cdrom -s, or
boot -s cdrom, from the ok prom prompt) and then fsck the hard disk.
Understanding Disk Device Files (i.e. breaking down

c0t2d0s7)
Overview
Under Solaris, one of the most involved UNIX devices to understand is the disk device
file. Here are several key points that may help:
• In many cases, a disk device file (i.e. /dev/dsk/c0t2d0s7) refers to a particular

partition (aka "slice") of a disk, and not the entire physical device. There are
several device files which refer to the entire physical device, but are rarely used.
• For every disk device, there are usually two device files - the block device and the
character ("raw") device. In general:
o block devices are generally stored under /dev/dsk and used for filesystem
type access (e.g mount)
o character devices are generally stored under /dev/rdsk used for
everything else (e.g. fsck, newfs, etc..)
• Discs are generally attached to a controller (or a bus) which can handle multiple
devices. IDE and SCSI are both common attach methods. This tends to make disk
device filename more complex than other types of devices.
/etc/vfstab
To see the difference between the block device and character device for a device,
consider the following. The /etc/vfstab contains entries for a single filesystem on a
Solaris server:
/dev/dsk/c0t2d0s7 /dev/rdsk/c0t2d0s7 /opt ufs 3 yes -
The first 2 fields in the above entry, list the same disk device as both a block device
("dsk") and character device ("rdsk"). The block device is used by mount when mounting
the filesystem while the character device is used by fsck when checking the filesystem
and newfs when creating the filesystem.. Both fields must be present in /etc/vfstab.
Breaking Down c0t2d0s7
This section breaks down the different components of a disk device file. In this example,
I will be using the disk device file: c0t2d0s7. The four components of the disk device
file are: controller, target, LUN and slice/partition and further defined in the following
table:
This device is attached to controller #0. On a SPARCstation this is usually the on-
c0 board SCSI or IDE controller. If this is a PC it usually refers to the first IDE
controller on the motherboard.
The device is target #2 - (i.e. the second device on this controller.) On a SCSI
controller this is the SCSI target ID and is usually set via a switch on any external
t2 enclosure or by jumpers on the disk itself. On an IDE controller target #2 refers to
the second IDE disk. With IDE this is generally determined by the device's
position on the IDE cable.
The device is Logical Unit / "LUN" #0 (the first) on this target. Under SCSI a
d0 single target can support up-to eight devices. This is rarely seen in practice, but
some hardware raid controllers use LUNs.
s7
Slice or Partition number 7. Under Solaris, this relates to the partition number as
set when using the format command.
Removing Invalid Disk Device Files (/dev/dsk and /dev/rdsk)

Overview
Whether installing a SCSI controller or even an additional IDE disk to a Sun Solaris
machine, the Solaris O/S will:
• Create Disk Device Files under the Hardware Device Tree (/devices).
• Create symbolic links in /dev/dsk, /dev/rdsk, and /dev/cfg that point to the
devices in the /devices directory.
• Make entries in the /etc/path_to_inst file.
Things will generally work fine until you decide to remove or move a device in the
system. I have had situations where I have run out of devices on a host because of Sun's
poor ability to remove invalid (hanging) disk device files after removing a device. This is
one area where Sun could really improve. It looks like they are trying new things with the
boot -p option but I've only ever seen it remove things once.
There are other times when I simply wanted to replace a certain type of SCSI controller
and wanted to reuse the controller ID's from a previously removed card. For example, I
have a host (an E450) which had 2 internal controllers (0 and 1) and a dual differential
SCSI card installed (controllers 2 and 3). I removed the dual differential SCSI host
adapter and decided to replace it with a Single-Ended SCSI host adapter but Solaris
would always assign them controller numbers 4 and 5. I wanted the system to reassign
controller numbers 2 and 3 for the new host adapter but links still existed for the original
dual differential SCSI host adapter.
My intention in this article is to provide several solutions for either renumbering disk
device files (SCSI controllers, SCSI disks, IDE controllers, IDE disks, etc.) or simply
removing old ones from replaced or removed devices. Please keep in mind that this
article has been put together from notes I found during many searches for answers on the
Internet. If anyone reading this has other solutions, please email me and I would be happy
to post them for others going through this procedure.
Using the devfsadm Command

The devfsadm command was introduced with Solaris 7 and can be found in
/usr/sbin/devfsadm. This command is used to maintain the /dev and /devices
namespaces. The devfsadm command replaces the previous suite of devfs administration
tools including drvconfig(1M), disks(1M), tapes(1M), ports(1M), audlinks(1M),
and devlinks(1M). To maintain backwards compatibility, all previous devfs commands
are hard links to devfsadm.
In many cases, you only need run the command:
# devfsadm -C
to invoke the cleanup routines that are not normally invoked to remove dangling logical
links.
Manual Methods
The devfsadm command was introduced with Solaris 7. For those running older versions
of Solaris (i.e. Solaris 2.6) or simply want to perform all manual steps, this section
describes the procedures to do just that.
1. Make a backup of your /etc/path_to_inst file and then modify the file so that
all that exists is the SCSI / IDE reference for the boot drive. Remove all of the
"pcipsy" and "glm" entries except for the one that is used by the controller that
has the boot drive. Take note of the physical path of the controller you want to
renumber.
2. Remove all /dev/dsk/cX* and /dev/rdsk/cX* files where X is the controller
number(s) you want to remove and even those that no longer exist. (In the case of
the example I provided on the E450, that would be 2, 3, 4, and 5.)
3. Remove all /dev/cfg/cX symbolic links where X is the controller(s) you want to
remove. Make sure to not remove the controller with the boot drive. (Again, in
the case of the example I provided on the E450, that would be 2, 3, 4, and 5.) It
turns out this was one of the crucial steps that needed to be complete in order for
Solaris to reuse controller numbers 2 and 3. The O/S was not able to reassign both
of these controller numbers while the links (/dev/cfg/2 and /dev/cfg/3) still
existed.
4. Remove all files under /devices/* for the controller you want to remove or
renumber as indicated in Step #1.
5. Remove all files in /dev/sdXX* that symbolically link to controller(s) you do not
want anymore. This may not be completely necessary, but it does clean things up.
6. Reboot the server with the "-srv" option: ok boot -srv
Using the "truss" command in Solaris

Using truss
Truss is used to trace the system/library calls (not user calls) and signals made/received
by a new or existing process. It sends the output to stderr.
NOTE: Trussing a process throttles that process to your display speed. Use -wall and
-rall sparingly.
Truss usage
truss -a -e -f -rall -wall -p
truss -a -e -f -rall -wall
-a Show arguments passed to the exec system calls

-e Show environment variables passed to the exec system calls
-f Show forked processes
(they will have a different pid: in column 1)
-rall Show all read data (default is 32 bytes)
-wall Show all written data (default is 32 bytes)
-p Hook to an existing process (must be owner or root)
<program> Specify a program to run
Truss examples
# truss -rall -wall -f -p <PID>
# truss -rall -wall lsnrctl start
# truss -aef lsnrctl dbsnmp_start
A Running Example (using the date command)

# truss -d date
Base time stamp: 1066157908.5731 [ Tue Oct 14 14:58:28 EDT 2003 ]

0.0000 execve("/usr/bin/date", 0xFFBEF29C, 0xFFBEF2A4) argc = 1
0.0449 mmap(0x00000000, 8192, PROT_READ|PROT_WRITE|
PROT_EXEC,MAP_PRIVATE|MAP_ANON, -1, 0) = 0xFF3A0000
0.0453 resolvepath("/usr/lib/ld.so.1", "/usr/lib/ld.so.1", 1023) = 16
0.0457 open("/var/ld/ld.config", O_RDONLY) Err#2 ENOENT
0.0460 open("/usr/lib/libc.so.1", O_RDONLY) = 3
0.0463 fstat(3, 0xFFBEE9C4) = 0
0.0464 mmap(0x00000000, 8192, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0)
= 0xFF390000
0.0466 mmap(0x00000000, 794624, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3,
0) = 0xFF280000
0.0470 mmap(0xFF33A000, 24652, PROT_READ|PROT_WRITE|
PROT_EXEC,MAP_PRIVATE|MAP_FIXED, 3, 696320) = 0xFF33A000
0.0474 munmap(0xFF32A000, 65536) = 0
0.0479 memcntl(0xFF280000, 113332, MC_ADVISE, MADV_WILLNEED, 0, 0) = 0
0.0481 close(3) = 0
0.0483 open("/usr/lib/libdl.so.1", O_RDONLY) = 3
0.0485 fstat(3, 0xFFBEE9C4) = 0
0.0487 mmap(0xFF390000, 8192, PROT_READ|PROT_EXEC, MAP_PRIVATE|
MAP_FIXED,3, 0) = 0xFF390000
0.0490 close(3) = 0
0.0493 open("/usr/platform/SUNW,Ultra-5_10/lib/libc_psr.so.1",
O_RDONLY) = 3
0.0496 fstat(3, 0xFFBEE854) = 0
= 0xFF380000
= 0xFF370000
0.0502 close(3) = 0
0.0514 munmap(0xFF380000, 8192) = 0
0.0521 brk(0x00022420) = 0
0.0523 brk(0x00024420) = 0
0.0526 time() = 1066157908
0.0531 open("/usr/share/lib/zoneinfo/US/Eastern", O_RDONLY) = 3
0.0533 read(3, " T Z i f\0\0\0\0\0\0\0\0".., 8192) = 1250
0.0536 close(3) = 0
0.0542 ioctl(1, TCGETA, 0xFFBEEFDC) = 0
Tue Oct 14 14:58:28 EDT 2003
0.0545 write(1, " T u e O c t 1 4 1".., 29) = 29
0.0547 llseek(0, 0, SEEK_CUR) = 1829
0.0549 _exit(0)
NOTE: The "truss" command works on SUN and Sequent. Use "strace" on Linux. If
your operating system doesn't support the truss and strace commands, call your system
administrator to find the equivalent command on your system.
Monitor your Unix system:
Unix message files record all system problems like disk errors, swap errors, NFS
problems, etc. Monitor the following files on your system to detect system problems:
# tail -f /var/adm/SYSLOG
# tail -f /var/adm/messages
# tail -f /var/log/syslog
Configuring TCP/IP on Solaris - TCP/IP Configuration Files - Introduction
In order to configure networking after installing Solaris, several files will need to be
created and/or modified. This document provides a quick overview of those files along
with example configuration data.
In most cases, the installation process performs all necessary configuration tasks. One of
the tasks generally not performed by the installer is updating the Solaris networking files.
I have not found an easy way to force the installation program to configure all local
networking files if the "Naming Services" section fails. For example, if you select the
DNS naming service and the machine you are configuring is not entered in DNS, the
installation process will skip this section. In cases like this, it will be necessary to update
several of the files that pertain to networking. The following is a list of those files and the
content that should be provided. Keep in mind that the system will need to be rebooted
after making changes (and creating) these files.
/etc/resolv.conf
During the Solaris installation program, you are prompted for Naming Configuration
information. In most cases, we use DNS. But during the installation process, if the
installer is unable to communicate with and/or resolve your newly configured host with
DNS, the Naming Configuration will fail, and none of the configuration files (i.e.
/etc/resolv.conf) will not be updated. I often find it necessary to manually create the
/etc/resolv.conf with any name service information.
nameserver 63.67.120.18
nameserver 63.67.120.23
/etc/resolv.conf
/etc/hostname.interface
The Solaris installation program creates this file for you. The file contains only one entry:
the host name or IP address associated with the network interface. For example, suppose
eri0 is the primary network interface for a machine called alexprod. Its
/etc/hostname.interface file would have the name /etc/hostname.eri0; the file
would contain the single entry alexprod.
alexprod
/etc/hostname.eri0
/etc/nodename
This file should contain one entry; the host name of the local machine. For example, on
machine alexprod, the file /etc/nodename would contain the entry alexprod.
alexprod
/etc/nodename
/etc/defaultdomain
This file should contain one entry, the full qualified domain name of the administrative
domain to which the local host's network belongs. You can supply this name to the
Solaris installation program or edit the file at a later date.
Take for example the domain iDevelopment which was classified as a .info domain. In
this example, /etc/defaultdomain should contain the entry iDevelopment.info.
idevelopment.info
/etc/defaultdomain
/etc/defaultrouter
This file should contain an entry for each router directly connected to the network. The
entry should be the name for the network interface that functions as a router between
networks.
If the default router for a machine will be 192.168.1.1, then this is the entry that should
be put into the file /etc/defaultrouter.
192.168.1.1
/etc/defaultrouter
/etc/hosts
The hosts database contains the IP addresses and host names of machines on your
network.
If you use local files for name service, the hosts database is maintained in the
/etc/inet/hosts file. This file contains the host names and IP addresses of the primary
network interface, other network interfaces attached to the machine, and any other
network addresses that the machine must know about.
NOTE: For compatibility with BSD-based operating systems, the file /etc/hosts is a
symbolic link to /etc/inet/hosts.
#
# Internet host table
#
127.0.0.1 localhost
192.168.1.102 alexprod alexprod.idevelopment.info loghost
/etc/hosts
/etc/inet/netmasks
You need to edit the netmasks database as part of network configuration only if you have
set up subnetting on your network. The netmasks database consists of a list of networks
and their associated subnet masks.
#
# The netmasks file associates Internet Protocol (IP) address
# masks with IP network numbers.
#
# network-number netmask
#
# The term network-number refers to a number obtained from the
Internet Network
# Information Center. Currently this number is restricted to being
a class
# A, B, or C network number. In the future we should be able to
support
# arbitrary network numbers per the Classless Internet Domain Routing
# guidelines.
#
# Both the network-number and the netmasks are specified in
# "decimal dot" notation, e.g:
#
# 128.32.0.0 255.255.255.0
#
192.168.1.0 255.255.255.0
/etc/inet/netmasks
/etc/nsswitch.conf
The /etc/nsswitch.conf file defines the search order of the network databases (hosts,
netmasks, ethers, bootparams, protocols, services, networks).
The Solaris installation program creates a default /etc/nsswitch.conf file for the local
machine, based on the name service you indicate during the installation process. The
installation process also creates 5 template files that can be copied over to
/etc/nsswitch.conf:
• nsswitch.files
• nsswitch.nis
• nsswitch.dns
• nsswitch.ldap
• nsswitch.nisplus
If you selected the 'None' option, indicating local files for name service, the resulting
/etc/nsswitch.conf file resembles the following example:
#
# /etc/nsswitch.files:
#
# An example file that could be copied over to /etc/nsswitch.conf; it
# does not use any naming service.
#
# "hosts:" and "services:" in this file are used only if the
# /etc/netconfig file has a "-" for nametoaddr_libs of "inet"
transports.
passwd: files
group: files
hosts: files
ipnodes: files
networks: files
protocols: files
rpc: files
ethers: files
netmasks: files
bootparams: files
publickey: files
# At present there isn't a 'files' backend for netgroup; the system
will
# figure it out pretty quickly, and won't use netgroups at all.
netgroup: files
automount: files
aliases: files
services: files
sendmailvars: files
printers: user files
auth_attr: files
prof_attr: files
project: files
/etc/nsswitch.conf - Default if you are using local files
Here is another /etc/nsswitch.conf file that adds a dns entry for hosts::
#
# /etc/nsswitch.dns:
#
# An example file that could be copied over to /etc/nsswitch.conf;
it uses
# DNS for hosts lookups, otherwise it does not use any other naming
service.
#
transports.
passwd: files
group: files
# You must also set up the /etc/resolv.conf file for DNS name
# server lookup. See resolv.conf(4).
hosts: files dns
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
networks: files
protocols: files
rpc: files
ethers: files
netmasks: files
bootparams: files
publickey: files
# At present there isn't a 'files' backend for netgroup; the system
will
# figure it out pretty quickly, and won't use netgroups at all.
netgroup: files
automount: files
aliases: files
services: files
sendmailvars: files
printers: user files
auth_attr: files
prof_attr: files
project: files
/etc/nsswitch.conf - Adding a dns database for the hosts: element
Here is another /etc/nsswitch.conf file that uses a combination of files, nis, and dns
entries:
# /etc/nsswitch.nis:
#
# An example file that could be copied over to /etc/nsswitch.conf; it
# uses NIS (YP) in conjunction with files.
#
transports.
# the following two lines obviate the "+" entry in /etc/passwd and
/etc/group.
passwd: files nis
group: files nis
# consult /etc "files" only if nis is down.

hosts: files dns nis
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: nis [NOTFOUND=return] files
networks: nis [NOTFOUND=return] files

protocols: nis [NOTFOUND=return] files
rpc: nis [NOTFOUND=return] files
ethers: nis [NOTFOUND=return] files
netmasks: nis [NOTFOUND=return] files
bootparams: nis [NOTFOUND=return] files
publickey: nis [NOTFOUND=return] files
netgroup: nis
automount: files nis

aliases: files nis
# for efficient getservbyname() avoid nis
services: files nis
sendmailvars: files
printers: user files nis
auth_attr: files nis

prof_attr: files nis
project: files nis
/etc/nsswitch.conf - Using a combination of files, nis, and dns databases
Configuring TCP/IP on Solaris - Introduction / Pre-Requisites
Introduction
After planning and optionally getting a network number from InterNIC, it is time to start
the second phase of network administration - setting up the network. This consists of
assembling the hardware which makes up the physical part of the network, and
configuring TCP/IP. This section of Networking Basics explains how to configure
TCP/IP. Before starting the configuration of TCP/IP, ensure you have the following
completed:
• Designed the network topology.

• Obtained a network number from your Internet addressing authority.
• Assembled the network hardware according to the topology designed and assured
that the hardware is functioning.
• Run any configuration software required by network interfaces and routers, if
applicable.
• Planned the IP addressing scheme for the network, including subnet addressing if
applicable.
• Assigned IP numbers and host names to all machines involved in the network.
• Determined which name service your network will use: NIS, NIS+, LDAP, DNS,
or local files.
• Selected domain names for your network, if applicable.
• Installed the operating system on at least one machine on the prospective network.
Determining Host Configuration Mode
As a network administrator, one of your key functions is to configure TCP/IP to run on all
hosts and routers (if applicable). You can set up these machines to obtain configuration
information from two sources:
• Files on the local machine

• Files located on other machines on the network
Configuration information will include:
• Host name of the machine

• IP address of the machine
• Domain name to which the machine belongs to
• Default router
• Netmask in use on the machine's network
A machine that obtains TCP/IP configuration information from local files is said to be
operating in local files mode. A machine that obtains TCP/IP configuration information
from a remote machine is said to be operating in network client mode.
Machines That Should Run in Local Files Mode
For a machine to run in local files mode, it must have local copies of the TCP/IP
configuration files. These files are described in the "TCP/IP Configuration Files"
document. The machine should have its own disk, though this is not strictly necessary.
Most servers should run in local file mode. This requirement includes:
• Network configuration servers

• NFS Servers
• Name servers supplying NIS, NIS+, LDAP, or DNS services
• Mail servers
• Routers
Machines that exclusively function as print servers do not need to run in local files mode.
Whether individual hosts should run in local files mode depends on teh size of your
network.
If you are running a very small network, the amount of work involved in maintaining
these files on individual hosts is management. If you network serves hundreds of hosts,
the taks becomes difficult, even with the network divided into a number of administrative
subdomains. Thus, for large networks, using local files mode is usually less efficient. On
the other hand, because routers and servers must be self-sufficient, they should be
configured in local files mode.
Network Configuration Servers
Network configuration servers are the machines that supply the TCP/IP configuration
information to hosts configured in network client mode. These server support three
booting protocols:
• RARP - Reverse Address Resolution Protocol (RARP) maps Ethernet addresses

(48 bits) to IP addresses (32 bits), the reverse ARP. When you run RARP on a
network configuration server, this enables hosts running in network client mode to
obtain their IP addresses and TCP/IP configuration files from the server. The
in.rarpd deamon enables RARP services.
• TFTP - Trivial File Transfer Protocol (TFTP) is an application that transfers files
between remote machines. The in.tftpd deamon carries out TFTP services,
enabling file transfer between network configuration servers and their network
clients.
• bootparams - The bootparams protocol supplies parameters for booting that are
required by diskless clients. The rpc.bootparamd deamon carries out these
services.
Network configuration servers can also function as NFS file servers.If you are going to
configure any hosts as network clients, then you must also configure at least one machine
on your network as a network configuration server. If your network is subneted, then you
must have at least one network configuration server for each subnet with network clients.
Machines That Are Network Clients

Any host that gets its configuration information from a network configuration server is
said to be "operating" in network client mode. Machines configured as network clients do
not require local copies of the TCP/IP configuation files.
Network client mode greatly simplifies administration of large networks. It minimizes the
number of configuation tasks that must be performed on individual hosts and assures that
all machines on the network adhere to the same configuration standards.
You can configure network client mode on all types of computers, from fully standalone
systems to diskless and dataless machines. Although it is possible to configure routers
and servers in network client mode, local files mode is a better choice for these machines.
Routers and servers should be as self-sufficient as possible.
Configuring TCP/IP on Solaris - TCP/IP Configuration Files
Introduction
Each machine on a TCP/IP network gets its configuration information from the following
TCP/IP configuration files and network databases:
• /etc/hostname.interface file
• /etc/nodename file
• /etc/defaultdomain file
• /etc/defaultrouter file (optional)
• hosts database
• netmasks database (optional)
The Solaris installation program creates these files as part of the installation process. You
can also edit the files manually, as explained in this document. The hosts and netmasks
databases are two of the network databases read by the name services available on Solaris
networks.
/etc/hostname.interface
This file defines the network interfaces on the local host. At least one
/etc/hostname.interface file should exist on the local machine. The Solaris installation
program creates this file for you. In the file name, interface is replaced by the device
name of the primary network interface.
The file contains only one entry: the host name or IP address associated with the network
interface. For example, suppose eri0 is the primary network interface for a machine
called alexprod. Its /etc/hostname.interface file would have the name
/etc/hostname.eri0; the file would contain the entry alexprod.
For Multiple Network Interfaces

If a machine contains more than one network interface, you must create additional
/etc/hostname.interface files for the additional network interfaces. You must create
these files with a text editor; the Solaris installation program does not create them for
you.
For example, consider the machine melodyprod. It has two network interfaces and
functions as a router. The primary network interface eri0 is connected to network
192.168.100. Its IP address is 192.168.100.50, and its host name is melodyprod. The
Solaris installation program creates the file /etc/hostname.eri0 for the primary
network interface and enters the host name melodyprod.
The second network interface is eri1; it is connected to network 192.168.200. Although

this interface is physically installed on machine melodyprod, it must have a separate IP
address. Therefore, you have to manually create the /etc/hostname.eri1 file for this
interface; the entry in the file would be the router's name; melodyprod-200.
/etc/nodename
This file should contain one entry; the host name of the local machine. For example, on
machine alexprod, the file /etc/nodename would contain the entry alexprod.
/etc/defaultdomain
This file should contain one entry, the full qualified domain name of the administrative
domain to which the local host's network belongs. You can supply this name to the
Solaris installation program or edit the file at a later date.
Take for example the domain iDevelopment which was classified as a .info domain. In
this example, /etc/defaultdomain should contain the entry iDevelopment.info.
/etc/defaultrouter
This file should contain an entry for each router directly connected to the network. The
entry should be the name for the network interface that functions as a router between
networks.
If the default router for a machine will be 192.168.1.1, then this is the entry that should
be put into the file /etc/defaultrouter.
hosts Database
The hosts database contains the IP addresses and host names of machines on your
network. If you use the NIS, NIS+, or DNS name services, the hosts database is
maintained in a database designated for host information. For example, on a network
running NIS+, the hosts database is maintained in the host table.
If you use local files for name service, the hosts database is maintained in the
/etc/inet/hosts file. This file contains the host names and IP addresses of the primary
network interface, other network interfaces attached to the machine, and any other
network addresses that the machine must know about.
NOTE: For compatibility with BSD-based operating systems, the file /etc/hosts is a
symbolic link to /etc/inet/hosts.
• /etc/inet/hosts File Format
The /etc/inet/hosts file uses this basic syntax: (Refer to the hosts(4) man page
for complete syntax information.)
IP-address hostname [nicknames] [#comment]
o IP-address contains the IP address for each interface that the local host
must know about.
o hostname contains the host name assigned to the machine at setup, plus
the host names assigned to additional network interfaces that the local host
must know about.
o [nickname] is an optional field containing a nickname for the host.
o [# comment] is an optional field where you can include a comment.
• Initial /etc/inet/hosts File
When you run the Solaris installation program on a machine, it sets up the initial
/etc/inet/hosts file. This file contains the minimum entries that the local host
requires: its loopback address, its IP address, and its host name.
For example, the Solaris installation program might create the following
/etc/inet/hosts file for machine alexprod shown in the following example:
127.0.0.1 localhost loghost #loopback address
192.168.100.51 alexprod #host name
• Loopback Address
In the above example, the IP address 127.0.0.1 is the loopback address, the
reserved network interface used by the local machine to allow interprocess
communication so that it sends packets to itself. The ifconfig command uses the
loopback address for configuration and testing. Every machine on a TCP/IP
network must use the IP address 127.0.0.1 for the local host.
• Host Name
The IP address 192.168.100.51 and the name alexprod are the address and host
name of the local machine. They are assigned to the machine's primary network
interface.
• Multiple Network Interfaces
Some machines have more than one network interface, either because they are
routers or multihomed hosts. Each additional network interface attached to the
machine requires its own IP address and associated name. When you configure a
router or multihomed host, you must manually add this information to the router's
/etc/inet/hosts file.
The following example is a /etc/inet/hosts file for machine alexroute:
127.0.0.1 localhost loghost

192.9.200.70 alexroute #This is the local host name
192.9.201.10 alexroute-201 #Interface to network 192.9.201
With these two interfaces, alexroute connects networks 192.168.200 and

192.168.201 as a router.
• How Name Services Affect the hosts Database
The NIS, NIS+, and DNS name services maintain host names and addresses on
one or more servers. These servers maintain hosts databases containing
information for every host and router (if applicable) on the servers' network.
netmasks Database
You need to edit the netmasks database as part of network configuration only if you have
set up subnetting on your network. The netmasks database consists of a list of networks
and their associated subnet masks.
NOTE: When you create subnets, each new network must be a separate physical
network. You cannot apply subnetting to a single physical network.
• What is Subnetting?
Subnetting is a method for getting the most out of the limited 32-bit IP addressing
space and reducing the size of the routing tables in a large internetwork. With any
address class, subnetting provides a means of allocating a part of the host address
space to network addresses, which lets you have more networks. The part of the
host address space allocated to new network addresses is known as the subnet
number.
In addition to making more efficient use of the IP address space, subnetting has
several administrative benefits. Routing can become very complicated as the
number of networks grows. A small organization, for example, might give each
local network a class C number. As the organization grows, administering a
number of different network numbers could become complicated. A better idea is
to allocate a few class B network numbers to each major division in an
organization. For instance, you could allocate one to Engineering, one to
Operations, and so on. Then, you could divide each class B network into
additional networks, using the additional network numbers gained by subnetting.
This can also reduce the amount of routing information that must be
communicated among routers.
• Creating the Network Mask
As part of the subnetting process, you need to select a network-wide netmask. The
netmask determines how many and which bits in the host address space represent
the subnet number and how many and which represent the host number. Recall
that the complete IP address consists of 32 bits. Depending on the address class,
as many as 24 bits and as few as 8 bits can be available for representing the host
address space. The netmask is specified in the netmasks database.
If you plan to use subnets, you must determine your netmask before you configure
TCP/IP. If you plan to install the operating system as part of network
configuration, the Solaris installation program requests the netmask for your
network. 32-bit IP addresses consist of a network part and a host part. The 32 bits
are divided into 4 bytes. Each byte is assigned either to the network number or the
host number, depending on the network class.
For example, in a class B IP address, the 2 left-hand bytes are assigned to the
network number, and the 2 right-hand bytes are assigned to the host number. In
the class B IP address 129.144.41.10, you can assign the 2 right-hand bytes to
hosts.
If you are going to implement subnetting, you need to use some of the bits in the
bytes assigned to the host number to apply to subnet addresses. For example, a
16-bit host address space provides addressing for 65,534 hosts. If you apply the
third byte to subnet addresses and the fourth to host addresses, you can address up
to 254 networks, with up to 254 hosts on each.
The bits in the host address bytes that will be applied to subnet addresses and
those applied to host addresses is determined by a subnet mask. Subnet masks are
used to select bits from either byte for use as subnet addresses. Although netmask
bits must be contiguous, they need not align on byte boundaries.
The netmask can be applied to an IP address using the bitwise logical AND
operator. This operation selects out the network number and subnet number
positions of the address.
It is easiest to explain netmasks in terms of their binary representation. You can

use a calculator for binary-to-decimal conversion. The following examples show
both the decimal and binary forms of the netmask.
If a netmask 255.255.255.0 is applied to the IP address 129.144.41.101, the result

is the IP address of 129.144.41.0.
129.144.41.101 & 255.255.255.0 = 129.144.41.0
In binary form, the operation is:
10000001.10010000.00101001.01100101 (IP address)
ANDed with
11111111.11111111.11111111.00000000 (netmask)
Now the system looks for a network number of 129.144.41 instead of a network
number of 129.144. If you have a network with the number 129.144.41, that is
what the system looks for and finds. Since you can assign up to 254 values to the
third byte of the IP address space, subnetting lets you create address space for 254
networks, where previously there was room for only one.
If you want to provide address space for only two additional networks, you could
use a subnet mask of: 255.255.192.0
This netmask provides a result of:
11111111.11111111.1100000.00000000
This still leaves 14 bits available for host addresses. Since all 0s and 1s are
reserved, at least two bits must be reserved for the host number.
• Editing the /etc/inet/netmasks File
If your network runs NIS or NIS+, the servers for these name services maintain
netmasks databases. For networks that use local files for name service, this
information is maintained in the /etc/inet/netmasks file.
NOTE: For compatibility with BSD-based operating systems, the file

/etc/netmasks is a symbolic link to /etc/inet/netmasks.
## The netmasks file associates Internet Protocol (IP) address

# masks with IP network numbers.
#
# network-number netmask
#
# Both the network-number and the netmasks are specified in
# ''decimal dot'' notation, e.g:
#
# 128.32.0.0 255.255.255.0
129.144.0.0 255.255.255.0
If the file does not exist, create it. Use the following syntax: network-number
netmask-number
When creating netmask numbers, type the network number assigned by the
InterNIC (not the subnet number) and netmask number in /etc/inet/netmasks.
Each subnet mask should be on a separate line.
For example:
128.78.0.0 255.255.248.0
You can also type symbolic names for network numbers in the /etc/inet/hosts
file. You can then use these network names instead of the network numbers as
parameters to commands.
Adding a Subnet to a Network
If you are changing from a network that does not use subnets to one that is subnetted,
perform the following steps:
1. Decide on the new subnet topology, including considerations for routers and
locations of hosts on the subnets.
2. Assign all subnet and host addresses.
3. Modify the /etc/inet/netmasks file, if you are manually configuring TCP/IP, or
supply the netmask to the Solaris installation program.
4. Modify the /etc/inet/hosts files on all hosts to reflect the new host addresses.
5. Reboot all machines.
Configuring TCP/IP on Solaris - Network Databases and nsswitch.conf File
Introduction
The network databases are files that provide information needed to configure the
network. The network databases are:
• hosts
• netmasks
• ethers
• bootparams
• protocols
• services
• networks
As part of the configuration process, you edit the hosts database and the netmasks
database, if your network is subnetted. Two network databases, bootparams and ethers,
are used to configure machines as network clients. The remaining databases are used by
the operating system and seldom require editing.
Although it is not a network database, the nsswitch.conf file needs to be configured along
with the relevant network databases. nsswitch.conf specifies which name service to use
for a particular machine: NIS, NIS+, DNS, or local files.
How Name Services Affect Network Databases
Your network database takes a form that depends on the type of name service you select
for your network. For example, the hosts database contains, at minimum, the host name
and IP address of the local machine and any network interfaces directly connected to the
local machine. However, the hosts database could contain other IP addresses and host
names, depending on the type of name service on your network.
The network databases are used as follows:
• Networks that use local files for their name service rely on files in the /etc/inet
and /etc directories
• NIS+ uses databases called NIS+ tables
• NIS uses databases called NIS maps
• DNS uses records with host information
Note - DNS boot and data files do not correspond directly to the network databases.
Network Database Local Files NIS+ Tables NIS Maps

hosts.byaddr
hosts /etc/inet/hosts hosts.ord_dir
hosts.byname
netmasks /etc/inet/netmasks netmasks.ord_dir netmasks.byaddr
ethers.byname
ethers /etc/ethers ethers.ord_dir
ethers.byaddr
bootparams /etc/bootparams bootparams.ord_dir bootparams
protocols.byname
protocols /etc/inet/protocols protocols.ord_dir
protocols.bynumber
services /etc/inet/services services.ord_dir services.byname
networks.byaddr
networks /etc/inet/networks networks.ord_dir
networks.byname
nsswitch.conf File - Specifying Which Name Service to Use
The /etc/nsswitch.conf file defines the search order of the network databases. The
Solaris installation program creates a default /etc/nsswitch.conf file for the local
machine, based on the name service you indicate during the installation process. If you
selected the 'None' option, indicating local files for name service, the resulting
nsswitch.conf file resembles the following example:
nsswitch.conf for Networks Using Files for Name Service
# /etc/nsswitch.files:
#
# An example file that could be copied over to /etc/nsswitch.conf;
# it does not use any naming service.
#
# /etc/netconfig file contains "switch.so" as a
# nametoaddr library for "inet" transports.
passwd: files
group: files
hosts: files
networks: files
protocols: files
rpc: files
ethers: files
netmasks: files
bootparams: files
publickey: files
# At present there isn't a 'files' backend for netgroup; the
# system will figure it out pretty quickly,
# and won't use netgroups at all.
netgroup: files
automount: files
aliases: files
services: files
sendmailvars: files
The nsswitch.conf(4) man page describes the file in detail. Its basic syntax is:
database name-service-to-search
The database field can list one of many types of databases searched by the operating
system. For example, it could indicate a database affecting users, such as passwd or
aliases, or a network database. The parameter name-service-to-search can have the values
files, nis, or nis+ for the network databases. (The hosts database can also have dns as a
name service to search.) You can also list more than one name service, such as nis+ and
files.
In the above example, the only search option indicated is files. Therefore, the local
machine gets security and automounting information, in addition to network database
information, from files located in its /etc and /etc/inet directories.
Changing nsswitch.conf
The /etc directory contains the nsswitch.conf file created by the Solaris installation
program. It also contains template files for the following name services:
• nsswitch.files
• nsswitch.nis
• nsswitch.nis+
If you want to change from one name service to another, you can copy the appropriate
template to nsswitch.conf. You can also selectively edit the nsswitch.conf file, and change
the default name service to search for individual databases.
For example, on a network running NIS, you might have to change the nsswitch.conf
file on diskless clients. The search path for the bootparams and ethers databases must list
files as the first option, and nis. The example below shows the correct search paths.
nsswitch.conf for a Diskless Client on a Network Running NIS

## /etc/nsswitch.conf:#
.
.
passwd: files nis
group: file nis
# consult /etc "files" only if nis is down.
hosts: nis [NOTFOUND=return] files
networks: nis [NOTFOUND=return] files
protocols: nis [NOTFOUND=return] files
rpc: nis [NOTFOUND=return] files
ethers: files [NOTFOUND=return] nis
netmasks: nis [NOTFOUND=return] files
bootparams: files [NOTFOUND=return] nis
publickey: nis
netgroup: nis
automount: files nis
aliases: files nis
# for efficient getservbyname() avoid nis
services: files nis
sendmailvars: files
bootparams Database
The bootparams database contains information used by diskless clients and machines
configured to boot in the network client mode. You need to edit it if your network will
have network clients. The database is built from information entered into the
/etc/bootparams file.
The bootparams(4) man page contains complete syntax for this database. Its basic syntax
is:
machine-name file-key-server-name:pathname
For each diskless or network client machine, the entry might contain the following
information: the name of the client, a list of keys, the names of servers, and path names.
The first item of each entry is the name of the client machine. Next is a list of keys,
names of servers, and path names, separated by tab characters. All items but the first are
optional. The database can contain a wildcard entry that will be matched by all clients.
Here is an example:
bootparams Database
myclient root=myserver : /nfsroot/myclient \
swap=myserver : /nfsswap//myclient \
dump=myserver : /nfsdump/myclient
In this example the term dump=: tells diskless hosts not to look for a dump file.
Wildcard Entry for bootparams

In most cases, you will want to use the wildcard entry when editing the bootparams
database to support diskless clients. This entry is:
* root=server:/path dump=:
The asterisk (*) wildcard indicates that this entry applies to all clients not specifically
named within the bootparams database.
ethers Database
The ethers database is built from information entered into the /etc/ethers file. It
associates host names to their Ethernet addresses. You need to create an ethers database
only if you are running the RARP daemon; that is, if you are configuring network clients
or diskless machines.
RARP uses the file to map Ethernet addresses to IP addresses. If you are running the
RARP daemon in.rarpd, you need to set up the ethers file and maintain it on all hosts
running the daemon to reflect changes to the network.
The ethers(4) man page contains complete syntax information for this database. Its basic
format is:
Ethernet-address hostname #comment

Ethernet-address is the Ethernet address of the host.
hostname is the official name of the host.
#comment is any kind of note you want to append to an entry in the file.
The equipment manufacturer provides the Ethernet address. If a machine does not display
the Ethernet address when you power up, see your hardware manuals for assistance.
When adding entries to the ethers database, make sure that host names correspond to the
primary names in the hosts database, not to the nicknames, as shown in the following
example:
Entries in the ethers Database

8:0:20:1:40:16 fayoum
8:0:20:1:40:15 nubian
8:0:20:1:40:7 sahara # This is a comment
8:0:20:1:40:14 tenere
Other Network Databases
The remaining network databases seldom need to be edited.
networks database Database
The networks database associates network names with network numbers, enabling some
applications to use and display names rather than numbers. The networks database is
based on information in the /etc/inet/networks file. It contains the names of all networks
to which your network connects via routers.
The Solaris installation program sets up the initial networks database. The only time you
need to update it is when you add a new network to your existing network topology.
The networks(4) man page contains full syntax information for /etc/inet/networks. Here is
its basic format:
network-name network-number nickname(s) # comment
network-name is the official name for the network.
network-number is the number assigned by the InterNIC.
nickname is any other name by which the network is known.
#comment is any kind of note you want to append to an entry in the
file.
It is particularly important that you maintain the networks file. The netstat program uses
the information in this database to produce status tables. The example shows a sample
/etc/networks file:
/etc/networks File
#ident "@(#)networks 1.4 92/07/14 SMI" /* SVr4.0 1.1 */
#
# The networks file associates Internet Protocol (IP)
network
numbers with network names. The format of this file is:
#
# network-name network-number nicnames . . .
# The loopback network is used only for intra-machine
communication
#loopback 127
# Internet networks
#
arpanet 10 arpa # Historical
ucb-ether 46 ucbether
#
# local networks
eng 193.9.0 #engineering
acc 193.9.1 #accounting
prog 193.9.2 #programming
protocols Database
The protocols database lists the TCP/IP protocols installed on your system and their
numbers; the Solaris installation program automatically creates it. It is rare when this file
requires administrative handling.
The protocols database contains the names of the TCP/IP protocols installed on the
system. Its syntax is completely described in the protocols(4) man page. The example
below shows an example of the /etc/inet/protocols file:
/etc/inet/protocols File
#
# Internet (IP) protocols
#
ip 0 IP # internet protocol, pseudo protocol number
icmp 1 ICMP # internet control message protocol
tcp 6 TCP # transmission control protocol
udp 17 UDP # user datagram protocol
services Database
The services database lists the names of TCP and UDP services and their well known port
numbers; it is used by programs that call network services. The Solaris installation
automatically creates the services database; it generally requires no administrative
handling.
The services(4) man page contains complete syntax information. The example below
shows an excerpt from a typical /etc/inet/services file:
/etc/inet/services File
#
# Network services
#
echo 7/udp
echo 7/tcp
discard 9/udp sink null
discard 11/tcp
daytime 13/udp
daytime 13/tcp
netstat 15/tcp
ftp-data 20/tcp
ftp 21/tcp
telnet 23/tcp
time 37/tcp timeserver
time 37/udp timeserver
name 42/udp nameserver
whois 43/tcp nickname
Configuring TCP/IP on Solaris - Network Configuration Procedures
Introduction
Network software installation takes place along with the installation of the operating
system software. At that time, certain IP configuration parameters must be stored in
appropriate files so they can be read at boot time.
The procedure is simply a matter of creating or editing the network- configuration files.
How configuration information is made available to a machine's kernel depends on
whether these files are stored locally (local files mode) or acquired from the network
configuration server (network client mode). Parameters supplied during network
configuration are:
• IP address of each network interface on every machine

• Host names of each machine on the network. You can type the host name in a
local file or a name service database.
• NIS, NIS+, or DNS domain name in which the machine resides, if applicable
• Default router addresses. You supply this only if you have a simple network
topology with only one router attached to each network, or your routers don’t run
routing protocols such as the Router Discovery Server Protocol (RDISC) or the
Router Information Protocol (RIP). (See Chapter 5 for more information about
these protocols.)
• Subnet mask (required only for networks with subnets)
This section contains complete information on creating and editing local configuration
files.
How to Configure a Host for Local Files Mode
Use this procedure for configuring TCP/IP on a machine that run in local files mode.
1. Become superuser and change to the /etc directory.

2. Type the host name of the machine in the file /etc/nodename. For example, if the
name of the host is tenere, type tenere in the file.
3. Create a file named /etc/hostname.interface for each network interface. (The
Solaris installation program automatically creates this file for the primary network
interface.)
4. Type either the interface IP address or the interface name in each
/etc/hostname.interface file. For example, create a file named hostname.ie1,
and type either the IP address of the host's interface or the host's name.
5. Edit the /etc/inet/hosts file to add:
o IP addresses that you have assigned to any additional network interfaces in
the local machine, along with the corresponding host name for each
interface. The Solaris installation program will already have created
entries for the primary network interface and loopback address.
o IP address or addresses of the file server, if the /usr file system is NFS
mounted.
6. Type the host's fully qualified domain name in the /etc/defaultdomain file. For
example, suppose host tenere was part of the domain deserts.worldwide.com.
Therefore, you would type: deserts.worldwide.com in /etc/defaultdomain.
7. Type the router's name in /etc/defaultrouter.
8. Type the name of the default router and its IP addresses in /etc/inet/hosts.
Additional routing options are available. You can apply these options to a local
files mode configuration.
9. If your network is subnetted, type the network number and the netmask in the file
/etc/inet/netmasks. If you have set up a NIS or NIS+ server, you can type
netmask information in the appropriate database on the server as long as server
and clients are on the same network.
10. Reboot each machine on the network.
Setting Up a Network Configuration Server
If you plan to configure certain hosts as network clients, you must configure at least one
machine on your network as a network configuration server. (Refer to “Network
Configuration Servers” on page 45 for an introduction.) Setting up a network
configuration server involves:
1. Turning on the network configuration daemons:
- in.tftpd
- in.rarpd
- rpc.bootparamd
2. Editing and maintaining the network configuration files on the configuration
server.
How to Set Up a Network Configuration Server
1. Become superuser and change to the root directory of the prospective network
configuration server.
2. Turn on the in.tftpd daemon by creating the directory /tftpboot:
# mkdir /tftpboot
This configures the machine as a TFTP, bootparams, and RARP server.
3. Create a symbolic link to the directory.
# ln -s /tftpboot/. /tftpboot/tftpboot
4. Enable the tftp line in intetd.conf. Check that the /etc/inetd.conf entry reads:
tftp dgram udp wait root /usr/sbin/in.tftpd in.tftpd -s /tftpboot
This prevents inettftpd() from retrieving any file other than one located in
/tftpboot.
5. Edit the hosts database, and add the host names and IP addresses for every client
on the network.
6. Edit the ethers database, and create entries for every host on the network to run in
network client mode.
7. Edit the bootparams database. Use the wildcard entry or create an entry for every
host that run in network client mode.
8. Reboot the server.
Configuring Network Clients
Network clients receive their configuration information from network configuration

servers. Therefore, before you configure a host as a network client you must ensure that
at least one network configuration server is set up for the network.
How to Configure Hosts for Network Client Mode
Do the following on each host to be configured in network client mode:
1. Become superuser.
2. Check the directory for the existence of an /etc/nodename file. If one exists,
delete it.
Eliminating /etc/nodename causes the system to use the hostconfig program to

obtain the host name, domain name, and router addresses from the network
configuration server.
3. Create the file /etc/hostname.interface, if it does not exist. Make sure that the
file is empty. An empty /etc/hostname.interface file causes the system to
acquire the IP address from the network configuration server.
4. Ensure that the /etc/inet/hosts file contains only the host name and IP address
of the loopback network interface. The file should not contain the IP address and
host name for the local machine (primary network interface). EXCEPTION: For a
diskless client (a machine with an NFS-mounted root file system), type the name
and IP address of the server that provides the client's root file system (usually, but
not always, the network configuration server).
5. Check for the existence of an /etc/defaultdomain file. If one exists, delete it.
The hostconfig program sets the domain name automatically. If you want to
override the domain name set by hostconfig, type the substitute domain name in
the file /etc/defaultdomain.
6. Ensure that the search paths in the client's /etc/nsswitch.conf reflects the
name service requirements for your network.
How to Specify a Router for the Network Client
1. If you have only one router on the network and you want the network
configuration server to specify its name automatically, ensure that the network
client does not have a /etc/defaultrouter file.
2. To override the name of the default router provided by the network configuration
server:
o Create /etc/defaultrouter on the network client.
o Type the host name and IP address of the machine you have designated as
the default router.
o Add the host name and IP address of the designated default router to the
network client's /etc/inet/hosts.
3. If you have multiple routers on the network, create /etc/defaultrouter on the
network client, but leave it empty.
Creating /etc/defaultrouter and leaving it empty causes one of the two dynamic
routing protocols to run: ICMP Router Discovery protocol (RDISC), or Routing
Information Protocol (RIP). The system first runs the program in.rdisc, which looks for
routers that are running the router discovery protocol. If it finds one such router, in.rdisc
continues to run and keeps track of the routers that are running the RDISC protocol.
If the system discovers that routers are not responding to the RDISC protocol, it uses RIP
and runs the daemon in.routed to keep track of them.
After Installing a Network Client
After you have finished editing the files on each network client machine, do the
following on the network configuration server.
1. Add entries for the hosts in the ethers and hosts databases.
2. Add entries for the hosts to the bootparams database. To simplify matters, you can
type a wild card in the bootparams database in place of individual entries for each
host.
3. Reboot the server.
Configuring TCP/IP on Solaris - Configuring Standard TCP/IP Services
TCP/IP Services
Services such as telnet, ftp, and rlogin are started by the inetd daemon, which runs
automatically at boot time. Like the name service ordering specified in nsswitch.conf,
you can configure TCP/IP services in the file /etc/inetd.conf by using the inetd -t
flag.
For example, you can use inetd to log the IP addresses of all incoming TCP connections
(remote logins and telnet). To turn the logging on, kill the running inetd and type:
# /usr/sbin/inetd -t -s
The t switch turns on TCP connection-tracing in inetd. Refer to the inetd(1M) and
inetd.conf(4) man pages.
Configuring TCP/IP on Solaris - Overview of the Booting Processes
The Boot Process
The following information is provided for your reference. It is a brief overview of the
network booting processes to help you better visualize what is happening during
configuration.
Note - The names of startup scripts might change from one release to another.
1. You start the operating system on a host.

2. The kernel runs /sbin/init, as part of the booting process.
3. /sbin/init runs the /etc/rcS.d/S30rootusr.sh. startup script.
4. The script runs a number of system startup tasks, including establishing the
minimum host and network configurations for diskless and dataless operations.
/etc/rcS.d/S30rootusr.sh also mounts the /usr file system.
1. If the local database files contain the required configuration information
(host name and IP address), the script uses it.
2. If the information is not available in local host configuration files,
/etc/rcS.d/S30rootusr.sh uses RARP to acquire the host's IP address.
5. If the local files contain domain name, host name, and default router address, the
machine uses them. If the configuration information is not in local files, then the
system uses the Bootparams protocol to acquire the host name, domain name, and
default router address. Note that the required information must be available on a
network configuration server that is located on the same network as the host. This
is necessary because no internetwork communications exist at this point.
6. After /etc/rcS/S30rootusr.sh completes its tasks and several other boot
procedures have executed, /etc/rc2.d/S69inet runs. This script executes
startup tasks that must be completed before the name services (NIS, NIS+, or
DNS) can start. These tasks include configuring the IP routing and setting the
domain name.
7. At completion of the S69inet tasks, /etc/rc2.d/S71rpc runs. This script starts
the NIS, NIS+, or DNS name service.
8. After /etc/rc2.d/S71 runs, /etc/rc2.d/S72inetsvc runs. This script starts up
services that depend on the presence of the name services. S72inetsvc also starts
the daemon inetd, which manages user services such as telnet.
Routers - Routing Protocols
Introduction
The Solaris operating environment supports two routing protocols: Routing Information
Protocol (RIP) and ICMP Router Discovery (RDISC). RIP and RDISC are both standard
TCP/IP protocols.
Routing Protocols
RIP is implemented by in.routed, the routing deamon, which automatically starts when
the machine boots. When run on a router with the s option specified, in.routed fills the
kernel routing table with a route to every reachable network and advertises "reachability"
through all network interfaces.
When run on a host with the q option specified, in.routed extracts routing information
but does not advertise reachability. On hosts, routing information can be extracted in two
ways:
• Do not specify the s flag (capital "S": "Space-saving mode") and in.routed
builds a full routing table exactly as it does in a router.
• Specify the s flag and in.routed creates a minimal kernel table, containing a
single default route for each available router.
ICMP Router Discovery (RDISC) Protocol
Hosts use RDISC to obtain routing information from routers. Thus, when hosts are
running RDISC, routers must also run another protocol, such as RIP, in order to exchange
router information amoung themselves.
RDISC is implemented by in.rdisc, which should run on both routers and hosts.
Normally, when in.rdisc runs on a host, it enters a default route for each router that is
also running in.rdisc. A host that is running in.rdisc can not discover routers that are
running only RIP. Furthermore, when routers are running in.rdisc (rather than
in.routed), then can be configured to have a different preference, which causes hosts to
select a better router.
Routers - Configuring Routers
Introduction
TCP/IP's first requirement for a router is that the machine must have at least two network
interfaces installed. As long as one of the network interfaces is not disabled, the router
automatically "talks" to the RDISC and RIP protocols. These protocols keep track of
routers on the network and advertise the router to the hosts on the network.
After the router is physically installed on the network, configure it to operate in local files
mode, as described in "How to Configure a Host for Local Files Mode". This ensures that
routers will boot in case the network configuration server is down. Remember that,unlike
a host, a router has at least two interfaces to configure.
Configuring Both Router Network Interfaces
Because a router provides the interface between two or more networks, you must assign a
unique name and IP address to each of the router's network interface cards.
Thus, each router has a host name and IP address associated with its primary network
interface, plus at least one more unique name and IP address for each additional network
interface.
How to Configure a Machine as a Router
Become superuser on the machine to be configured as a router and do the following:
1. Create an /etc/hostname.interface file or each network interface installed. For

example, create hostname.ie0 and hostname.ie1.
2. Type in each file the host name you have selected for that interface. For example,
you could type the name alexprod in the file hostname.ie0, then type the name
alexprod-201 in the file hostname.ie1. Both interfaces would be located on the
same machine.
3. Type the host name and IP address of each interface into /etc/inet/hosts.
For example:
192.168.100.20 alexprod #interface for network

192.168.100
192.168.200.1 alexprod-200 #interface for network
192.168.200
192.168.200.5 gobi
192.168.200.10 mojave
192.168.200.110 saltlake
192.168.200.12 chilean
The interfaces alexprod and alexprod-200 are on the same machine. Notice that
the network address for alexprod-200 is different from that of alexprod. That is
because the medium for network 192.168.100 is connected to the alexprod-200
network interface while the media for network 192.168.200 is connected to the
alexprod interface.
How a Machine Determines if it is a Router
The /etc/rc2.d/S69inet startup script, which runs when the machine boots, determines
whether a machine is a router or a host. This decision also determines whether the routing
protocols (RIP and RDISC) should run in router mode or host mode.
Automatic Routing Protocol Selection
The startup script then must determine whether to start up a routing protocol (RIP or
RDISC) on the machine or use static routing.
To Select Static Routing on a Host
If the host is a diskless client or network client, add an entry for a router on the network
into /etc/defaultrouter. A single static default route is then installed in the routing
table. Under this condition, the host does not run any dynamic routing protocol (such as
RIP and RDISC).
To Select Dynamic Routing on a Host
To force a diskless client or network client to select a dynamic routing protocol, its
/etc/defaultrouter file should be empty. The type of dynamic routing used is selected
according to the following criteria:
• If the /usr/sbin/in.rdisc program exists, the startup script starts in.rdisc. Any
router on the network that is running RDISC then responds to any RDISC queries
from the host. If at least one router responds, the host selects RDISC as its routing
protocol.
• If the network router is not running RDISC or fails to respond to the RDISC
queries, then in.rdisc on the host exits. The host then starts in.routed, which runs
RIP.
Forcing a Machine to Be a Router
You can force a machine that has only one /etc/hostname.interface file (by default a
host) to be a router. To do so, create a file named /etc/gateways and leave it empty.
Creating a Multihomed Host
By default, TCP/IP considers any machine with multiple network interfaces to be a

router. However, you can change a router into a multihomed host—a machine with more
than one network interface that does not run routing protocols or forward IP packets. You
typically configure the following types of machines as multihomed hosts:
• NFS servers, particularly large data centers, can be attached to more than one
network in order to share files among a large pool of users. These servers don't
need to maintain routing tables.
• Database servers can have multiple network interfaces for the same reason as NFS
servers'to provide resources to a large pool of users.
• Firewall gateways are machines that provide the connection between a company's
network and public networks such as the Internet. Administrators set up firewalls
as a security measure. When configured as a firewall, the host will not pass
packets between the networks attached to it. On the other hand, it can still provide
standard TCP/IP services, such as ftp or rlogin, to authorized users.
Since TCP/IP considers any machine with multiple network interfaces to be a router, you
need to perform a few operations to turn it into a multihomed host.
How to Create a Multihomed Host
Become superuser on the prospective multihomed host and do the following:
• Create an /etc/hostname.interface file for each additional network interface

installed in the machine.
• Type:
% touch /etc/notrouter
This creates an empty file called /etc/notrouter.

• Reboot the machine. When the machine reboots, the startup script looks for the
presence of the /etc/notrouter file. If the file exists, the startup script does not
run in.routed -s or in.rdisc -r, and does not turn on IP forwarding on all
interfaces configured "up" by ifconfig. This happens regardless of whether an
/etc/gateways file exists. Thus the machine is now a multihomed host.
Turning On Space-Saving Mode
Space-saving mode provides the host with a table that contains only the default routes.
On a host, in.routed runs with space saving mode turned off by default.
If you do not want the host to have a full routing table (which provides increased
protection against misconfigured routers), turn space saving mode on. To do so, edit the
/etc/rc2.d/S69inet startup script by changing the line:
/usr/sbin/in.routed -q
to
/usr/sbin/in.routed -q -S
Turning Off ICMP Router Discovery on the Host
For reasons involving router reliability, you might not want your hosts to use RDISC. To
turn RDISC off, change the name of the host's /usr/sbin/in.rdisc to some other
name, such as /usr/sbin/in.rdisc.saved, and then reboot the host.
Turning Off ICMP Router Discovery on the Router
If the automatic selection of RIP rather than RDISC by a host is to work reliably, the
routers in the network (particularly those running RDISC) must also work reliably.
If your routers are not running RDISC and you install a single Solaris router, by default
all hosts connected to that router rely on it alone. To have the hosts on that network use
the other routers as well, turn off RDISC on the new router. To do this, change the name
of the router's /usr/bin/in.rdisc file to some other file name and reboot the router.

Step by Step Install Ti On Solaris 10

Încărcat de

Informații document

Descriere 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

Step by Step Install Ti On Solaris 10

Încărcat de

Drepturi de autor:

Formate disponibile

Installing Sun Solaris 10

by Jeff Hunter, Sr. Database Administrator

• Sun Blade 150 (UltraSPARC-IIe 650MHz), No Keyboard, OpenBoot 4.6

• Determine the host name of the system you are installing

Using Serial / Console Connection

Welcome to minicom 2.00.0

OPTIONS: History Buffer, F-key Macros, Search History Buffer, I18n

alex console login: root

Starting the Installation

If you were performing a network installation, you would type:

Answering the Screen Prompts

Sun Blade 150 (UltraSPARC-IIe 650MHz), No Keyboard

Rebooting with command: boot cdrom

Screen 1 : The Solaris Installation Program

This is the Solaris Installation Welcome screen.

Screen 2 : Identify This System

Screen 3 : Network Connectivity

Host name for eri0: alex

Screen 6 : IP Address for eri0

IP address for eri0: 192.168.1.102

Screen 7 : Subnet for eri0

System part of a subnet

Screen 8 : Netmask for eri0

Netmask for eri0: 255.255.255.0

Screen 9 : IPv6 for eri0

In this example, I will not be enabling IPv6.

Enable IPv6 for eri0

Screen 10 : Set the Default Route for eri0

Default Route for eri0

Screen 11 : Default Route IP Address for eri0

Router IP Address for eri0: 192.168.1.1

Screen 12 : Confirm Information for eri0

This is a confirmation screen. Verify all data is correct.

Host name: alex

Screen 13 : Configure Security Policy

Configure Kerberos Security

Screen 14 : Confirm Information

This is a confirmation screen. Verify all data is correct.

Configure Kerberos Security: No

Screen 16 : Domain Name

Host name: idevelopment.info

Screen 17 : DNS Server Addresses

Server's IP address: 63.67.120.23

Screen 18 : DNS Search List

Screen 19 : Confirm Information

This is a confirmation screen. Verify all data is correct.

Name service: DNS

Continents and Oceans

Screen 21 : Country or Region

Countries and Regions

Screen 22 : Time Zone

Screen 23 : Date and Time

Date and time: YYYY-MM-DD HH:MM

Screen 24 : Confirm Information

This is a confirmation screen. Verify all data is correct.

Time zone: Eastern Time

Screen 25 : Solaris Interactive Installation

Screen 26 : Eject a CD/DVD Automatically?

[X] Automatically eject CD/DVD

Screen 27 : Reboot After Installation?

[X] Auto Reboot

Screen 28 : Solaris Interactive Installation

The system is being initialized.