Академический Документы
Профессиональный Документы
Культура Документы
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:
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:
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
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.
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.
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 ...
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.
Hit F2 to continue
This screen informs you about how you will need to identify the computer as it applies to
network connectivity.
Hit F2 to continue
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".
Enter the Internet Protocol (IP) address for this network interface.
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.
Hit F2 to continue
Hit F2 to continue
Hit F2 to continue
Hit F2 to continue
Screen 15 : Name Service
Name service
------------
[ ] NIS+
[ ] NIS
[X] DNS
[ ] LDAP
[ ] None
Hit F2 to continue
Search domain:
Search domain:
Search domain:
Search domain:
Search domain:
Search domain:
Hit F2 to continue
Hit F2 to continue
Screen 20 : 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
Hit F2 to continue
There are two ways to install your Solaris software: "Standard" or "Flash". Choose the
"Standard" method (F2_Standard).
Hit F2 to continue
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.
Hit F2 to continue
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.
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
Screen 30 : License
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
To scan for additional products, select the location you wish to scan.
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
----------------------------------------------------------
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.
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.
[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
Do you want to update the system's hardware (EEPROM) to always boot from c0t0d0?
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
Do you want to use auto-layout to automatically layout file systems? Manually laying out
file systems requires advanced system administration skills.
On this screen you must select all the file systems you want auto-layout to create, or
accept the default file systems shown.
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.
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.
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
==================================================================
Solaris Initial Install
*****
| | | | | |
0 20 40 60 80 100
==================================================================
Cleaning devices
Install of CD 1 complete.
Executing SolStart postinstall phase...
Executing finish script "patch_finish"...
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.
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.
Ready to Install
1. Install Now
2. Start Over
3. Exit Installation
Please specify the media from which you will install Solaris 10
Software 3 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 3 for SPARC Platforms.
Ready to Install
1. Install Now
2. Start Over
3. Exit Installation
Please specify the media from which you will install Solaris 10
Software 4 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 4 for SPARC Platforms.
Ready to Install
1. Install Now
2. Start Over
3. Exit Installation
Please specify the media from which you will install Solaris 10
Software 5 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 5 for SPARC Platforms.
1. Install Now
2. Start Over
3. Exit Installation
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)
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
Overview
This article documents the process of downloading and installing the latest Sun Solaris 9
Patch Cluster.
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.
Contents
1. Introduction
2. SwitchView® 1000
3. AutoView® 1415
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
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 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.
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):
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".
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.
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.
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.
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:
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.
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
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.
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
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
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.
# /usr/openwin/bin/dtpower
Method #2
• 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
system-threshold always-on
# /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.
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
prtdiag
Use the following command to obtain detailed diagnostics information about your system
configuration:
# /usr/platform/`uname -i`/sbin/prtdiag -v
==================================== 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
Name Port#
------------ -----
device 4
Name Port#
------------ -----
keyboard mouse
============================ Environmental Status
============================
Fan Speeds:
----------------------------
Fan Device Speed
----------------------------
system 100%
================================ HW Revisions
================================
ASIC Revisions:
---------------
ebus: Rev 1
prtconf
Use the following command to obtain detailed system information about your Sun Solaris
installation:
# /usr/sbin/prtconf
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)
dimm (driver not attached)
dimm (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
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
# /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.
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.
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.
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.
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:
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.
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
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.
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
• 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):
# tip hardwire
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.
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
• Connecting from a Sun E250
To obtain a serial connection from a Sun E250 to another server (possibly another
Sun SPARC machine) you will need the following:
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):
# tip hardwire
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).
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.
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.
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:
Bits per second: 9600
Data bits: 8
Parity: None
Stop bits: 1
Flow Control: Hardware
• Connecting from a Sun V100
To obtain a serial connection from a Sun V100 to another server (possibly another
Sun SPARC machine) you will need the following:
o ...
o ...
o ...
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
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.
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
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 ""
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
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.
wwws.sun.com/software/whitepapers/solaris9/volume_manager.pdf
There are many uses for Volume Manager but most tasks center around the following:
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.
docs.sun.com/db/doc/806-6111
http://wwws.sun.com/software/whitepapers/solaris9/transition_volumemgr.pdf
docs.sun.com/db/coll/260.1?q=disksuite&s=t
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!
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.
Solaris Volume Manager includes a graphic user interview (GUI) named Enhanced
Storage which is part of the Solaris Management Console.
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.
Here is a screenshot of the Solaris Management Console and the Enhanced Storage Tool:
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).
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.
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
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.
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.
# metadb
# 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
A RAID 0 volume (often called just a stripe) are one of the three types of simple volumes:
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.
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,
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):
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.
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.
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:
8. Device Start Block Dbase Reloc
9. c2t1d0s7 10773 Yes Yes
10. Stripe 1:
11. Device Start Block Dbase Reloc
12. c1t2d0s7 10773 Yes Yes
13. Stripe 2:
14. Device Start Block Dbase Reloc
15. c2t2d0s7 10773 Yes Yes
16.
17.d0: Concat/Stripe
18. Size: 52999569 blocks (25 GB)
19. Stripe 0: (interlace: 64 blocks)
20. Device Start Block Dbase Reloc
21. c1t0d0s7 10773 Yes Yes
22. c2t0d0s7 10773 Yes Yes
23. c1t1d0s7 10773 Yes Yes
24.
25.Device Relocation Information:
26.Device Reloc Device ID
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:
33.# newfs -i 8192 /dev/md/rdsk/d1
34.newfs: construct a new file system /dev/md/rdsk/d1: (y/n)? y
35./dev/md/rdsk/d1: 53003160 sectors in 14760 cylinders of 27
tracks, 133 sectors
36. 25880.4MB in 923 cyl groups (16 c/g, 28.05MB/g, 3392 i/g)
37.super-block backups (for fsck -F ufs -o b=#) at:
38. 32, 57632, 115232, 172832, 230432, 288032, 345632, 403232,
460832, 518432,
39.Initializing cylinder groups:
40...................
41.super-block backups for last 10 cylinder groups at:
42. 52459808, 52517408, 52575008, 52632608, 52690208, 52747808,
52805408,
52863008, 52920608, 52978208,
45. 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):
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:
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.
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.
5. # metainit d22 1 1 c2t3d0s7
d22: Concat/Stripe is setup
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.
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:
43.# newfs -i 8192 /dev/md/rdsk/d20
44.newfs: construct a new file system /dev/md/rdsk/d20: (y/n)? y
45./dev/md/rdsk/d20: 17667720 sectors in 4920 cylinders of 27
tracks, 133 sectors
46. 8626.8MB in 308 cyl groups (16 c/g, 28.05MB/g, 3392 i/g)
47.super-block backups (for fsck -F ufs -o b=#) at:
48. 32, 57632, 115232, 172832, 230432, 288032, 345632, 403232,
460832, 518432,
49. 17123360, 17180960, 17238560, 17296160, 17353760, 17411360,
17468960,
17526560, 17584160, 17641760,
52. 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):
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.
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
d21: Concat/Stripe is setup
5. Create a second concat/stripe. (This will be submirror2)
6. # metainit d22 1 1 c2t3d0s7
d22: Concat/Stripe is setup
# 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 -
/dev/md/dsk/d20 /dev/md/rdsk/d20 /db20 ufs 2
yes -
# mount /db20
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
18. Submirror 0: d21
19. State: Okay
20. Submirror 1: d22
21. State: Resyncing
22. Resync in progress: 15 % done
23. Pass: 1
24. Read option: roundrobin (default)
25. Write option: parallel (default)
26. Size: 17470215 blocks
27.
28.d21: Submirror of d20
29. State: Okay
30. Size: 17470215 blocks
31. Stripe 0:
32. Device Start Block Dbase State Hot
Spare
33. c1t3d0s7 3591 Yes Okay
34.
35.
36.d22: Submirror of d20
37. State: Resyncing
38. Size: 17470215 blocks
39. Stripe 0:
40. Device Start Block Dbase State Hot
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.
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.
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 c0t0d0s6
d21: Concat/Stripe is setup
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 -
# reboot
14. After attaching d22 (submirror2), this triggers a mirror resync. Use the metastat
command to view the progress of the mirror resync:
15.# metastat d20
16.d20: Mirror
17. Submirror 0: d21
18. State: Okay
19. Submirror 1: d22
20. State: Resyncing
21. Resync in progress: 8 % done
22. Pass: 1
23. Read option: roundrobin (default)
24. Write option: parallel (default)
25. Size: 16781040 blocks
26.
27.d21: Submirror of d20
28. State: Okay
29. Size: 16781040 blocks
30. Stripe 0:
31. Device Start Block Dbase State Hot
Spare
32. c0t0d0s6 0 No Okay
33.
34.
35.d22: Submirror of d20
36. State: Resyncing
37. Size: 17470215 blocks
38. Stripe 0:
39. Device Start Block Dbase State Hot
Spare
c2t3d0s7 3591 Yes Okay
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-
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 c0t0d0s3
d21: Concat/Stripe is setup
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
14. After attaching d22 (submirror2), this triggers a mirror resync. Use the metastat
command to view the progress of the mirror resync:
15.# metastat d20
16.d20: Mirror
17. Submirror 0: d21
18. State: Okay
19. Submirror 1: d22
20. State: Resyncing
21. Resync in progress: 32 % done
22. Pass: 1
23. Read option: roundrobin (default)
24. Write option: parallel (default)
25. Size: 2101200 blocks
26.
27.d21: Submirror of d20
28. State: Okay
29. Size: 2101200 blocks
30. Stripe 0:
31. Device Start Block Dbase State Hot
Spare
32. c0t0d0s3 0 No Okay
33.
34.
35.d22: Submirror of d20
36. State: Resyncing
37. Size: 17470215 blocks
38. Stripe 0:
39. Device Start Block Dbase State Hot
Spare
c2t3d0s7 3591 Yes Okay
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.
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:
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
# lockfs -fa
# reboot
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.
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 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.
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
14. c2t4d0s7 11103 Yes Initializing Yes
15. c1t5d0s7 11103 Yes Initializing Yes
16.
17.Device Relocation Information:
18.Device Reloc Device ID
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
c2t4d0s7 11103 Yes Okay Yes
c1t5d0s7 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:
22.# newfs -i 8192 /dev/md/rdsk/d3
23.newfs: construct a new file system /dev/md/rdsk/d3: (y/n)? y
24.Warning: 1 sector(s) in last cylinder unallocated
25./dev/md/rdsk/d3: 35331848 sectors in 9839 cylinders of 27
tracks, 133 sectors
26. 17251.9MB in 615 cyl groups (16 c/g, 28.05MB/g, 3392 i/g)
27.super-block backups (for fsck -F ufs -o b=#) at:
28. 32, 57632, 115232, 172832, 230432, 288032, 345632, 403232,
460832, 518432,
29.Initializing cylinder groups:
30.............
31.super-block backups for last 10 cylinder groups at:
32. 34765088, 34822688, 34880288, 34933280, 34990880, 35048480,
35106080,
35163680, 35221280, 35278880,
35. 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):
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 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
# 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:
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!
# umount /db0
2. Next, remove the entry you made to the /etc/vfstab file for automatically
mounting the /dev/md/dsk/d0 volume:
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
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
2. Next, remove the entry you made to the /etc/vfstab file for automatically
mounting the /dev/md/dsk/d1 volume:
3. Now remove the directory (/db1) that was used to mount the file system:
# rmdir /db1
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
metastat: alex: d1: unit not set up
This section will contain the following four examples for unmirroring / removing mirrors:
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
12. Read option: roundrobin (default)
13. Write option: parallel (default)
14. Size: 17470215 blocks
15.
16.d21: Submirror of d20
17. State: Okay
18. Size: 17470215 blocks
19. Stripe 0:
20. Device Start Block Dbase State Hot
Spare
21. c1t3d0s7 3591 Yes Okay
22.
23.
24.d22: Submirror of d20
25. State: Okay
26. Size: 17470215 blocks
27. Stripe 0:
28. Device Start Block Dbase State Hot
Spare
c2t3d0s7 3591 Yes Okay
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.
33.# metadetach d20 d21
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
d21: Concat/Stripe is cleared
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.
47.metastat: alex: d21: unit not set up
48.
metastat: alex: d22: unit not set up
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
9. Read option: roundrobin (default)
10. Write option: parallel (default)
11. Size: 16781040 blocks
12.
13.d21: Submirror of d20
14. State: Okay
15. Size: 16781040 blocks
16. Stripe 0:
17. Device Start Block Dbase State Hot
Spare
18. c0t0d0s6 0 No Okay
19.
20.
21.d22: Submirror of d20
22. State: Okay
23. Size: 17470215 blocks
24. Stripe 0:
25. Device Start Block Dbase State Hot
Spare
c2t3d0s7 3591 Yes Okay
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:
27.# metadetach d20 d22
d20: submirror d22 is detached
28. 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/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
33.d20: Mirror is cleared
34.d21: Concat/Stripe is cleared
35.
36.# metaclear d22
d22: Concat/Stripe is cleared
37. You can now use the metastat command to verify that the mirrored and
contactenated volume were removed:
38.# metastat d20 d21 d22
39.metastat: alex: d20: unit not set up
40.
41.metastat: alex: d21: unit not set up
42.
metastat: alex: d22: unit not set up
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.
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
9. Read option: roundrobin (default)
10. Write option: parallel (default)
11. Size: 2101200 blocks
12.
13.d21: Submirror of d20
14. State: Okay
15. Size: 2101200 blocks
16. Stripe 0:
17. Device Start Block Dbase State Hot
Spare
18. c0t0d0s3 0 No Okay
19.
20.
21.d22: Submirror of d20
22. State: Okay
23. Size: 17470215 blocks
24. Stripe 0:
25. Device Start Block Dbase State Hot
Spare
c2t3d0s7 3591 Yes Okay
26. Next, run the metadetach command on the mirror that contains the swap file
system. In this case, I will detach d22 to make a one-way mirror:
27.# metadetach d20 d22
d20: submirror d22 is detached
28. 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/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
34. To remove the mirror volume and submirrors, use the metaclear command as
follows:
35.# metaclear -r d20
36.d20: Mirror is cleared
37.d21: Concat/Stripe is cleared
38.
39.# metaclear d22
d22: Concat/Stripe is cleared
40. You can now use the metastat command to verify that the mirrored and
contactenated volume were removed:
41.# metastat d20 d21 d22
42.metastat: alex: d20: unit not set up
43.
44.metastat: alex: d21: unit not set up
45.
metastat: alex: d22: unit not set up
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.
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
9. Read option: roundrobin (default)
10. Write option: parallel (default)
11. Size: 4198320 blocks
12.
13.d21: Submirror of d20
14. State: Okay
15. Size: 4198320 blocks
16. Stripe 0:
17. Device Start Block Dbase State Hot
Spare
18. c0t0d0s0 0 No Okay
19.
20.
21.d22: Submirror of d20
22. State: Okay
23. Size: 10489680 blocks
24. Stripe 0:
25. Device Start Block Dbase State Hot
Spare
c0t2d0s0 0 No Okay
26. Next, run the metadetach command on the mirror that contains the root file
system. In this case, I will detach d22 to make a one-way mirror:
27.# metadetach d20 d22
d20: submirror d22 is detached
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
30. To remove the mirror volume and submirrors, use the metaclear command as
follows:
31.# metaclear -r d20
32.d20: Mirror is cleared
33.d21: Concat/Stripe is cleared
34.
35.# metaclear d22
d22: Concat/Stripe is cleared
36. You can now use the metastat command to verify that the mirrored and
contactenated volume were removed:
37.# metastat d20 d21 d22
38.metastat: alex: d20: unit not set up
39.
40.metastat: alex: d21: unit not set up
41.
metastat: alex: d22: unit not set up
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
2. Next, remove the entry you made to the /etc/vfstab file for automatically
mounting the /dev/md/dsk/d0 volume:
3. Now remove the directory (/db3) that was used to mount the file system:
# 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
metastat: alex: d3: unit not set up
Removing a Hot Spare
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.
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
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.
The following items should be included with your host adapter package:
Attach the wrist strap between your wrist and a metal part of the system chassis.
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.
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
Connect the SCSI cable to your newly installed SCSI host adapter and then to the
SCSI peripheral(s).
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.
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).
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.
# su
# /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.
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 -
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
selecting c0t0d0
[disk formatted, no defect list found]
Warning: Current Disk has mounted partitions.
format> verify
format> disk
format> verify
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
Part Tag Flag Cylinders Size Blocks
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
/dev/dsk/c0t0d0s3 swap
/dev/dsk/c0t0d0s0 / ufs
/dev/dsk/c0t0d0s5 /usr ufs
/dev/dsk/c0t0d0s1 /var ufs
/dev/dsk/c0t0d0s4 /opt ufs
/dev/dsk/c0t0d0s6 /db ufs
swap /tmp tmpfs
Volume name = < >
ascii name = <ST320011A cyl 38790 alt 2 hd 16 sec 63>
pcyl = 38792
ncyl = 38790
acyl = 2
nhead = 16
nsect = 63
Part Tag Flag Cylinders Size Blocks
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
/dev/dsk/c0t0d0s3 swap
/dev/dsk/c0t0d0s0 / ufs
/dev/dsk/c0t0d0s5 /usr ufs
/dev/dsk/c0t0d0s1 /var ufs
/dev/dsk/c0t0d0s4 /opt ufs
/dev/dsk/c0t0d0s6 /db ufs
swap /tmp tmpfs
/dev/dsk/c0t2d0s7 /image ufs
Disk 1
Disk 2
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
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.
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.
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:
fsck Process
by Jeff Hunter, Sr. Database Administrator
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.
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:
/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.
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.
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.
# 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
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
Truss examples
# truss -rall -wall -f -p <PID>
# truss -rall -wall lsnrctl start
# truss -aef lsnrctl dbsnmp_start
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
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
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.
#
# "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
# 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
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.
#
# "hosts:" and "services:" in this file are used only if the
# /etc/netconfig file has a "-" for nametoaddr_libs of "inet"
transports.
# the following two lines obviate the "+" entry in /etc/passwd and
/etc/group.
passwd: files nis
group: files nis
netgroup: nis
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:
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:
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.
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:
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 are the machines that supply the TCP/IP configuration
information to hosts configured in network client mode. These server support three
booting protocols:
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.
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.
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 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.
/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.
The /etc/inet/hosts file uses this basic syntax: (Refer to the hosts(4) man page
for complete syntax information.)
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.
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 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.
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.
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
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.
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.
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.
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.
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.
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.
• 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.
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.
#
# "hosts:" and "services:" in this file are used only if the
# /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.
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.
* 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:
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:
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
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:
This section contains complete information on creating and editing local configuration
files.
Use this procedure for configuring TCP/IP on a machine that run in local files mode.
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.
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
# ln -s /tftpboot/. /tftpboot/tftpboot
4. Enable the tftp line in intetd.conf. Check that the /etc/inetd.conf entry reads:
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.
1. Become superuser.
2. Check the directory for the existence of an /etc/nodename file. If one exists,
delete it.
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.
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 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.
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.
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.
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.
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.
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.
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.
For example:
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.
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.
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 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.
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.
• 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.
% touch /etc/notrouter
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
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.
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.