Solaris 8 Administrator's Guide

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Sun's marketing slogans have long focused around a single, underlying concept: "The network is the computer." Far from being the typical marketing hype that surrounds all operating system releases, this slogan succinctly describes what Sun—and its flagship operating system SunOS—is all about. Although SunOS is a Unix operating system, it is part of a complete operating environment, known as Solaris. Thus, the core operating system is distinguished from the surrounding environment. If you just want a Unix operating system, SunOS is the most popular, since it takes advantage of current System V standards (even though it was originally built from BSD).

However, if you want a complete operating environment that is specifically designed to support network services, then Solaris provides many different applications and services toward this goal. Indeed, the vision associated with Solaris systems is not of a single host operating alone, but of many hosts working together to provide high-availability, high-performance distributed services. This is not a new vision: Sun engineers have developed the very core of what is considered the standard network in services and protocols, from RPC and NFS at the system level to Java at the development level.

SunOS is always designed, modified, and updated to suit the hardware Sun manufactures, rather than a base to which other hardware vendors try and adapt their hardware. This creates a coherence that is missing in operating systems not designed with specific hardware devices in mind.

While other operating-system vendors have oscillated between consumer and enterprise releases, Sun has focused on developing a system that is exactly the same for desktop systems as it is for enterprise systems: scalability depends only on hardware with Solaris, not on the operating system. This means that administrators, developers, and users can seamlessly move between a $1,000 Sun Ray, and a $1,000,000 E10000, and work with exactly the same user interface and toolset.

For an integrated plan of how Solaris services are usually deployed, Sun has developed the Sun ONE (Open Network Environment) specification (

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

For an integrated plan of how Solaris services are usually deployed, Sun has developed the Sun ONE (Open Network Environment) specification (http://www.sun.com/software/sunone/). This specifies the framework of the typical layers involved in providing enterprise-level network services. These layers are displayed in Figure 1-1. The basic topology is client/server: a client makes a request for a service or data, which is then passed through a frontend system, then through a layer consisting of application servers and containers, which in turn are integrated with backend systems (possibly legacy systems) by middleware. The service or data is then provided back to the client, returning along the same chain as the request in the opposite direction. Underlying these operations are distributed user and resource management, supported by SunOS. An additional layer not associated with transactions in real time, but which ultimately supports these services, is development. So, Solaris services can be roughly divided into development and deployment services.

Figure 1-1: Sun ONE network architecture

Although ONE, as described by Sun, is illustrated with the Sun's products (such as the iPlanet service range), one advantage of having an open architecture is that other vendors' products can be substituted. For example, while the iPlanet Application Server and iPlanet Web Server are excellent products, a company that develops e-commerce applications using Borland's JBuilder product may well want to take advantage of the integration features of JBuilder with the Borland Application Server, and VisiBroker for Java CORBA server. Alternatively, iPlanet's unified user-management system could be replaced with a Kerberos product that provides distributed authentication. Choosing a vendor for a specific layer, such as application services, shouldn't mean having to use only the products provided by the operating-system vendor, because secret API calls and proprietary technology available only to developers who work for the operating-system vendor prohibit third-party integration. With Sun's open architecture, third-party products can always be substituted for Sun's own.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Apart from major changes that occurred to the SunOS platform between releases 4.x and 5.x, which concerned conversion of many services from BSD to System V, the underlying platform has remained consistent. For example, shell scripts that were written 10 years ago still operate as expected, and applications that have been written for an earlier operating system release often work without modification on the new release. Stability may be seen as boring and unexciting by the feature-bloat crowd, but in projects where timelines are often 10 years or longer, factoring in an unknown number of operating system changes along the way entails a high level of risk. Appreciating that the foundation of your e-commerce system will still be stable in 10 years is very reassuring for managers and company directors, as well as developers.

Solaris has introduced many new features over the years, but these have typically been introduced as extra levels of service, rather than a complete change in platform every few weeks. One of the problems with evolving operating systems such as Linux is that there can be a large number of incompatibilities between different minor releases of the kernel that can lead to unexpected failure. A kernel upgrade that introduces a new feature may well interfere with, or invalidate, an existing feature used elsewhere. Stability is essential when, as we've seen in Figure 1-1, your entire e-commerce strategy relies upon the operating system.

Some of the new features included with Solaris 8, which were not present in previous releases, are:

Automatic disaster recovery	Kernel-level packet filtering
C2 security compliance

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

One of the best features of the SunOS operating system is the wealth of high-quality system and user documentation that is supplied. Manpages are available online for shell-based consultation, while the following HTML and PDF manuals are available through the AnswerBook:

Binary compatibility guide	Power management user guide
CDE user guide	64-bit developer's guide
CDE transition guide	Source compatibility guide
Device drivers guide	SPARC assembly language guide
Internationalization guide	STREAMS guide
JumpStart guide	SunShield security guide
Mail server guide	System administration guides

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The basis of providing modern network services rests with TCP/IP and the Internet. In this chapter,you'll learn fundamental networking principles, such as the structure of IP addresses, hostname and address resolution, and practical architectures for building Solaris networks. I examine how network interface devices are supported by Solaris, and review the installation and configuration of basic TCP/IP network services (including the Internet services daemon, inetd ). I'll demonstrate the basic principles of the Transmission Control Protocol (TCP) and related protocols by examining the contents of actual packets being transferred between Solaris hosts.

Before I begin designing networks, I need to consider individual hosts and their characteristics. A bad network design often results from an unplanned expansion of hosts that grows over the years to consume a Class C or Class B subnet, with little apparent direction. Understanding what hostnames, domain names, naming services, and IP addresses are will assist in better managment of the long-term growth of your network.

A host is an individual system running Solaris. It must be uniquely identified on the network on which it resides, which in turn uniquely identifies it on the Internet, since each Internet domain name is unique. Thus, while there may be many hosts called foxy in networks worldwide, there will be only one host called foxy allowed in each domain. This prevents foxy.savetheanimals.com from being confused with foxy.huntingholidays.com. It also prevents foxy.admin.huntingholidays.com from being confused with foxy.com, foxy.huntingholidays.com and foxy.fashion.huntingholidays.com. A hostname plus a domain name is known as a host's fully qualified domain name, since it makes no assumptions about a system's location on the Internet.

An Ethernet (MAC) address is set in a system's hardware, and uniquely identifies each network interface attached to a host. It consists of hexadecimal numbers separated by colons (e.g.,

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Before I begin designing networks, I need to consider individual hosts and their characteristics. A bad network design often results from an unplanned expansion of hosts that grows over the years to consume a Class C or Class B subnet, with little apparent direction. Understanding what hostnames, domain names, naming services, and IP addresses are will assist in better managment of the long-term growth of your network.

A host is an individual system running Solaris. It must be uniquely identified on the network on which it resides, which in turn uniquely identifies it on the Internet, since each Internet domain name is unique. Thus, while there may be many hosts called foxy in networks worldwide, there will be only one host called foxy allowed in each domain. This prevents foxy.savetheanimals.com from being confused with foxy.huntingholidays.com. It also prevents foxy.admin.huntingholidays.com from being confused with foxy.com, foxy.huntingholidays.com and foxy.fashion.huntingholidays.com. A hostname plus a domain name is known as a host's fully qualified domain name, since it makes no assumptions about a system's location on the Internet.

An Ethernet (MAC) address is set in a system's hardware, and uniquely identifies each network interface attached to a host. It consists of hexadecimal numbers separated by colons (e.g., 0:50:ba:13:8:18). Applications often use MAC addresses to identify licensed interfaces on which they can operate. In such an instance, the MAC address must be supplied to the vendor so that a license key for a specific network interface can be generated. For example, a web server license might be applied to only one interface, with the second interface being connected to an internal network (such as a router). Thus, only the MAC address of the external interface needs to be supplied to the vendor.

In addition to a MAC address, each network interface must have its own IP address so that it can be addressed individually on the network. You may ask why an IP address is necessary if each interface already has a unique MAC address. The answer is, subnets need to be addressed using a common system for distinguishing local from nonlocal addresses. Because the Ethernet address is set in hardware, there's no way to determine whether an interface is local or remote to the subnet just by looking at the MAC address.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Let's examine how Solaris networks are designed and configured. I'll start by examining the simplest possible case—a single host that is not connected to any local network. Although not many Solaris hosts are configured this way, some dedicated workstation systems do not require networking, particularly for home use. Non-networked hosts may be connected to the Internet using a traditional (dial-up) modem.

If two local hosts need to communicate using a network, the first step is to connect the two hosts together by using a crossover cable. This creates a simple network without the need for additional hardware. This configuration is often used where a single server has a single remote terminal.

In order to support more than two hosts on your network, you'll need a hub or a switch (at the least). The hub takes care of all interconnections and cabling required to form a simple star-topology network: all hosts connect through the hub to locate their appropriate targets. Note that hubs and switches can often be "piggy-backed," so that one switch connects to a second switch on an auxiliary port, which in turn might be connected to another switch or hub. In this way, an entire subnet can be set up. However, it's worth keeping in mind that there should be only three hops between a router and its most distant hub; otherwise, packets might be lost through collisions.

A set of interconnected hubs and switches is sufficient to create a single subnet, on which members of the network can send and receive broadcasts. However, once network configurations begin to extend beyond the local area, additional subnets must often be constructed; these subnets might reflect either physical constraints or organizational structures. For example, a college campus with several buildings might have a different subnet associated with each building. Alternatively, a single building might have several subnets, each associated with individual departments (Administration, Finance, Human Resources, etc.). A further reason to create subnets is security: while all kinds of data are broadcast freely around individual subnets, such data can be kept from prying eyes by partitioning subnets appropriately. A firewall can also be used to explicitly filter certain types of data that are exchanged between subnets.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Many networks are connected to the Internet, or use the Internet Protocol (IP) and higher-level protocols such as TCP/IP to communicate. In this section, I'll review what each protocol is used for, with respect to the Open Systems Interconnect Network Model (OSI), which defines seven layers of networking. Administered by the International Standards Organization (ISO), the OSI model is the foundation from which TCP/IP is built. If you understand the concepts underlying OSI, you'll easily be able to understand the relationship between the various components of TCP/IP.

The OSI model is shown in Figure 2-6. The top layer of the OSI model is the Application Layer. Unsurprisingly, applications that make use of networking lie within the Application Layer. Next is the Presentation Layer, which acts as a backplane for all applications, ensuring that network data is presented in a consistent way. Underlying presentation is the Session Layer, which ensures that individual applications are logically partitioned by sessions (imagine if data between applications was confused!). The Transport Layer is responsible for implementing the underlying protocols for data transmission, and must consider data authenticity and whether or not data packets are guaranteed to arrive. The Network Layer is responsible for connection management; essentially, connecting applications using a specific kind of transport to the Data Link Layer, which is responsible for transmission of data at the lowest level. Finally, the Physical Layer represents the actual physical implementation of bits and bytes data transfer across the network.

Figure 2-6: OSI networking model

TCP/IP layers map directly onto OSI layers. All user applications and clients that use the network lie in the Application Layer, using streams and messages to implement network functions. The Presentation Layer is implemented by standardized network data formats, such as eXternal Data Representations (XDR). The Session Layer is implemented in terms of ports and sockets, while the Transmission Control Protocol (TCP), which guarantees packet delivery, and the User Datagram Protocol (UDP), which does not make any such guarantees, comprise the Transport Layer. The Network Layer is implemented by the IP. The Data Link Layer and Physical Layer are intimately connected to the underlying physical hardware used for networking (interface cards, cables, and hubs).

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Most Solaris services run as daemons, or self-contained agents that accept client requests. However, daemons can be configured to run standalone or by using the Internet services daemon (inetd). Using inetdas a launching pad for daemons has a number of advantages: only two configuration files (/etc/inetd.conf and /etc/services ) are required to operate all inetd-enabled daemons, and key actions, such as logging, can be centralized through a single service. This ensures uniformity across inetd-enabled daemons, while standalone daemons have far fewer restrictions on their activities and configuration. For some situations, this is advantageous. For example, Apache can be run through inetd or as a standalone product; the standalone configuration gives more control over issues such as multithreading and the use of lightweight processes. Daemons run through inetd can use either TCP or UDP transport layers, or both.

Using inetd is not without disadvantages: since all services are centralized through a single daemon, all services will be lost if inetd comes under external attack or has a (yet undiscovered) bug.

Many traditional Unix services run through inetd, including ftp, telnet, rsh, rlogin, rexec, finger, talk, and UUCP. New daemons designed along the same lines will probably run best through inetd, including the new Kerberos 5 daemons.

As previously mentioned, inetd makes use of two separate configuration files: /etc/inetd.conf is the actual configuration file for the inetddaemon, listing all of the supported services and their runtime parameters; /etc/services registers all available service numbers to service names, making it easy to work with inetd. It is consulted by applications that use the getprotobyname( ) function to retrieve a protocol name. When new services are added or deleted from /etc/inetd.conf, enable changes by sending a HUP signal to the inetd process. This results in inetd restarting and reprocessing inetd.conf.

bash-2.03# kill -HUP `pgrep inetd`

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

If you're still unsure about how data is transmitted, then you need snoop. The snoop command "eavesdrops" on all packets being passed around the local subnet, including broadcasts, as well as point-to-point connections, using TCP, UDP, RPC, and many other protocols and services. This makes snoop a very valuable troubleshooting tool, since it is able to determine whether or not packets are being transferred between hosts, using specific protocols as anticipated. If the patterns of network traffic are as expected, then any application errors due to network problems can be ruled out. Alternatively, when testing a packet filtering firewall, it's important to use snoop to determine whether certain types of traffic are being allowed through the firewall that shouldn't be.

Most useful networking tools on Solaris can be used with malicious intent; snoop is no exception. Since it operates by placing the network interface into promiscuous mode, even the contents of packets can be intercepted and displayed on screen, or captured to file for later analysis. This means that a user running snoop can easily intercept usernames and passwords being transmitted around the network. The good news is snoop can be executed only by the root user; the bad news is if a cracker gains root access on only one local system, that user can then intercept all packets from hosts she has not cracked. This monitoring may eventually lead to more root passwords being intercepted. Indeed, scripts can be written that pick up key text in packets, such as "su root," and then extract the password subsequently entered.

The default mode of snoop prints out a summary of all traffic on the local network.

# snoop 
Using device /dev/eri (promiscuous mode)
      hurley -> austin           TELNET C port=1025
      austin -> hurley           TELNET R port=1025 Using device /dev/eri
      hurley -> austin           TELNET C port=1025
      austin -> hurley           TELNET R port=1025 hurley -> austin
      hurley -> austin           TELNET C port=1025
      austin -> hurley           TELNET R port=1025 austin -> hurley
      hurley -> austin           TELNET C port=1025

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

This chapter covers the step-by-step installation and selection of basic network configuration parameters, for both Solaris Intel and Solaris SPARC. Solaris has three methods of installation: command-line (text-based), interactive (menu-based), and Web Start (Java-based); I'll walk you through the latter. In addition, I'll describe the pre-installation and planning tasks necessary to select the correct networking parameters. You'll also learn about common errors made when installing Solaris, and strategies for troubleshooting Solaris installations.

Installing a Solaris system is not as easy as ringing up your local computer retailer and ordering a desktop PC running Windows Me (or similar). A Solaris system is not typically used as a desktop PC; instead, installing a Solaris system is more fairly compared to selecting a PC server running Windows 2000, which may be responsible for managing hundreds of users' files or dozens of different services. In that case, a PC guru would no doubt spend a considerable amount of time investigating various motherboard architectures and CPU types, as well as key hardware peripherals, such as SCSI cards that may manage RAID controllers, and other complex devices.

Whether or not you are installing Solaris SPARC or Intel, selecting the appropriate hardware is an important issue that needs to be resolved before installation commences. In Chapter 8, we discuss methods for sizing storage requirements for Solaris servers. However, storage is only one side of the equation: Solaris systems that need to support numerical simulations may have strong requirements for CPU speed, rather than a lot of disk space. Alternatively, purchasing the fastest possible disks at the expense of faster CPUs may optimize a database system that uses raw partitions to store data. In a perfect world, trade-offs of this kind are unnecessary but, where cost becomes an issue—and it usually is for server installations—being able to justify a specific configuration to a budget committee can be a useful skill!

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Installing a Solaris system is not as easy as ringing up your local computer retailer and ordering a desktop PC running Windows Me (or similar). A Solaris system is not typically used as a desktop PC; instead, installing a Solaris system is more fairly compared to selecting a PC server running Windows 2000, which may be responsible for managing hundreds of users' files or dozens of different services. In that case, a PC guru would no doubt spend a considerable amount of time investigating various motherboard architectures and CPU types, as well as key hardware peripherals, such as SCSI cards that may manage RAID controllers, and other complex devices.

Whether or not you are installing Solaris SPARC or Intel, selecting the appropriate hardware is an important issue that needs to be resolved before installation commences. In Chapter 8, we discuss methods for sizing storage requirements for Solaris servers. However, storage is only one side of the equation: Solaris systems that need to support numerical simulations may have strong requirements for CPU speed, rather than a lot of disk space. Alternatively, purchasing the fastest possible disks at the expense of faster CPUs may optimize a database system that uses raw partitions to store data. In a perfect world, trade-offs of this kind are unnecessary but, where cost becomes an issue—and it usually is for server installations—being able to justify a specific configuration to a budget committee can be a useful skill!

Later in this chapter, we'll look at some specific hardware configurations for SPARC- and Intel-based systems that are supported under the current release of Solaris. Unlike a lot of PC hardware, Sun systems tend to have quite long life spans, with some systems approaching the 10-year mark still being supported by the current operating environment release.

When planning a system installation, it's a good idea to use three worksheets, which combine to specify the system to be built:

A Host Configuration worksheet, which defines all of the appropriate host and network configuration details, including the hostname, IP address, domain name, DNS server address, and subnet mask.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Traditionally, SunOS was designed to work with the Scalable Processor Architecture (SPARC) processors, which are manufactured by Sun and other leading electronics manufacturers, such as Fujitsu (http://www.fujitsu.com/) and T.Sqware (http://www.tsqware.com/). In addition, a number of other companies develop peripheral boards and other SPARC-compatible appliances, particularly those that are compatible with the SBus (as opposed to the PCI bus). These companies include Seagate (http://www.seagate.com/), Hitachi (http://www.hitachi.com/), and Kingston Technology (http://www.kingston.com/). Sun does not control the standards to which their CPUs conform; instead, this responsibility lies with the SPARC member organization (http://www.sparc.org/). The standards to which SPARC systems must conform can be found at http://www.sparc.org/standards.html.

SunOS is dissimilar to other operating systems in the sense that the same operating system release runs equally well on low-end and high-end systems. Compatibility is assured across a wide range of systems that differ in bus type, CPU speed, memory size, disk type, and related properties. Even different versions of SunOS tend to be compatible with each other, although major changes occurred during the transition from SunOS 4 to SunOS 5.

In the past, SPARC systems tended to prioritize bus speeds and throughput at the expense of CPU speed. For example, a SPARC 10/51 has a 51 MHz processor, which may seem puny by today's PC standards. However, combining a fast bus with an integrated SCSI chain of fast disks and optimizing I/O performance, even SPARC servers from previous generations are able to sustain long periods of uptime compared to less solidly constructed PCs.

The current release of SunOS 5.8 supports the following SPARC systems:

Blade 100
Blade 1000
Sun Ray 100
Sun Ray 150

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Although Solaris was originally designed for SPARC systems, the immense popularity of Intel-based systems no doubt influenced Sun's decision to expand the supported hardware to include PC systems. This expansion has introduced Solaris to a whole new audience of former Microsoft Windows and Linux administrators who have upgraded their systems to use Solaris.

In terms of software installation, the two different hardware platforms actually have their own separate pre-installation sequences. However, the installation method used (e.g., Web Start Wizards) remains consistent across the two platforms. Thus, experienced SPARC installers can leverage their knowledge of existing installation techniques when installing Solaris Intel, even if they must first learn how to use the Configuration Assistant.

A wide range of PC devices are supported under Solaris. Primarily, Sun and hardware vendors supply device drivers and modules to support these devices, although it is possible to write your own. (This process has been made easier because of the availability of source code for Solaris.) In addition, device drivers for Linux can often be rewritten for Solaris Intel with a few modifications.

In order to build a new system, it's wise to consult the Hardware Compatibility List (HCL), which you can download from http://soldc.sun.com/support/drivers/hcl/index.html. The HCL lists all the different device groups supported by Solaris Intel and describes the individual devices supported within each group.

Not every device that will work with Solaris is listed in the HCL, since many generic brands and compatible versions are interoperable with named brands. For example, many network cards are "NE2000 compatible," even if they are not genuine NE2000 cards. Some other devices may be supported, but in a limited way. For example, if your video card supports resolutions of 1024x768 under Microsoft Windows, it may support only lower resolutions under Solaris Intel (e.g., 800x600). In addition, if your video card is not supported, it is possible to install the XFree86 X server (

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

To install Solaris SPARC, power on the system and press STOP+a after the boot messages have appeared. Alternatively, if your system is already operating at a specific run level, you can use the following command to bring it down to the boot PROM monitor:

# sync; init 0

At this point, insert the Web Start installation CD into the CD-ROM drive and type the following command:

ok boot cdrom

The kernel will load using a reconfiguration boot:

Boot device: /sbus/espdma@e,8400000/esp@e,8800000/sd@6,0:f File and args:
SunOS Release 5.8 Version Generic 32-bit
Copyright 1983-2000 Sun Microsystems, Inc. All rights reserved.
Configuring /dev and /devices
Using RPC Bootparams for network configuration information.
Solaris Web Start 3.0 installer
English has been selected as the language in which to perform the install.
Starting the Web Start 3.0 Solaris installer
Solaris installer is searching the system's hard disks for a
location to place the Solaris installer software.
Your system appears to be upgradeable.
Do you want to do a Initial Install or Upgrade?
1) Initial Install
2) Upgrade
Please Enter 1 or 2 >

If your system can be upgraded and you wish to retain data on existing filesystems, select 2. However, if you prefer to install with a clean slate, you may perform an initial install. In this case, you will need to back up any data you want to restore to the newly installed system, since all current data will be overwritten. Note that the option to perform an upgrade will appear only if the system is, in fact, upgradable.

To perform an initial install, simply enter 1. After pressing Enter, the following message is displayed:

The default root disk is /dev/dsk/c1t0d0.
The Solaris installer needs to format
/dev/dsk/c1t0d0 to install Solaris.
WARNING: ALL INFORMATION ON THE DISK WILL BE ERASED!
Do you want to format /dev/dsk/c1t0d0? [y,n,?,q]

At this point, you must confirm that you really do wish to install a new version of Solaris, acknowledging that the contents of the boot disk (in this case,

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

In this section, we'll review how to use the Device Configuration Assistant and related applications to prepare an Intel system for use with Solaris. After assembling the system to be installed, it should be powered up and the installation CD inserted into the CD-ROM drive. Before you can proceed, you system BIOS may need to be adjusted to allow for booting from the CD-ROM in preference to the hard disk, particularly if another operating system is already installed on the hard disk. Obviously, this setting will need to be reverted after installation has been completed, so that booting can proceed from the hard disk as normal.

After the system has powered up, and the CD-ROM drive has been accessed, the system will begin booting, as shown in the following output:

SunOS Secondary Boot version 3.00
Solaris Intel Platform Edition Booting System
Running Configuration Assistant...

At this point, the Device Configuration Assistant (DCA) will initialize. The DCA is responsible scanning the system bus to determine the bus type and the configuration of installed peripheral devices. Once the scan is complete, all detected devices are listed on the screen:

     ISA: Floppy disk controller
     ISA: IDE controller
     ISA: IDE controller
     ISA: Motherboard
     ISA: PS/2 Mouse
     ISA: PnP bios: 16550-compatible serial controller
     ISA: PnP bios: 8514-compatible display controller
     ISA: PnP bios: Audio device
     ISA: System keyboard (US-English)

If you have installed a device that is not listed, there are two possibilities: either the device is not supported by Solaris or it is supported but its configuration must be changed before installation can proceed. To modify the device's characteristics, select the "Device Task" option. In addition to changing device characteristics, you can set input device parameters (e.g., keyboard) and the default console device from this page. Alternatively, configuration information can be restored from disk, or the current configuration can be saved to disk. This is a useful feature when there are multiple compatible systems to install and configure concurrently.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Solaris provides two ways to perform an installation: interactively or by using the Web Start Wizard. Although previous versions of Solaris used the interactive installer, which consists of a series of text-based screens, the Web Start Wizard uses a Java GUI to perform the installation. Not only is the Wizard system easier to use, it allows the installer to make use of "copy and paste" and other editing facilities. The Wizard allows software to be installed by distribution or by individual package.

The Wizard divides the installation into a number of individual stages. These include:

Network
Name service
Date and time
Root password
Power management
Proxy server
Kiosk

To perform the installation, you'll use the data contained in the Host, Software, and Hardware Configuration data sheets. In many cases, the values entered there can be retyped into the screens of the Wizard. For example, the values for the IP address, hostname, and netmask of the host can be entered into the screens of the Network section. In addition, if the host uses DHCP to retrieve its IP address, the IP address of the DHCP server must be entered. If the local network uses IPv6 in addition to IPv4, this must be entered.

Next, enter the DNS and NIS+ name server details into the Name Service section. The IP address of the primary DNS server can be entered, and up to two backup servers. In addition, the IP address of the local NIS+ server should also be entered.

Once the network settings are entered, you must enter the local time zone, so the system can set the appropriate date and time. If the displayed date and time are incorrect, modify them at this point.

Next, set the root password. As the root user has superuser privileges, select the password carefully. For example, the password should not be a word that appears in any dictionary (for any language) and should ideally be a random string of characters that can be remembered easily.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

After undertaking the complex tasks required to configure a single host, planning and setting up an entire network can be daunting. In this chapter, you'll learn how to configure a Solaris-based network, including the configuration of single or multiple network interfaces, static and dynamic routing, and network troubleshooting. In addition, examples for enabling devices and testing interfaces will be provided.

While Solaris systems are capable of operating in an isolated, non-networked environment, Solaris is a strongly network-oriented operating system. It provides the following tools to support networking, both between hosts on a local area network and to the worldwide Internet:

Support for single, dual, and quad ethernet devices
Standardized network device naming
Support for a wide variety of network devices
Configuration of interfaces to support IPv4 and IPv6
Routing using static and dynamic protocols
Troubleshooting and performance measurement
Blocking/acess filtering on all TCP and UDP ports
Transmission using Ethernet and FDDI
Support for Asynchronous Transfer Mode (ATM) networks

In combination, these features make it easy to construct Solaris networks, especially networks in which Solaris systems are assigned backbone functions in routing and packet filtering.

A typical Solaris local area network will contain one or more servers, which provide network services to local clients. These clients can be other Solaris systems, but are just as likely to be Linux, Microsoft Windows, or other Unix systems. In some network designs, each major service is located on its own system, to prevent downtime on one system from disabling access to all services. This brand of server role diversification is taken one step further by the E10000 system, which can be logically partitioned to form 64 independent virtual servers, all physically located on the same machine. Thus, if one domain is taken offline for service, other domains are unaffected.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

While Solaris systems are capable of operating in an isolated, non-networked environment, Solaris is a strongly network-oriented operating system. It provides the following tools to support networking, both between hosts on a local area network and to the worldwide Internet:

Support for single, dual, and quad ethernet devices
Standardized network device naming
Support for a wide variety of network devices
Configuration of interfaces to support IPv4 and IPv6
Routing using static and dynamic protocols
Troubleshooting and performance measurement
Blocking/acess filtering on all TCP and UDP ports
Transmission using Ethernet and FDDI
Support for Asynchronous Transfer Mode (ATM) networks

In combination, these features make it easy to construct Solaris networks, especially networks in which Solaris systems are assigned backbone functions in routing and packet filtering.

A typical Solaris local area network will contain one or more servers, which provide network services to local clients. These clients can be other Solaris systems, but are just as likely to be Linux, Microsoft Windows, or other Unix systems. In some network designs, each major service is located on its own system, to prevent downtime on one system from disabling access to all services. This brand of server role diversification is taken one step further by the E10000 system, which can be logically partitioned to form 64 independent virtual servers, all physically located on the same machine. Thus, if one domain is taken offline for service, other domains are unaffected.

The numbers and types of services provided on a Solaris local area network are virtually endless, but a typical configuration would include the following service types:

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Although the various Solaris installation programs will happily configure built-in network interfaces at installation, there are several situations where you may need to add another interface or modify the configuration of the existing interfaces. These situations include:

Setting up an existing host as a router
Relocating a host to a different subnet
Setting up load balancing across different interfaces

In order to enable a network interface under Solaris, several steps may be necessary. These include:

Installing any device drivers
Reconfiguring the system by rebooting
Assigning an IP address to the interface
Deciding whether the interface acts as a router component or as a component of a multi-homed host
Creating a hosts entry that maps the IP address to a hostname
Configuring and plumbing the interface for passing traffic

Device drivers are typically stored in /kernel/drv (or as defined in /etc/system ) and listed in /etc/device_aliases . For example, the standard quad ethernet connector supplied by Sun has the driver /kernel/drv/qfe, and has its alias listed in /etc/device_aliases as qfe SUNW,qfe. Rebooting with the following command forces a reconfiguration reboot:

bash-2.03# touch /reconfigure; init 6

Alternatively, from the OpenBoot PROM monitor, the following command can be used to force a reconfiguration boot:

OK boot -r

An IP address is assigned to the interface by inserting the IP address into a hostname file, located in the /etc directory. For a system with a single interface (e.g., /dev/eri0), such as the Blade 100, the hostname file is called

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Once all network interfaces are configured as required, use the netstat command, which is responsible for gathering network statistics of various types, to verify their operational status. This data is gathered by using the interfaces on the local host.

netstat is able to gather statistics for the following types of data:

Data grouped by protocol type
Device statistics grouped by address type, including IPv4, IPv6, and Unix addresses
DHCP data
Interface data grouped by multicast
Routing table details (including multicast)
STREAMS data
The state of all available IP interfaces
The state of all active sockets, routes, physical interfaces, and logical interfaces

In the following sections, we'll review each of these data gathering operations and discuss how each is used to aid in troubleshooting and pinpointing performance issues.

The per- protocol statistics can be divided into several categories:

RAWIP (raw IP) packets	TCP packets
IPv4 packets	ICMPv4 packets

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Imagine that you are a courier, and your run always starts at the local courier depot. You're given a list of addresses, which are associated with a set of packages, and your goal is to deliver them in as little time as possible, subject to the following constraints:

The number of roads you take to deliver each package must be minimized.
You must avoid deadends and accidents.
You can only determine which roads to take by consulting a street directory and by crosschecking street names along your path with those in your directory.

If this seems like a fairly trivial task for a courier, consider how much more difficult the job would be if the following conditions prevailed:

The number of possible roads increases exponentially each year. You might be asked to take roads you've never heard of before!
There is no way of knowing, in advance, where accidents or deadends might occur.
The street directory you have is completely out of date, because the number of highways increases exponentially each year.

This scenario describes the difficulties faced by the emergence of the Internet and the massive interconnections between hosts and networks. In order for a packet of data to be transferred from host A to host B, a physical path must be identified for the packet to travel.

There is no central lookup service that decides how to route each packet between all possible combinations of two hosts on the Internet (i.e., between the sender and the receiver). This means routes must be generated dynamically. (The only exceptions to this rule are certain situations where a predictable static route may be installed.)

When transferring data around the Internet or between subnets, intermediate hosts must be responsible for transferring packets between networks; these hosts are called routers and are responsible for routing packets between hosts, which can be separated by single subnets or by entire continents. To gain insight into how many routers a packet transfer may involve, let's use the

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Once a network has been conceived and various functions assigned to different hosts, it is critical that at least one directory system be set up to locate hosts on the network. Additional naming services may be required to support directory services for Internet domains. In this chapter I discuss the importance of distributed naming services for locating hosts, users, and resources on a network, and walk through the configuration of a Solaris Domain Name Service (DNS). DNS allows IP addresses to be mapped to human-friendly hostnames and vice versa. Solaris goes one step further than DNS in supporting hierarchical namespaces, using Sun's Network Information Service (NIS/NIS+). NIS/NIS+ is examined as a comprehensive network resource management system for both authorizing access to resources and hosts and handling client/server authentication. Finally, I review the newer Lightweight Directory Access Protocol (LDAP) and its implementation under Solaris.

Before looking more closely at the implementations of various naming services, I will focus on what the term domain really means. In general terms, a domain is like a nation state, with clearly identifiable borders, security mechanisms to repel intruders, and a set of shared expectations (codified in laws) about what constitutes neighborly behavior. An economic relationship exists between citizens of the domain, such that services can be provided where an account can be maintained of their use.

A Solaris domain, of whatever type, has many parallels with a nation state: groups of hosts are protected by a central authority that ensures local network security, users are able to access services from a number of hosts within a local domain, and system accounting and auditing facilities are able to keep records of who uses these services. It's no wonder that Sun refers to its Solaris domain services as the Federated Naming Service!

In order for any kind of Solaris domain to operate successfully, it's essential that a repository of data is maintained (in either a centralized or distributed fashion) that contains authoritative data on all users and hosts under local control. Standalone Solaris systems typically use files to keep track of individual users and groups authorized to operate on a local system. On a small local area network, the Domain Name Service (DNS) is typically used to map IP addresses to hostnames, making it easy to reference hosts using all IP-aware applications.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Before looking more closely at the implementations of various naming services, I will focus on what the term domain really means. In general terms, a domain is like a nation state, with clearly identifiable borders, security mechanisms to repel intruders, and a set of shared expectations (codified in laws) about what constitutes neighborly behavior. An economic relationship exists between citizens of the domain, such that services can be provided where an account can be maintained of their use.

A Solaris domain, of whatever type, has many parallels with a nation state: groups of hosts are protected by a central authority that ensures local network security, users are able to access services from a number of hosts within a local domain, and system accounting and auditing facilities are able to keep records of who uses these services. It's no wonder that Sun refers to its Solaris domain services as the Federated Naming Service!

In order for any kind of Solaris domain to operate successfully, it's essential that a repository of data is maintained (in either a centralized or distributed fashion) that contains authoritative data on all users and hosts under local control. Standalone Solaris systems typically use files to keep track of individual users and groups authorized to operate on a local system. On a small local area network, the Domain Name Service (DNS) is typically used to map IP addresses to hostnames, making it easy to reference hosts using all IP-aware applications.

However, DNS provides no mechanism to manage anything other than hostnames; all other system resources, such as users, groups, and printers, must either be managed individually for every host in the domain, or another domain service must be used. One of the most popular (and simple) enhanced domain services is the Network Information Service (NIS). NIS allows a single centralized server to manage the following resources on an entire local network:

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|

Table of Contents