Software Packages and Clusters

Solaris 2.5 system software is delivered in units known as packages. A package is a collection of files and directories required for a software product. A cluster is a collection of packages.

The list below describes four clusters. Note that as you progress through the list, each cluster contains the software of the preceding cluster as well as additional software.

• Core System Support is the minimum software configuration; it contains only the software necessary to boot and run the Solaris 2.5 operating environment.
• End User System Support contains Core System Support plus end user support such as the OpenWindows windowing system and the related DeskSet application files; this cluster includes the recommended software for an end user.
• Developer System Support contains End User System Support plus the libraries, include files, and tools needed to develop software in the Solaris 2.5 operating environment. Compilers and debuggers are not included in the Solaris 2.5 operating environment.
• Entire Distribution contains the entire Solaris 2.5 environment.

For more information about this section's topics, see System Administration Guide, Volume I.

Package Administration

Software package management simplifies installing and updating software. Administration is simplified because the method for managing system software and third party applications is now consistent. The tools for creating software packages are in an application packaging tools library.

There are two tools you can use to install and remove packages:

• A graphical user interface program (see the admintool(1m) man page)
• The command-line utilities (see the pkgadd(1M) and pkgrm(1M) man pages)

Graphical User Interface (admintool)

You can install software on your local system or on a remote system with Admintool (started with the admintool command). The default location for the installation is the local system.

Use Admintool to:

• Look at the software installed on the local system
• Install or remove software on a local system

If you want to install or remove the software, you must run Admintool as superuser or as a user in the sysadmin group (group 14). You do not need to be superuser to look at the software packages that are already installed on a system.

Command-Line Utilities

You can use command-line utilities to install, remove, and check the installation of software packages. The commands are:

• pkgadd(1M) for installing a package
• pkgrm(1M) for removing a package
• pkgchk(1M) for checking the installation of a package
• pkginfo(1M) for listing the packages installed on a system

Disk Slices

A disk slice is composed of a single range of contiguous blocks, and is a physical subset of the disk (except for slice 2, which customarily represents the entire disk). Before you can create a file system on a disk, you must format and divide it into slices. See System Administration Guide, Volume I for complete information on installing and formatting disks, and dividing disks into slices.

A slice can be used as a raw device for swap space or to hold one and only one UFS file system. A disk can be divided into as many as eight slices. See System Administration Guide, Volume I for a list of customary disk slice assignments.

Cylinder Groups

You create a UFS file system on a disk slice, which is divided into one or more areas called cylinder groups. A cylinder group is composed of one or more consecutive disk cylinders (the set of tracks on a group of platters that have the same radial distance from the center of the platter). See System Administration Guide, Volume I for a complete description of disk geometry.

A cylinder group map is created for each cylinder group. The cylinder group map records the block usage and available blocks.

Figure 2-1 shows the relationship between disk slices and cylinder groups.

Figure 2-1

Device Naming

SunOS release 5.5 device names make it easier to infer certain device characteristics from a device name. SunOS release 4.x systems convey type, rather than device attributes, which makes it difficult for programs and scripts to derive necessary information about devices. SunOS release 5.5 conventions are slightly different from AT&T SVR4 device names because SunOS release 5.5 allows only eight partitions on a disk.

In addition, the /dev directory that contains the special device names has been changed from a flat directory to a hierarchical one, with a separate subdirectory for each category of device. For example, the location of disk device files is /dev/dsk, while raw disks are located in /dev/rdsk (see "Directory and File Changes" on page 87). For discussions on device-naming conventions, see "Device Naming Conventions" on page 61 and "Device Naming From a Developer's Perspective" on page 181.

File Systems

SunOS release 5.5 and SunOS release 4.x file systems are similar, but there are changes in the locations and names of system directories and files. There are also new file systems, new pseudo file systems, and one directory is not used.

Chapter 9, "File-System Administration," describes file system changes. System Administration Guide, Volume I describes file system concepts and administration in detail.

Changes

Some of the changes to file system locations and names are:

• The /dev directory has changed from a flat directory to a hierarchical one.
• The /etc directory contains system configuration information. Several files and subdirectories have been added, removed, or changed for SunOS release 5.5.
• The /etc/vfstab tab file replaces /etc/fstab.
• The /etc/lp directory replaces /etc/printcap.
• The SunOS release 5.5 /sbin directory contains the rc scripts used to alter system run levels as well as the rcs script used to initialize the system prior to mounting file systems.
• The SunOS release 5.5 /usr directory contains sharable files and executables provided by the system.
• The /var directory contains files that change sizes during normal operation. Several files and subdirectories in the /var directory have been added, removed, or changed for SunOS release 5.5.
• The /var/mail directory replaces /var/spool/mail.
• The /sys directory is no longer needed because the kernel is dynamically loaded.
• The terminfo database replaces termcap.
• The /RFS file system has been removed.
• The kernel is called unix in SunOS release 5.5, and the kernel modules are stored in the /kernel directory.

Pseudo File Systems

Pseudo file system types are logical groupings of files that reside in disk-based systems. The TFS pseudo file system is not included in SunOS release 5.5.

The pseudo file systems in SunOS release 5.5 are:

• CACHEFS pseudo file system - can be used to improve performance of slow devices such as CD-ROM.
• PROCFS pseudo file system - resides in memory and contains a list of active processes, by process number, in the /proc directory. See the proc(4) manual page.
• FDFS pseudo file system - provides explicit names for opening files using file descriptors.
• FIFOFS pseudo file system - contains pipe files that give processes common access to data.
• NAMEFS pseudo file system - is used mostly by STREAMS for dynamic mounts of file descriptors on top of files.
• SWAPFS pseudo file system - is the default swap device when the system boots or you create additional swap space.

Added File Systems

The following file systems are included in the SunOS release 5.5 directory structure:

• The optional /opt file system - can be used to store third-party or unbundled software. If /opt is not a separate file system, it may be a symbolic link to /usr/opt.
• The /vol file system - provides the default file system for the Volume Management daemon, vold(1M). See the volfs(7) manual page.

Kernel Configuration

Unlike SunOS release 4.x, the SunOS release 5.5 kernel is dynamically configured. This means that you no longer need to rebuild it manually when you make changes to the system configuration. The kernel consists of a small static core and many dynamically loadable kernel modules. Drivers, file

systems, STREAMS modules, and other modules are loaded automatically as needed, either at boot time or at run time. These modules are unloaded when they are no longer in use. The modinfo(1M) command provides information about the modules currently loaded on a system.

The modload(1M) and modunload(1M) commands are still available in this release, but they perform differently. These commands have more limited usage, and are no longer sufficient to correctly install a loadable driver onto the system. modunload is similar to the SunOS release 4.x command, but it includes the capability to unload all unloadable (and not busy) modules as the following example illustrates.

# modunload -i 0

Chapter 18, "System and Device Configuration," discusses these topics in more detail.

Kernel Layout

The contents of the kernel, which were formerly in a single file, /vmunix, are now contained in modules in a directory hierarchy. By default, the directory hierarchy is /kernel and /usr/kernel.

The directory search path for modules can be set by the moddir variable in the /etc/system file. See the system(4) man page in the man Pages(1M): System Administration Commands. Typically, /kernel/unix is the first portion of the kernel to be loaded. See the kernel(1M) manual page in the man Pages(1M): System Administration Commands.

The /kernel/drv directory is used for bootable devices and system-dependent software. The /usr/kernel/drv directory is used for all other drivers.

Automounting

SunOS 5.x supports automatic mounting for file systems shared through NFS. autofs runs in the background, mounting and unmounting remote directories on an as-needed basis, without user input. autofs starts automatically when a

system enters run level 3, or you can start it from a shell command line. See NFS Administration Guide for complete information on how to set up and administer autofs.

The following example shows that the /home/bugs directory was not mounted until it was accessed.

% mount | grep bugs % cd /home/bugs % mount | grep bugs /tmp_mnt/home/bugs on bugs:/export/home/bugs intr/remote on Fri Mar 4 16:16:00 1994

Whenever a user tries to access a remote file or directory (using the cd(1) command for example), autofs mounts the file system to which that file or directory belongs. This remote file system remains mounted for as long as it is needed. If the remote file system is not accessed for a certain period of time, it is automatically unmounted. No mounting is done at boot time, and the user does not need to know the superuser password to mount a directory; users need not use the mount and umount commands, although they are still available.

autofs works with file systems specified in NIS maps or NIS+ tables. These maps or tables can be maintained as NIS, NIS+, or local files.

autofs maps or tables can specify several remote locations for a particular file. This way, if one of the servers is down, the automounter can try to mount from another system. You can specify which servers are preferred for each resource in the maps by assigning each server a weighting factor.

By default, the SunOS system software automounts /home.

See "Mounting File Systems and autofs" on page 95 for more detailed information.

Admintool

One of the major changes affecting system administration between SunOS release 4.x and SunOS release 5.x is the availability of Admintool with OpenWindows. This tool employs a graphical user interface to simplify tasks, such as managing users, hosts, printers, and serial devices. These tasks can be managed on local systems if the right access has been set up.

Admintool applications enable you to manage the following:

• Local system database files such as aliases and netmasks
• User account information, including tasks such as adding users, modifying password aging features, and removing user account information
• Local and remote printer setup
• Terminal and modem setup

Using a graphical user interface (GUI) like Admintool to perform the administration tasks has the following benefits:

• It is faster than using numerous SunOS commands to perform the same tasks
• System files are updated automatically without the risk of making editing errors in important system files
• The application programs interact with appropriate system daemons and notify you when the two are out of sync

---

Note - You do not need to be root to start Admintool, but you do need to be a member in the sysadmin group (use the groups(1) command to display your groups). Running admintool as root will restrict your changes to the local system.

---

To display Admintool, type the following command in any window.

$ admintool &

Network Information Service Plus (NIS+)

---

Note - SunOS release 5.x does not support NIS. Clients that use the NIS or DNS naming service must either use the NIS binary compatibility package or continue to use the SunOS release 4.x NIS or DNS server.

---

NIS+ is the network information service for Solaris networks. NIS data can be shared with NIS+ and the services can be combined to some extent. All commands and functions that use NIS are prefixed by the letters yp, as in ypmatch(1) and ypcat(1). Commands and functions that use NIS+ are prefixed by the letters nis, as in nismatch(1) and nischown(1).

NIS+ is a name service built on top of the ONC transport-independent remote procedure call (TI-RPC) interface. NIS+ has significant benefits compared to NIS in the areas of security, performance, scalability, and administration. Some of the advantages of using NIS+ are:

• NIS+ shares data with the NIS environments, allowing a smooth migration.
• Domains are hierarchical; you can create subdomains.
• You can use the name service switch (/etc/nsswitch.conf) to set which name service a system will try to use first - NIS+, NIS, or DNS.
• You can use the Database Manager to make changes to NIS+ tables for adding, modifying, deleting, and searching for information.

See Chapter 14, "Using Name Services," in this guide and NIS+ Transition Guide, NIS+ and FNS Administration Guide, and NIS+ and DNS Setup and Configuration Guide for more information.

Print Subsystem

The print management commands have changed between SunOS release 4.x and the Solaris 2.5 operating environment. In the Solaris 2.5 operating environment, you can use command-line procedures or Admintool to set up printers, and you can use administrative commands or the PrintTool to control print jobs.

See Chapter 11, "Setting Up and Using Printers,"and System Administration Guide, Volume II for more information.

Users can accomplish the same basic tasks using the PrintTool or commands in a shell.

PrintTool

PrintTool is a software tool available through OpenWindows in the Solaris 2.5 user environment. It provides a graphical user interface through which a user can monitor printers and monitor and cancel print jobs.

Command Changes

The following list summarizes command changes:

• lp(1) replaces lpr and the /etc/printcap file

• lpstat(1) replaces lpq
• cancel(1) replaces lprm
• troff(1) requires a printer name
• TEX, pscat (C/A/T), and raster image filters are not available in Solaris 2.5

The lp service consists of several daemons, or processes, that monitor system work, a hierarchy of configuration files in the /etc/lp directory; and as a set of administrative commands.

Service Access Facility

The Service Access Facility (SAF) is the tool used for administering terminals, modems, and other network devices. In particular, the SAF enables you to:

• Add and administer ttymon and listen port monitors (using the sacadm command)
• Add and administer ttymon port monitor services (using the pmadm and ttyadm commands)
• Add and administer listen port monitor services (using the pmadm and nlsadmin commands)
• Administer and troubleshoot TTY devices
• Administer and troubleshoot incoming network requests for printing service
• Administer and troubleshoot the Service Access Controller (using the sacadm command)

The SAF is an open systems solution that controls access to system and network resources through TTY devices and local-area networks (LANs). The SAF offers well-defined interfaces that make it easy to add new features and configure existing ones.

The SAF is not a program. It is a hierarchy of background processes and administrative commands. The top-level SAF program is the SAC. The SAC controls port monitors that you administer through the sacadm command. Each port monitor can manage one or more ports.

You administer the services associated with ports through the pmadm command. While services provided through SAC may differ from network to network, SAC and the administrative programs sacadm and pmadm are not tailored to network types.

Table 2-1 illustrates the SAF control hierarchy. The sacadm command is used to administer the SAC, which controls the ttymon and listen port monitors.

Table 2-1

Function	Program	Description
Overall Administration	sacadm	Command for adding and removing port monitors
Service Access Controller	sac	SAF's master program
Port Monitors	ttymon listen	Monitors serial port login requests Monitors requests for network services
Port Monitor Service Administrator	pmadm	Controls port monitors' services
Services	logins; remote procedure calls; etc	Services to which SAF provides access

The services of ttymon and listen are in turn controlled by pmadm. One instance of ttymon can service multiple ports and one instance of listen can provide multiple services on a network interface.

See Chapter 12, "Managing Terminals and Modems," for more information.

Volume Management

Beginning with the Solaris 2.2 software, a new layer of software manages CD-ROM and diskette devices -- Volume Management. This software automates the interaction between you and your CD-ROMs and diskettes.

OpenWindows users will notice a slight change to the File Manager -- it has been modified to use Volume Management to provide immediate user access to CD-ROMs and diskettes with file systems on them. See the Solaris User's Guide for more information on File Manager's new features.

There are also several new commands to help you administer Volume Management on your system.

For more information, see "Using Volume Management," in Chapter 7, "Device Administration".