As you work in the SunOS release 5.7 environment, you will find similarities to SunOS release 4. However, you will also notice some differences. The rest of this guide focuses on procedures, tools, commands, and concepts that have changed between releases.
This chapter is an overview of some of the principal changes. It provides background information for topics in subsequent chapters. Some topics receive sufficient coverage here, while others require more in-depth technical background. In the latter case, the text directs you to a chapter that more fully describes the changes.
The list below describes four clusters. Note that as you progress through the list, each cluster contains the software of the preceding cluster plus additional software.
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 7 operating environment. Compilers and debuggers are not included in the Solaris 7 operating environment.
For more information about this section's topics, see System Administration Guide, Volume I.
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.
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.
The patchadd(1M) and patchrm(1M) commands are used to install and remove patches from a Solaris 2 system. You can add one or more patches to a system, client, service, or net install image.
A single range of contiguous blocks or a physical subset of a disk is known as a disk partition in the SunOS release 4 software. In the SunOS release 5 software, a physical subset of a disk is known as a disk slice. Before you can create a file system on a disk, you must format and divide it into slices. This is usually done when the Solaris release is installed using the Solaris 2 installation program. See System Administration Guide, Volume I if you need to install and format a disk after installation.
In some Solaris documentation, Solaris slices are still referred to as "partitions". The Solaris 2 documentation distinguishes between fdisk partitions (for Intel systems) and the divisions within an fdisk partition, referred to interchangeably as slices or partitions.
See System Administration Guide, Volume I for information about Solaris fdisk partitions.
A slice can be used as a raw device for swap space or to hold one and only one UFS file system, unless you are using a product like Solstice DiskSuiteTM. Table 2-1 describes how disk slices can be set up on each Solaris 2 platform.Table 2-1 Slice Differences on Platforms
The whole disk is devoted to the Solaris operating environment.
The disk is divided into four fdisk partitions, one per operating environment.
The disk is divided into eight slices, numbered 0-7.
The Solaris fdisk partition is divided into 10 slices, numbered 0-9. Only 0-7 can be used to store user data.
See System Administration Guide, Volume I for a description of customary disk slice assignments for each platform.
A UFS file system is created 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.
Figure 2-1 shows the relationship between disk slices and cylinder groups.
SunOS release 5.7 device names make it easier to infer certain device characteristics from a device name. SunOS release 4 systems convey type rather than device attributes, which makes it difficult for programs and scripts to derive necessary information about devices. SunOS release 5.7 conventions are slightly different from AT&T SVR4 device names because SunOS release 5.7 allows only eight user-configurable slices on a disk.
In addition, special device files are now stored in the hierarchical /devices directory, with symbolic links to the hierarchical /dev directory, which is used by administrators and users to access devices. The /dev directory contains subdirectories, such as /dev/dsk/*, used to access disk devices, and /dev/rdsk/*, used to access raw disk devices. For more information, see "Device Naming Conventions". For discussions on device naming conventions, see "Device Naming From a Developer's Perspective".
SunOS release 5.7 and SunOS release 4 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.
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.
The /etc/vfstab tab file replaces /etc/fstab.
The /etc/lp directory replaces /etc/printcap.
The SunOS release 5.7 /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.7 /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.
The /var/mail directory replaces /var/spool/mail.
The terminfo database replaces termcap.
The SunOS release 5.7 pseudo file systems are:
CACHEFS pseudo file system - can be used to improve performance of slow devices such as a CD-ROM drive.
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) man 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 - used mostly by STREAMS for dynamic mounts of file descriptors on top of files.
SWAPFS pseudo file system - the default swap device when the system boots, or you create additional swap space.
The following file systems are included in the SunOS release 5.7 directory structure:
The optional /opt file system, which 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.
Support for the RFS file system type has been removed.
Unlike in the SunOS release 4 software, the SunOS release 5.7 kernel is dynamically configured. This means that you no longer need to rebuild it manually when you make changes to the system configuration.
Starting with release 5.5 of the SunOS software, the kernel and its modules were separated into platform-independent and platform-dependent objects. The platform-independent kernel consists of a small static core, called /kernel/genunix, and its dynamically loadable kernel modules are stored in the /kernel and /usr/kernel directories if they are platform independent, and /platform and /usr/platform if they are platform independent. See System Administration Guide, Volume I for a description of the platform-dependent directories and their contents.
Drivers, file systems, the STREAMS module, 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. The modunload(1M) command is similar to the SunOS release 4 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.
The contents of the kernel, which were formerly in a single file, /vmunix, are now contained in modules in a platform-independent and platform-dependent directory hierarchy. By default, the directory hierarchy is:
The directory search path for modules can be set by the moddir variable in the /etc/system file. Typically, /kernel/genunix is the first portion of the kernel to be loaded. See system(4) and kernel(1M) for more information.
A new version of the automounter, called AutoFS, has been included. In the SunOS release 4 releases, the automounter mounted everything under /tmp_mnt and used symbolic links to redirect the lookups. AutoFS allows for file systems to be mounted in place (for instance, /home).
In SunOS release 4, the maps for the automounter were named auto.master and auto.home. For Solaris 7, these maps have been renamed to auto_master, auto_home, and so on. The NIS+ name service, which is included with the release, requires this change. A default copy of these maps is included in the release, so that the AutoFS service is started when the system is booted. The SunOS release 4 releases did not include the maps, so additional installation steps were required.
The Solaris 7 release provides the ability to select the name service that is being used through /etc/nsswitch.conf. The automount entry can be changed to select local files, NIS+, NIS, or some combination of these.
Earlier releases supported a home directory naming convention like: /home/server/login. With the AutoFS maps it is much easier to use /home/login for each entry. This new naming convention also provides for location independence. The old convention can still be used, but once a transition to using the AutoFS maps has been made, it will be easier to administer the shorter paths.
/net - for mounting file systems from a known host
/home - for mounting the home directory of a known user
/xfn - for mounting file systems that support the X/Open XFN standard
On home directory servers, the actual home directories should be moved to /export/home rather than /home, so that they do not conflict with the automounter directory structure. This also means that you cannot mount file systems on /home while the automounter is running.
The AutoFS software now has two programs. The first program is automount that runs at boot time to establish AutoFS mount points. This command can also be run anytime by superuser to change the mount points. The second command is automountd, which is a stateless daemon that answers AutoFS file system mount and unmount requests. These two programs replace the SunOS release 4 automount daemon.
The automount daemon is now fully multi-threaded. Multiple automatic mount requests can be serviced concurrently, which makes AutoFS more reliable. In short, one mount request could block connecting to a slow server, while a second request is processed without waiting.
The Solaris 7 release supports browsability of indirect AutoFS maps. All mountable entries under an AutoFS mount point (for example, /home) are now visible without the overhead of mounting them first.
Also provided is improved on-demand automounting of hierarchically related file systems. Previous releases would automount an entire set of file systems if they were hierarchically related (for example, /net/server) even if only one of the file systems was referenced. The file system that is referenced is dynamically mounted without mounting all of the other file systems in the hierarchy. Other file systems are mounted when they are individually referenced.
The version of sendmail that is included on the release is Version 8 compatible. The new version fixes some security holes and includes several improvements to Version 5. Several extensions to the standard BSD release have been added, including name service switch and NIS+ support.
The mailbox spooling directory has been moved from /var/spool/mail to /var/mail. A new directory, /var/mail/:saved, is used for creating locks and temporary files by the mailx program. Also, the mail configuration files are now all located in /etc/mail. The new directory includes the aliases and the sendmail.cf files.
The mailbox locking mechanism has been enhanced so that Solaris 7 clients can safely mount mailboxes from both Solaris 2 and SunOS release 4 mail servers. This enhancement eases administration of mail, especially in large sites.
In the Solaris 7 release, /usr/bin/mailx supersedes /usr/ucb/mail. The mailx program has been enhanced to behave the same way as the SunOS release 4 version of /usr/ucb/mail. The /usr/ucb/mail file is now a symbolic link to /usr/bin/mailx.
In SunOS release 4 releases, a program called sendmail.mx was used in DNS sites to access mail exchange records. The new version of sendmail includes the needed functionality and can be configured through /etc/nsswitch.conf.
Mail Administration Guide describes the administration of sendmail.
One of the major differences between SunOS release 4 and SunOS release 5.7 that affects system administration is the availability of Admintool to perform basic system administration tasks. This tool employs a graphical user interface to simplify tasks, such as managing users, hosts, printers, and serial devices, on local desktop systems.
Admintool applications enable you to manage the following tasks on a local system:
System database files such as aliases and netmasks
User account and group information, including tasks such as adding users and groups, modifying password aging features, and removing user account information
Printer setup for local and remote printers
Terminal and modem setup
Using a graphical user interface (GUI) like Admintool to perform 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
The application programs interact with appropriate system daemons and notify you when the two are out of sync
You do not need to be root to start Admintool but you do need to be a member in the sysadmin group (GID=14). Use the groups(1) command to display your group membership.
$ admintool &
NIS+ is a name service built on top of the ONC transport-independent remote procedure call (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.
NIS+ enables you to create and maintain an enterprise-wide name service, even across geographically separated sites connected by WAN links.
You can use the NIS+ backup and restore feature to quickly and easily preserve your name space data set. This feature can also be used to quickly bring additional replica servers online.
Starting with the Solaris 2.6 release, the printing software provides a centralized environment for setting up and managing client access to printers on a network. The Solaris printing software contains these components:
The print client software, previously only available with the Solstice AdminSuiteTM set of administration tools, provides the ability to make printers available to print clients using a name service.
Admintool, a graphical user interface used to manage printing on a local system.
The LP print service commands, a command line interface used to set up and manage printers that also provides functionality above and beyond the other print management tools.
See Chapter 11, Managing Printers, Terminals, and Modems, and System Administration Guide, Volume II for more information.
PrintTool is a software tool available in the Solaris 7 user environment. It provides a graphical user interface within OpenWindows or CDE through which a user can monitor printers and monitor and cancel print jobs.
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 so you can easily 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-2 illustrates the SAF control hierarchy. The sacadm command is used to administer the SAC, which controls the ttymon and listen port monitors.Table 2-2 SAF Functions and Associated Programs
Command for adding and removing port monitors
Service Access Controller
Monitors serial port login requests
Monitors requests for network
Controls port monitor services
calls, and so on
Services to which SAF provides
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 11, Managing Printers, Terminals, and Modems for more information.
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 CDs and diskettes.
CDE OpenWindows File Manager has been modified to use Volume Management to provide immediate user access to CDs and diskettes with file systems on them. See OpenWindows 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".