Configuring TCP/IP on Solaris - Overview of the Booting Processes

The Boot Process

The following information is provided for your reference. It is a brief overview of the network booting processes to help you better visualize what is happening during configuration.

Note - The names of startup scripts might change from one release to another.

You start the operating system on a host.

The kernel runs /sbin/init, as part of the booting process.

/sbin/init runs the /etc/rcS.d/S30rootusr.sh. startup script.

The script runs a number of system startup tasks, including establishing the minimum host and network configurations for diskless and dataless operations. /etc/rcS.d/S30rootusr.sh also mounts the /usr file system.

If the local database files contain the required configuration information (host name and IP address), the script uses it.

If the information is not available in local host configuration files, /etc/rcS.d/S30rootusr.sh uses RARP to acquire the host's IP address.

If the local files contain domain name, host name, and default router address, the machine uses them. If the configuration information is not in local files, then the system uses the Bootparams protocol to acquire the host name, domain name, and default router address. Note that the required information must be available on a network configuration server that is located on the same network as the host. This is necessary because no internetwork communications exist at this point.

After /etc/rcS/S30rootusr.sh completes its tasks and several other boot procedures have executed, /etc/rc2.d/S69inet runs. This script executes startup tasks that must be completed before the name services (NIS, NIS+, or DNS) can start. These tasks include configuring the IP routing and setting the domain name.

At completion of the S69inet tasks, /etc/rc2.d/S71rpc runs. This script starts the NIS, NIS+, or DNS name service.

After /etc/rc2.d/S71 runs, /etc/rc2.d/S72inetsvc runs. This script starts up services that depend on the presence of the name services. S72inetsvc also starts the daemon inetd, which manages user services such as telnet.

Configuring TCP/IP on Solaris - Network Configuration Procedures

Introduction

Network software installation takes place along with the installation of the operating system software. At that time, certain IP configuration parameters must be stored in appropriate files so they can be read at boot time.

The procedure is simply a matter of creating or editing the network- configuration files. How configuration information is made available to a machine's kernel depends on whether these files are stored locally (local files mode) or acquired from the network configuration server (network client mode). Parameters supplied during network configuration are:

IP address of each network interface on every machine

Host names of each machine on the network. You can type the host name in a local file or a name service database.

NIS, NIS+, or DNS domain name in which the machine resides, if applicable

Default router addresses. You supply this only if you have a simple network topology with only one router attached to each network, or your routers don’t run routing protocols such as the Router Discovery Server Protocol (RDISC) or the Router Information Protocol (RIP). (See Chapter 5 for more information about these protocols.)

Subnet mask (required only for networks with subnets)

This section contains complete information on creating and editing local configuration files.

How to Configure a Host for Local Files Mode

Use this procedure for configuring TCP/IP on a machine that run in local files mode.

Become superuser and change to the /etc directory.

Type the host name of the machine in the file /etc/nodename. For example, if the name of the host is tenere, type tenere in the file.

Create a file named /etc/hostname.interface for each network interface. (The Solaris installation program automatically creates this file for the primary network interface.)

Type either the interface IP address or the interface name in each /etc/hostname.interface file. For example, create a file named hostname.ie1, and type either the IP address of the host's interface or the host's name.

Edit the /etc/inet/hosts file to add:

IP addresses that you have assigned to any additional network interfaces in the local machine, along with the corresponding host name for each interface. The Solaris installation program will already have created entries for the primary network interface and loopback address.

IP address or addresses of the file server, if the /usr file system is NFS mounted.

Type the host's fully qualified domain name in the /etc/defaultdomain file. For example, suppose host tenere was part of the domain deserts.worldwide.com. Therefore, you would type: deserts.worldwide.com in /etc/defaultdomain.

Type the router's name in /etc/defaultrouter.

Type the name of the default router and its IP addresses in /etc/inet/hosts. Additional routing options are available. You can apply these options to a local files mode configuration.

If your network is subnetted, type the network number and the netmask in the file /etc/inet/netmasks. If you have set up a NIS or NIS+ server, you can type netmask information in the appropriate database on the server as long as server and clients are on the same network.

Reboot each machine on the network.

Setting Up a Network Configuration Server

If you plan to configure certain hosts as network clients, you must configure at least one machine on your network as a network configuration server. (Refer to “Network Configuration Servers” on page 45 for an introduction.) Setting up a network configuration server involves:

Turning on the network configuration daemons:
- in.tftpd
- in.rarpd
- rpc.bootparamd

Editing and maintaining the network configuration files on the configuration server.

How to Set Up a Network Configuration Server

Become superuser and change to the root directory of the prospective network configuration server.

Turn on the in.tftpd daemon by creating the directory /tftpboot:

# mkdir /tftpboot

This configures the machine as a TFTP, bootparams, and RARP server.

Create a symbolic link to the directory.

# ln -s /tftpboot/. /tftpboot/tftpboot

Enable the tftp line in intetd.conf. Check that the /etc/inetd.conf entry reads:

tftp dgram udp wait root /usr/sbin/in.tftpd in.tftpd -s /tftpboot

This prevents inettftpd() from retrieving any file other than one located in /tftpboot.

Edit the hosts database, and add the host names and IP addresses for every client on the network.

Edit the ethers database, and create entries for every host on the network to run in network client mode.

Edit the bootparams database. Use the wildcard entry or create an entry for every host that run in network client mode.

Reboot the server.

Configuring Network Clients

Network clients receive their configuration information from network configuration servers. Therefore, before you configure a host as a network client you must ensure that at least one network configuration server is set up for the network.

How to Configure Hosts for Network Client Mode

Do the following on each host to be configured in network client mode:

Become superuser.

Check the directory for the existence of an /etc/nodename file. If one exists, delete it.

Eliminating /etc/nodename causes the system to use the hostconfig program to obtain the host name, domain name, and router addresses from the network configuration server.

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.

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).

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.

Ensure that the search paths in the client's /etc/nsswitch.conf reflects the name service requirements for your network.

How to Specify a Router for the Network Client

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.

To override the name of the default router provided by the network configuration server:

Create /etc/defaultrouter on the network client.

Type the host name and IP address of the machine you have designated as the default router.

Add the host name and IP address of the designated default router to the network client's /etc/inet/hosts.

If you have multiple routers on the network, create /etc/defaultrouter on the network client, but leave it empty.

Creating /etc/defaultrouter and leaving it empty causes one of the two dynamic routing protocols to run: ICMP Router Discovery protocol (RDISC), or Routing Information Protocol (RIP). The system first runs the program in.rdisc, which looks for routers that are running the router discovery protocol. If it finds one such router, in.rdisc continues to run and keeps track of the routers that are running the RDISC protocol.

If the system discovers that routers are not responding to the RDISC protocol, it uses RIP and runs the daemon in.routed to keep track of them.

After Installing a Network Client

After you have finished editing the files on each network client machine, do the following on the network configuration server.

Add entries for the hosts in the ethers and hosts databases.

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.

Reboot the server.

Configuring TCP/IP on Solaris - Network Databases and nsswitch.conf File

Introduction

The network databases are files that provide information needed to configure the network. The network databases are:

hosts

netmasks

ethers

bootparams

protocols

services

networks

As part of the configuration process, you edit the hosts database and the netmasks database, if your network is subnetted. Two network databases, bootparams and ethers, are used to configure machines as network clients. The remaining databases are used by the operating system and seldom require editing.

Although it is not a network database, the nsswitch.conf file needs to be configured along with the relevant network databases. nsswitch.conf specifies which name service to use for a particular machine: NIS, NIS+, DNS, or local files.

How Name Services Affect Network Databases

Your network database takes a form that depends on the type of name service you select for your network. For example, the hosts database contains, at minimum, the host name and IP address of the local machine and any network interfaces directly connected to the local machine. However, the hosts database could contain other IP addresses and host names, depending on the type of name service on your network.

The network databases are used as follows:

Networks that use local files for their name service rely on files in the /etc/inet and /etc directories

NIS+ uses databases called NIS+ tables

NIS uses databases called NIS maps

DNS uses records with host information

Note - DNS boot and data files do not correspond directly to the network databases.

Network Database	Local Files	NIS+ Tables	NIS Maps
hosts	/etc/inet/hosts	hosts.ord_dir	hosts.byaddr hosts.byname
netmasks	/etc/inet/netmasks	netmasks.ord_dir	netmasks.byaddr
ethers	/etc/ethers	ethers.ord_dir	ethers.byname ethers.byaddr
bootparams	/etc/bootparams	bootparams.ord_dir	bootparams
protocols	/etc/inet/protocols	protocols.ord_dir	protocols.byname protocols.bynumber
services	/etc/inet/services	services.ord_dir	services.byname
networks	/etc/inet/networks	networks.ord_dir	networks.byaddr networks.byname

nsswitch.conf File - Specifying Which Name Service to Use

The /etc/nsswitch.conf file defines the search order of the network databases. The Solaris installation program creates a default /etc/nsswitch.conf file for the local machine, based on the name service you indicate during the installation process. If you selected the 'None' option, indicating local files for name service, the resulting nsswitch.conf file resembles the following example:

nsswitch.conf for Networks Using Files for Name Service

# /etc/nsswitch.files: # # An example file that could be copied over to /etc/nsswitch.conf; # it does not use any naming service. # # "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.

nsswitch.conf for a Diskless Client on a Network Running NIS

## /etc/nsswitch.conf:# . . passwd: files nis group: file nis # consult /etc "files" only if nis is down. hosts: nis [NOTFOUND=return] files networks: nis [NOTFOUND=return] files protocols: nis [NOTFOUND=return] files rpc: nis [NOTFOUND=return] files ethers: files [NOTFOUND=return] nis netmasks: nis [NOTFOUND=return] files bootparams: files [NOTFOUND=return] nis publickey: nis netgroup: nis automount: files nis aliases: files nis # for efficient getservbyname() avoid nis services: files nis sendmailvars: files

bootparams Database

The bootparams database contains information used by diskless clients and machines configured to boot in the network client mode. You need to edit it if your network will have network clients. The database is built from information entered into the /etc/bootparams file.

The bootparams(4) man page contains complete syntax for this database. Its basic syntax is:

    machine-name file-key-server-name:pathname

For each diskless or network client machine, the entry might contain the following information: the name of the client, a list of keys, the names of servers, and path names.

The first item of each entry is the name of the client machine. Next is a list of keys, names of servers, and path names, separated by tab characters. All items but the first are optional. The database can contain a wildcard entry that will be matched by all clients. Here is an example:

bootparams Database

myclient root=myserver : /nfsroot/myclient \ swap=myserver : /nfsswap//myclient \ dump=myserver : /nfsdump/myclient

In this example the term dump=: tells diskless hosts not to look for a dump file.

Wildcard Entry for bootparams
In most cases, you will want to use the wildcard entry when editing the bootparams database to support diskless clients. This entry is:

    * root=server:/path dump=:

The asterisk (*) wildcard indicates that this entry applies to all clients not specifically named within the bootparams database.

ethers Database

The ethers database is built from information entered into the /etc/ethers file. It associates host names to their Ethernet addresses. You need to create an ethers database only if you are running the RARP daemon; that is, if you are configuring network clients or diskless machines.

RARP uses the file to map Ethernet addresses to IP addresses. If you are running the RARP daemon in.rarpd, you need to set up the ethers file and maintain it on all hosts running the daemon to reflect changes to the network.

The ethers(4) man page contains complete syntax information for this database. Its basic format is:

Ethernet-address hostname #comment
Ethernet-address is the Ethernet address of the host.
hostname is the official name of the host.
#comment is any kind of note you want to append to an entry in the file.

The equipment manufacturer provides the Ethernet address. If a machine does not display the Ethernet address when you power up, see your hardware manuals for assistance.

When adding entries to the ethers database, make sure that host names correspond to the primary names in the hosts database, not to the nicknames, as shown in the following example:

Entries in the ethers Database

8:0:20:1:40:16 fayoum 8:0:20:1:40:15 nubian 8:0:20:1:40:7 sahara # This is a comment 8:0:20:1:40:14 tenere

Other Network Databases

The remaining network databases seldom need to be edited.

networks database Database

The networks database associates network names with network numbers, enabling some applications to use and display names rather than numbers. The networks database is based on information in the /etc/inet/networks file. It contains the names of all networks to which your network connects via routers.

The Solaris installation program sets up the initial networks database. The only time you need to update it is when you add a new network to your existing network topology.

The networks(4) man page contains full syntax information for /etc/inet/networks. Here is its basic format:

  network-name network-number nickname(s) # comment   network-name is the official name for the network.   network-number is the number assigned by the InterNIC.   nickname is any other name by which the network is known.   #comment is any kind of note you want to append to an entry in the file.

It is particularly important that you maintain the networks file. The netstat program uses the information in this database to produce status tables. The example shows a sample /etc/networks file:

/etc/networks File

#ident "@(#)networks 1.4 92/07/14 SMI" /* SVr4.0 1.1 */ # # The networks file associates Internet Protocol (IP) network numbers with network names. The format of this file is: # # network-name network-number nicnames . . . # The loopback network is used only for intra-machine communication #loopback 127 # Internet networks # arpanet 10 arpa # Historical ucb-ether 46 ucbether # # local networks eng 193.9.0 #engineering acc 193.9.1 #accounting prog 193.9.2 #programming

protocols Database

The protocols database lists the TCP/IP protocols installed on your system and their numbers; the Solaris installation program automatically creates it. It is rare when this file requires administrative handling.

The protocols database contains the names of the TCP/IP protocols installed on the system. Its syntax is completely described in the protocols(4) man page. The example below shows an example of the /etc/inet/protocols file:

/etc/inet/protocols File

# # Internet (IP) protocols # ip 0 IP # internet protocol, pseudo protocol number icmp 1 ICMP # internet control message protocol tcp 6 TCP # transmission control protocol udp 17 UDP # user datagram protocol

services Database

The services database lists the names of TCP and UDP services and their well known port numbers; it is used by programs that call network services. The Solaris installation automatically creates the services database; it generally requires no administrative handling.

The services(4) man page contains complete syntax information. The example below shows an excerpt from a typical /etc/inet/services file:

/etc/inet/services File

# # Network services # echo 7/udp echo 7/tcp discard 9/udp sink null discard 11/tcp daytime 13/udp daytime 13/tcp netstat 15/tcp ftp-data 20/tcp ftp 21/tcp telnet 23/tcp time 37/tcp timeserver time 37/udp timeserver name 42/udp nameserver whois 43/tcp nickname

Networking -- Solaris

Introduction

In order to configure networking after installing Solaris, several files will need to be created and/or modified. This document provides a quick overview of those files along with example configuration data.

In most cases, the installation process performs all necessary configuration tasks. One of the tasks generally not performed by the installer is updating the Solaris networking files.

I have not found an easy way to force the installation program to configure all local networking files if the "Naming Services" section fails. For example, if you select the DNS naming service and the machine you are configuring is not entered in DNS, the installation process will skip this section. In cases like this, it will be necessary to update several of the files that pertain to networking. The following is a list of those files and the content that should be provided. Keep in mind that the system will need to be rebooted after making changes (and creating) these files.

/etc/resolv.conf

During the Solaris installation program, you are prompted for Naming Configuration information. In most cases, we use DNS. But during the installation process, if the installer is unable to communicate with and/or resolve your newly configured host with DNS, the Naming Configuration will fail, and none of the configuration files (i.e. /etc/resolv.conf) will not be updated. I often find it necessary to manually create the /etc/resolv.conf with any name service information.

nameserver 63.67.120.18 nameserver 63.67.120.23

/etc/resolv.conf

/etc/hostname.interface

The Solaris installation program creates this file for you. The file contains only one entry: the host name or IP address associated with the network interface. For example, suppose eri0 is the primary network interface for a machine called alexprod. Its /etc/hostname.interface file would have the name /etc/hostname.eri0; the file would contain the single entry alexprod.

alexprod

/etc/hostname.eri0

/etc/nodename

This file should contain one entry; the host name of the local machine. For example, on machine alexprod, the file /etc/nodename would contain the entry alexprod.

alexprod

/etc/nodename

/etc/defaultdomain

This file should contain one entry, the full qualified domain name of the administrative domain to which the local host's network belongs. You can supply this name to the Solaris installation program or edit the file at a later date.

Take for example the domain iDevelopment which was classified as a .info domain. In this example, /etc/defaultdomain should contain the entry iDevelopment.info.

idevelopment.info

/etc/defaultdomain

/etc/defaultrouter

This file should contain an entry for each router directly connected to the network. The entry should be the name for the network interface that functions as a router between networks.

If the default router for a machine will be 192.168.1.1, then this is the entry that should be put into the file /etc/defaultrouter.

192.168.1.1

/etc/defaultrouter

/etc/hosts

The hosts database contains the IP addresses and host names of machines on your network.

If you use local files for name service, the hosts database is maintained in the /etc/inet/hosts file. This file contains the host names and IP addresses of the primary network interface, other network interfaces attached to the machine, and any other network addresses that the machine must know about.

NOTE: For compatibility with BSD-based operating systems, the file /etc/hosts is a symbolic link to /etc/inet/hosts.

# # Internet host table # 127.0.0.1 localhost 192.168.1.102 alexprod alexprod.idevelopment.info loghost

/etc/hosts

/etc/inet/netmasks

You need to edit the netmasks database as part of network configuration only if you have set up subnetting on your network. The netmasks database consists of a list of networks and their associated subnet masks.

# # The netmasks file associates Internet Protocol (IP) address # masks with IP network numbers. # # network-number netmask # # The term network-number refers to a number obtained from the Internet Network # Information Center. Currently this number is restricted to being a class # A, B, or C network number. In the future we should be able to support # arbitrary network numbers per the Classless Internet Domain Routing # guidelines. # # Both the network-number and the netmasks are specified in # "decimal dot" notation, e.g: # # 128.32.0.0 255.255.255.0 # 192.168.1.0 255.255.255.0

/etc/inet/netmasks

/etc/nsswitch.conf

The /etc/nsswitch.conf file defines the search order of the network databases (hosts, netmasks, ethers, bootparams, protocols, services, networks).

The Solaris installation program creates a default /etc/nsswitch.conf file for the local machine, based on the name service you indicate during the installation process. The installation process also creates 5 template files that can be copied over to /etc/nsswitch.conf:

nsswitch.files

nsswitch.nis

nsswitch.dns

nsswitch.ldap

nsswitch.nisplus

If you selected the 'None' option, indicating local files for name service, the resulting /etc/nsswitch.conf file resembles the following example:

# # /etc/nsswitch.files: # # An example file that could be copied over to /etc/nsswitch.conf; it # does not use any naming service. # # "hosts:" and "services:" in this file are used only if the # /etc/netconfig file has a "-" for nametoaddr_libs of "inet" transports. passwd: files group: files hosts: files ipnodes: files networks: files protocols: files rpc: files ethers: files netmasks: files bootparams: files publickey: files # At present there isn't a 'files' backend for netgroup; the system will # figure it out pretty quickly, and won't use netgroups at all. netgroup: files automount: files aliases: files services: files sendmailvars: files printers: user files auth_attr: files prof_attr: files project: files

/etc/nsswitch.conf - Default if you are using local files

Here is another /etc/nsswitch.conf file that adds a dns entry for hosts::

# # /etc/nsswitch.dns: # # An example file that could be copied over to /etc/nsswitch.conf; it uses # DNS for hosts lookups, otherwise it does not use any other naming service. # # "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

/etc/nsswitch.conf - Adding a dns database for the hosts: element

Here is another /etc/nsswitch.conf file that uses a combination of files, nis, and dns entries:

# /etc/nsswitch.nis: # # An example file that could be copied over to /etc/nsswitch.conf; it # uses NIS (YP) in conjunction with files. # # "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 # consult /etc "files" only if nis is down. hosts: files dns nis ipnodes: files # Uncomment the following line and comment out the above to resolve # both IPv4 and IPv6 addresses from the ipnodes databases. Note that # IPv4 addresses are searched in all of the ipnodes databases before # searching the hosts databases. Before turning this option on, consult # the Network Administration Guide for more details on using IPv6. #ipnodes: nis [NOTFOUND=return] files networks: nis [NOTFOUND=return] files protocols: nis [NOTFOUND=return] files rpc: nis [NOTFOUND=return] files ethers: nis [NOTFOUND=return] files netmasks: nis [NOTFOUND=return] files bootparams: nis [NOTFOUND=return] files publickey: nis [NOTFOUND=return] files netgroup: nis automount: files nis aliases: files nis # for efficient getservbyname() avoid nis services: files nis sendmailvars: files printers: user files nis auth_attr: files nis prof_attr: files nis project: files nis

/etc/nsswitch.conf - Using a combination of files, nis, and dns databases

Removing Invalid Disk Device Files (/dev/dsk and /dev/rdsk)

Removing Invalid Disk Device Files (/dev/dsk and /dev/rdsk)

by Jeff Hunter, Sr. Database Administrator

Overview

Whether installing a SCSI controller or even an additional IDE disk to a Sun Solaris machine, the Solaris O/S will:

Create Disk Device Files under the Hardware Device Tree (/devices).

Create symbolic links in /dev/dsk, /dev/rdsk, and /dev/cfg that point to the devices in the /devices directory.

Make entries in the /etc/path_to_inst file.

Things will generally work fine until you decide to remove or move a device in the system. I have had situations where I have run out of devices on a host because of Sun's poor ability to remove invalid (hanging) disk device files after removing a device. This is one area where Sun could really improve. It looks like they are trying new things with the boot -p option but I've only ever seen it remove things once.

There are other times when I simply wanted to replace a certain type of SCSI controller and wanted to reuse the controller ID's from a previously removed card. For example, I have a host (an E450) which had 2 internal controllers (0 and 1) and a dual differential SCSI card installed (controllers 2 and 3). I removed the dual differential SCSI host adapter and decided to replace it with a Single-Ended SCSI host adapter but Solaris would always assign them controller numbers 4 and 5. I wanted the system to reassign controller numbers 2 and 3 for the new host adapter but links still existed for the original dual differential SCSI host adapter.

My intention in this article is to provide several solutions for either renumbering disk device files (SCSI controllers, SCSI disks, IDE controllers, IDE disks, etc.) or simply removing old ones from replaced or removed devices. Please keep in mind that this article has been put together from notes I found during many searches for answers on the Internet. If anyone reading this has other solutions, please email me and I would be happy to post them for others going through this procedure.

Using the devfsadm Command

The devfsadm command was introduced with Solaris 7 and can be found in /usr/sbin/devfsadm. This command is used to maintain the /dev and /devices namespaces. The devfsadm command replaces the previous suite of devfs administration tools including drvconfig(1M), disks(1M), tapes(1M), ports(1M), audlinks(1M), and devlinks(1M). To maintain backwards compatibility, all previous devfs commands are hard links to devfsadm.

In many cases, you only need run the command:

  # devfsadm -C

to invoke the cleanup routines that are not normally invoked to remove dangling logical links.

Manual Methods

The devfsadm command was introduced with Solaris 7. For those running older versions of Solaris (i.e. Solaris 2.6) or simply want to perform all manual steps, this section describes the procedures to do just that.

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.

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.)

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.

Remove all files under /devices/* for the controller you want to remove or renumber as indicated in Step #1.

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.

Reboot the server with the "-srv" option:

ok boot -srv

Understanding Disk Device Files (i.e. breaking down c0t2d0s7)

Understanding Disk Device Files (i.e. breaking down c0t2d0s7)

by Jeff Hunter, Sr. Database Administrator

Overview

Under Solaris, one of the most involved UNIX devices to understand is the disk device file. Here are several key points that may help:

In many cases, a disk device file (i.e. /dev/dsk/c0t2d0s7) refers to a particular partition (aka "slice") of a disk, and not the entire physical device. There are several device files which refer to the entire physical device, but are rarely used.

For every disk device, there are usually two device files - the block device and the character ("raw") device. In general:

block devices are generally stored under /dev/dsk and used for filesystem type access (e.g mount)

character devices are generally stored under /dev/rdsk used for everything else (e.g. fsck, newfs, etc..)

Discs are generally attached to a controller (or a bus) which can handle multiple devices. IDE and SCSI are both common attach methods. This tends to make disk device filename more complex than other types of devices.

/etc/vfstab

To see the difference between the block device and character device for a device, consider the following. The /etc/vfstab contains entries for a single filesystem on a Solaris server:

/dev/dsk/c0t2d0s7 /dev/rdsk/c0t2d0s7 /opt ufs 3 yes - 

The first 2 fields in the above entry, list the same disk device as both a block device ("dsk") and character device ("rdsk"). The block device is used by mount when mounting the filesystem while the character device is used by fsck when checking the filesystem and newfs when creating the filesystem.. Both fields must be present in /etc/vfstab.

Breaking Down c0t2d0s7

This section breaks down the different components of a disk device file. In this example, I will be using the disk device file: c0t2d0s7. The four components of the disk device file are: controller, target, LUN and slice/partition and further defined in the following table:

c0	This device is attached to controller #0. On a SPARCstation this is usually the on-board SCSI or IDE controller. If this is a PC it usually refers to the first IDE controller on the motherboard.
t2	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 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.
d0	The device is Logical Unit / "LUN" #0 (the first) on this target. Under SCSI a 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.

Adding SCSI Host Adapter (X6541A) into a Blade 100/150

Adding SCSI Host Adapter (X6541A) into a Blade 100/150

by Jeff Hunter, Sr. Database Administrator

Overview

A Sun Blade 100/150 can accept the following PCI SCSI host adapters:

Option #	Top Level Part #	Manufacturing Part #	Description	Substitute Part #
X1032A	595-4258	501-5656	Single-Ended Ultra/Wide SCSI/FastEthernet (SunSwift PCI)	501-2741
X2222A	595-5624	501-5727	Dual Ultra-2 SCSI/Dual FastEthernet PCI Adapter	n/a
X5010A	595-5377	375-0097	Single-Channel Single-Ended Ultra/Wide SCSI (PCI)	n/a
X6540A	595-4399	375-0005	Dual Single-Ended Ultra/Wide SCSI (PCI)	n/a
X6541A	595-4414	375-0006	Dual Differential Ultra/Wide SCSI (PCI)	n/a

In this article I will be documenting the steps for installing and configuring a Dual Differential Ultra/Wide SCSI (PCI) host adapter (X6541A) in a Sun Blade 150 running Solaris 8.

The above host adapters are designed to be installed in SPARC systems running at least Solaris 2.5.1 Hardware:4/97 operating system.

The host adapters support up to 15 targets on each SCSI bus.

Installing the Dual Differential Ultra/Wide SCSI (PCI)

The following section documents the steps necessary to install a Dual Differential Ultra/Wide SCSI (PCI) (X6541A) in a Sun Blade 150.

Check OS version

Check the file /etc/release to ensure you are running Solaris 2.5.1 or higher.

# cat /etc/release            Solaris 8 2/02 s28s_u7wos_08a SPARC Copyright 2002 Sun Microsystems, Inc.  All Rights Reserved.              Assembled 18 December 2001

Exit the OS and power down the system

Use either the shutdown command (if this is a server with active users that should be warned) or init 0 (if this is a stand along server). When at the ok prompt power down the system.

Unpack host adapter

The following items should be included with your host adapter package:

PCI UltraSCSI host adapter

2 meter UltraSCSI-compliant cable

Electrostatic discharge (ESD) kit

Open the computer

Attach the wrist strap

Attach the wrist strap between your wrist and a metal part of the system chassis.

Disconnect power cord from computer

Remove the filler panel for the desired slot

In most cases this will be just one screw to remove in order to remove the filler panel for the desired PCI slot.

Make sure that the switches and jumpers are correctly set.

For the single-ended host adapter, confirm the following settings:

Make sure that all elements of switches U1 and U2 are off.

Make sure that jumper TP9 is open.

For the differential host adapter, confirm the following settings:

Make sure that all jumpers (TP1, TP2, TP3, TP5, TP6) are open.

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.

Close up system

Close up the system and remove the anti-static wrist strap.

Reconnect power cable

Connect the SCSI cables

Connect the SCSI cable to your newly installed SCSI host adapter and then to the SCSI peripheral(s).

Power on peripherals / system

Power on your peripherals and then your system.

NOTE: If your system starts to reboot, interrupt the reboot process by pressing the Stop and A keys together. If this is not possible, allow the system to complete the boot process and then bring the system to the ok prompt by using init 0.

Make sure the host adapter is recognized by the system

Use the probe-scsi-all command to display the SCSI devices connected to your system. For example:

ok probe-scsi-all /pci@1f,2000/scsi@2 Target 8 Unit 0 Disk SEAGATE ST34371W SUN4.2G8254 /pci@1f,2000/scsi@2,1 Target 1 Unit 0 Disk SEAGATE ST34371W SUN4.2G8254

In the example, the first SCSI port (scsi@2) has one disk drive connected (target 8). The second SCSI port (scsi@2,1) also has one disk drive connected (target 1).

Reboot your system (using the -r option)

ok boot -r

Test the installation with SunVTS

You can use the SunVTS diagnostic program exercise your system to verify the functionality, reliability, and configuration of the new host adapter card. It is recommended to run the SunVTS program before attempting to utilize the new host adapter for any applications.

The SunVTS program needs to be run as the root userid.

# su

Bring up the SunVTS program (GUI Window):

# /opt/SUNWvts/bin/sunvts

Select a disk drive (any disk) that is attached to the host adapter card you just installed.

Start the test by hitting the "Start" button.

Verify that no errors have occurred by checking the SunVTS status window.

If no problems occur, stop SunVTS by hitting the "Stop" button and exit from the SunVTS application.

Your host adapter card is ready to run applications!

Solstice DiskSuite - (Solaris 2.5.1 - Solaris 8)

Solstice DiskSuite - (Solaris 2.5.1 - Solaris 8)

Solstice DiskSuite Software Data Sheet - (Solaris 8)
DiskSuite Support Matrix
Introduction
Installing
Command Line Tools
Creating Metadevices - (Using DiskSuite 4.2.1 Commands)
Metadevice State Database - (State Database Replicas)
Creating a Stripe - (RAID 0)
Creating a Concatenation - (RAID 0)
Creating Mirrors - (RAID 1)
Creating a RAID5 Volume - (RAID 5)
Creating a Trans Metadevice
Creating a Hot Spare
Removing Metadevices - (Using DiskSuite 4.2.1 Commands)
Removing a State Database Replica
Removing a Stripe - (RAID 0)
Removing a Concatenation - (RAID 0)
Removing a Mirror - (RAID 1)
Removing a RAID5 Volume - (RAID 5)
Removing a Trans Metadevice
Removing a Hot Spare

Solaris Volume Manager - (Solaris 9)

Solaris Volume Manager - (Solaris 9)

Solaris Volume Manager Data Sheet - (Solaris 9)
Introduction
Installing
Command Line Tools
Starting the Volume Manager Console GUI - (Enhanced Storage)
Creating Volumes - (Using Solaris 9 Volume Manager Commands)
State Database - (State Database Replicas)
Creating a Stripe - (RAID 0)
Creating a Concatenation - (RAID 0)
Creating Mirrors - (RAID 1)
Creating a RAID5 Volume - (RAID 5)
Creating a Hot Spare
Removing Volumes - (Using Solaris 9 Volume Manager Commands)
Removing a State Database Replica
Removing a Stripe - (RAID 0)
Removing a Concatenation - (RAID 0)
Removing a Mirror - (RAID 1)
Removing a RAID5 Volume - (RAID 5)
Removing a Hot Spare

Using NFS - (Solaris)

Using NFS - (Solaris)

by Jeff Hunter, Sr. Database Administrator

This brief article touches on several of the important commands that are used to NFS a file system on Solaris. Now keep in mind that with most Solaris configurations; enabling a Sun Solaris server to mount or share a file system, the required daemons will already be running. If not, this article may help you with this process.

The first thing to ensure is that the proper daemons for running NFS are started. If unsure, I will typically just run them when I cannot determine whether or not they are running:

$ su - $ cd /usr/lib/nfs $ ./mountd $ ./nfsd

NOTE: mountd: RPC server that answers requests for NFS access information and file system mount requests nfsd: The daemon that handles client file system requests

Sharing A File System

The following example will share a file system /software so that others may be able to mount it:

# share /software

If I want to check all file systems being shared from my system:

# share -               /software   rw   ""

How to NFS A File System

Now, from another machine, I want to NFS the file system that is being shared above:

# mount -F nfs alex:/software /mnt/software

How to Unmount an NFS File System

Finally, let's unmount the previously mounted file system:

# umount /mnt/software

Determine Which Package a Particular File Belongs To - (Sun Solaris)

by Jeff Hunter, Sr. Database Administrator

Use the pkgchk command to determine which package a particular file belongs to. The syntax is:

# /usr/sbin/pkgchk -l -p /absolute/path/todir

For example,

# /usr/sbin/pkgchk -l -p /usr/bin/pgrep Pathname: /usr/bin/pgrep Type: regular file Expected mode: 0555 Expected owner: root Expected group: bin Expected file size (bytes): 14688 Expected sum(1) of contents: 63968 Expected last modification: Mar 16 05:53:45 AM 2000 Referenced by the following packages:         SUNWcsu Current status: installed

You can also simply query the packages directory as follows:

# grep /usr/bin/pgrep /var/sadm/install/contents /usr/bin/pgrep f none 0555 root bin 14688 63968 953204025 SUNWcsu

Diagnostic Command - (Sun Solaris)

Diagnostic Command - (Sun Solaris)

by Jeff Hunter, Sr. Database Administrator

prtdiag

Use the following command to obtain detailed diagnostics information about your system configuration:

# /usr/platform/`uname -i`/sbin/prtdiag -v  System Configuration: Sun Microsystems  sun4u Sun Blade 150 (UltraSPARC-IIe 650MHz) System clock frequency: 93 MHZ Memory size: 1.75GB  ==================================== CPUs ====================================                E$          CPU     CPU       Temperature CPU  Freq      Size        Impl.   Mask     Die    Ambient ---  --------  ----------  ------  ----  --------  --------  0    650 MHz  512KB       US-IIe   3.3     56 C     29 C  ================================= IO Devices =================================      Bus   Freq Brd  Type  MHz   Slot        Name                              Model ---  ----  ----  ----------  --------------------------------  ----------------------  0   pci    33            7  isa/dma-isadma (dma)  0   pci    33            7  isa/serial-su16550 (serial)  0   pci    33            7  isa/serial-su16550 (serial)  0   pci    33            8  sound-pci10b9,5451.10b9.5451.1 (+  0   pci    33           12  network-pci108e,1101.1 (network)  SUNW,pci-eri  0   pci    33           12  firewire-pci108e,1102.1001 (fire+  0   pci    33           13  ide-pci10b9,5229.c3 (ide)  0   pci    33           19  SUNW,m64B (display)               ATY,RageXL  ============================ Memory Configuration ============================ Segment Table: ----------------------------------------------------------------------- Base Address       Size       Interleave Factor  Contains ----------------------------------------------------------------------- 0x0                256MB             1           Label DIMM0 0x40000000         512MB             1           Label DIMM1 0x80000000         512MB             1           Label DIMM2 0xc0000000         512MB             1           Label DIMM3  =============================== usb Devices ===============================  Name          Port# ------------  ----- device          4  =============================== device#4 Devices ===============================  Name          Port# ------------  ----- keyboard      mouse ============================ Environmental Status ============================ Fan Speeds: ---------------------------- Fan Device            Speed ---------------------------- system                 100%  ================================ HW Revisions ================================ ASIC Revisions: --------------- ebus: Rev 1  System PROM revisions: ---------------------- OBP 4.6.5 2002/06/03 16:49 POST 2.0.1 2001/08/23 17:13

prtconf

Use the following command to obtain detailed system information about your Sun Solaris installation:

# /usr/sbin/prtconf  System Configuration:  Sun Microsystems  sun4u Memory size: 1792 Megabytes System Peripherals (Software Nodes):  SUNW,Sun-Blade-100     packages (driver not attached)         SUNW,builtin-drivers (driver not attached)         deblocker (driver not attached)         disk-label (driver not attached)         terminal-emulator (driver not attached)         obp-tftp (driver not attached)         dropins (driver not attached)         kbd-translator (driver not attached)         ufs-file-system (driver not attached)     chosen (driver not attached)     openprom (driver not attached)         client-services (driver not attached)     options, instance #0     aliases (driver not attached)     memory (driver not attached)     virtual-memory (driver not attached)     pci, instance #0         ebus, instance #1             flashprom (driver not attached)             eeprom (driver not attached)             idprom (driver not attached)         isa, instance #0             dma, instance #0                 floppy, instance #0                 parallel (driver not attached)             power, instance #0             serial, instance #0             serial, instance #1         network, instance #0         firewire, instance #0         usb (driver not attached)         pmu, instance #0             i2c, instance #0                 temperature, instance #0                 card-reader (driver not attached)                 dimm (driver not attached)                 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

Using Package Manager on Solaris

Using Package Manager on Solaris

by Jeff Hunter, Sr. Database Administrator

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

Configuring Power Management (Sun Blades Only)

Configuring Power Management (Sun Blades Only)

by Jeff Hunter, Sr. Database Administrator

Hard drive and system power management are adjustable with the dtpower application with Solaris 8 7/01 release and higher. However, the power management features were not present in Solaris 8 10/00 and Solaris 8 1/01 releases. By default, power management is enabled on all new Sun Blade systems. (I really wish Sun would change this!)

When the system is in low-power mode, the hard drive eventually spins down to conserve power. Later, when you perform a task that accesses the hard drive, the hard drive spins up again. You might have to wait a few seconds for the hard drive to spin up to full speed. If you find that the delay is inconvenient, you can turn off Energy Star power management using one of the two methods provided below:

Method #1

You can disable the Energy Star power management feature by using the dtpower application.

Login as the "root" account and at the system prompt type:

# /usr/openwin/bin/dtpower

The dtpower application is displayed.

Under the Current power saving scheme menu, select Disabled.

Press the OK button.

Method #2

The main configuration file for controller Power Management is /etc/power.conf.

As the root user ID, edit the /etc/power.conf file as follows to disable all Automatic Power Management:

# # Copyright (c) 1996 - 2001 by Sun Microsystems, Inc. # All rights reserved. # #pragma ident "@(#)power.conf 1.14 99/10/18 SMI" # # Power Management Configuration File # # Statefile Path statefile /usr/.CPR # Auto-Shutdown Idle(min) Start/Finish(hh:mm) Behavior autoshutdown 30 9:00 9:00 noshutdown device-dependency-property removable-media /dev/fb autopm disable system-threshold always-on

Run the command:

# /usr/sbin/pmconfig

This utility is run from the command line after manual changes have been made to the /etc/power.conf file. For editing changes made to the /etc/power.conf file to take effect, users must run pmconfig.

pmconfig is also run at each system boot.

Configuring Telnet / FTP to login as root (Solaris)

Configuring Telnet / FTP to login as root (Solaris)

by Jeff Hunter, Sr. Database Administrator

Now before getting into the details of how to configure Solaris for root logins, keep in mind that this is VERY BAD security. Make sure that you NEVER configure your production servers for this type of login.

Configure Telnet for root logins

Simply edit the file /etc/default/login and comment out the following line as follows:

# If CONSOLE is set, root can only login on that device. # Comment this line out to allow remote login by root. # # CONSOLE=/dev/console

Configure FTP for root logins

First remove the 'root' line from /etc/ftpusers.

Also, don't forget to edit the file /etc/ftpaccess and comment out the 'deny-uid' and 'deny-gid' lines. If the file doesn't exist, there is no need to create it.

NOTE: If you are using Solaris 9 or Solaris 10, the ftp* files are located in /etc/ftpd

Booting Options and Using EEPROM

Booting Options and Using EEPROM

by Jeff Hunter, Sr. Database Administrator

EEPROM Command

The eeprom command is located in /usr/sbin/eeprom. The eeprom command is used to display or change the values of parameters in the EEPROM. It processes parameters in the order given. When processing a parameter accompanied by a value, eeprom makes the indicated alteration to the EEPROM; otherwise it displays the parameter's value. When given no parameter specifiers, eeprom displays the values of all EEPROM parameters. A '-' (hyphen) flag specifies that parameters and values are to be read from the standard input (one parameter or parameter = value per line). Only the super-user (root) may alter the EEPROM contents.

When the eeprom command is executed in user mode, the parameters with a trailing question mark (?) need to be enclosed in double quotation marks (" ") to prevent the shell from interpreting the question mark. Preceding the question mark with an escape character (\) will also prevent the shell from interpreting the question mark.

The remainder of this section descibes some of the common usages of the eeprom command in Solaris.

Query Values

To query all current EEPROM values, simply use the eeprom command with no arguments. If you only want to determine one EEPROM value, specify it as an argument. Here are two examples of using the eeprom command:

# eeprom auto-boot? auto-boot?=true # eeprom test-args: data not available. diag-passes=1 pci-probe-list=7,c,3,8,d,13,5 local-mac-address?=false fcode-debug?=false ttyb-rts-dtr-off=false ttyb-ignore-cd=true ttya-rts-dtr-off=false ttya-ignore-cd=true silent-mode?=false scsi-initiator-id=7 oem-logo: data not available. oem-logo?=false oem-banner: data not available. oem-banner?=false ansi-terminal?=true screen-#columns=80 screen-#rows=34 ttyb-mode=9600,8,n,1,- ttya-mode=9600,8,n,1,- output-device=screen input-device=keyboard load-base=16384 auto-boot?=true boot-command=boot diag-file: data not available. diag-device=disk net boot-file: data not available. boot-device=disk net use-nvramrc?=false nvramrc: data not available. security-mode=none security-password: data not available. security-#badlogins=0 mfg-mode=off diag-level=max diag-switch?=false error-reset-recovery=boot

auto-boot?

Used to control the auto-boot feature. This option controls whether the system directly boots up. You can disable auto-boot so next time it stays at the ok prompt for starting installations. Use the following command and reboot the system:

# eeprom "auto-boot?"=false