Part I Transition Information for Users and System Administrators

You can use this part of the guide to help install Solaris 7 software and to understand changes to the local computing environment and to routine tasks.

Chapter 1 Introduction

The Solaris^TM operating environment enhances your system's capabilities with powerful tools and features. This introduction discusses the benefits of migrating to the Solaris operating environment and summarizes the principal differences between SVR4 and the Solaris operating environment.

• "Advantages of Migrating to the Solaris Operating Environment"

• "Comparison of SVR4 and the Solaris Operating Environment"

Advantages of Migrating to the Solaris Operating Environment

The UNIX® standard, SVR4, accommodates the leading UNIX variants (System V, BSD, SunOS^TM, and XENIX), uniting the majority of the installed base of UNIX users. The Solaris operating environment, based on SVR4, gives software developers, system administrators, and end users the benefits of a standard operating system including broad compatibility, a growth path, and reduced time to market. It also delivers a functional and powerful product reflecting years of refinement. Among the many advantages the Solaris operating environment provides are portability, scalability, interoperability, and compatibility.

Although the foundation of the Solaris operating environment is based on SVR4, extensive functionality has been added in areas such as symmetric multiprocessing with multithreads, real-time functionality, increased security, and improved system administration.

The Solaris operating environment offers the following features:

• SunOS release 5.7, a 64-bitSolaris operating environment based on UNIX System V Release 4 (SVR4) for UltraSPARC^TM systems and a 64-bitSolaris application environment for SPARC^TM and IA platforms.

• Cross-functional compatibility that enables SunOS release 5.7 software to run on SPARC systems as well as IA CPUs.

• Industry standards including SVR4 standards and the ONC^TM family of networking protocols.

• Graphical user interface (GUI) in the OpenLook Window Manager.

• Common Desktop Environment, a desktop environment that provides windows, workspaces, controls, menus, and front panel access to Mail, File Manager, Printers, Image Tool, Calendar Manager, and other applications.

• Calendar Manager, a time management application that displays appointments and ToDo items at a glance and offers a multibrowse feature that makes scheduling among a group.easy

• File Manager, a graphical and intuitive way to navigate to local and remote file systems.

• Image Tool, which enables you to load, view and save images of over 40 different formats.

• Audio, a new Motif-based audio application for playing and recording AU, WAV, and AIFF files.

• Motif Admintool^TM, the base for local system administration.

• Installation GUI for ease of installation and update.

• Log-based file systems on servers.

• Advanced architecture that includes fully symmetric multiprocessing and sophisticated multithreading.

• Real-time priority scheduling and a fully pre-emptible kernel, providing the benefits of open systems while meeting the requirements of control applications.

• Network Information Services Plus (NIS+), an upward-compatible version of the NIS name service with simpler hierarchical administration, improved security, and faster updates.

• Standards conformance for application developers interested in the benefits of application portability.

• Multimedia Mail, for sending messages that incorporate audio, graphics, and embedded files.

• Java^TM Virtual Machine, provides access to the Java platform for the Solaris operating environment.

• WebNFS^TM, makes it possible to make a file system accessible through a Web browser.

• AnswerBook2^TM viewer, online documentation that uses a web browser interface.

Portability, Scalability, Interoperability, and Compatibility

The Solaris operating environment is portable, scalable, interoperable, and compatible.

Portability

The SunOS 5.7 product is portable across multiple vendor platforms. Software conforming to an application binary interface (ABI) runs as shrink-wrapped software on all vendor systems with the same microprocessor architecture. This enables application developers to reduce software development costs and bring products to market quickly, and enables users to upgrade hardware while retaining their software applications and minimizing conversion costs.

Scalability

Over time, applications become more widely used and require more powerful systems to support them. To operate in a growing environment, software must be able to run in a wide power range and must be able to take advantage of the additional processing power. The Solaris operating environment runs on machines of all sizes, from laptops to supercomputers.

Interoperability

Heterogenous computing environments are a reality today. Users purchase systems from many vendors to implement the solutions they need. Standardization and clear interfaces are critical to a heterogeneous environment, enabling users to develop strategies for communicating throughout their network.

Compatibility

Computing technology continues to advance rapidly, but the need to remain competitive requires vendors to minimize their costs and to maximize their investments. As new technology is introduced, there is a need for the existing software investment to be preserved.

Advantages for Large Organizations

The Solaris operating environment provides a number of sound business reasons for transitioning to an industry-standard-based UNIX operating system. Application development and maintenance costs are lower, and application portability is enhanced.

Comparison of SVR4 and the Solaris Operating Environment

This section describes the main differences between SVR4 and the Solaris operating environment. It points out features that the Solaris operating environment includes that are not available in SVR4 and a few SVR4 features that are not available in the Solaris operating environment.

Additional Features in the Solaris Operating Environment

The Solaris operating environment offers value-added components in addition to the SVR4-based operating system. These make computing easier and create new opportunities for users, system administrators, and developers.

In general, the merge of established UNIX variants into SVR4 and the Solaris operating environment was done by consolidating the existing functionality while maintaining compatibility for existing applications. As a result, features and commands were added or withdrawn in some cases.

Features for the User

For users, the Solaris operating environment incorporates a suite of powerful DeskSet^TM applications to enhance personal productivity. All DeskSet applications rely on the drag-and-drop metaphor, enabling users to carry out complex UNIX commands with a mouse. Some of the features are:

• Workspace manager. Provides basic window management services (open, close, move, and so on), as well as tools that enables user to customize their workspace.

• Desktop integration services. These include ToolTalk^TM, drag and drop, and cut and paste, providing the foundation that enables applications to seamlessly integrate with one another.

• Graphics libraries. These include XGL^TM, Direct Xlib^TM, Solaris PEX^TM, and XIL^TM, providing support for 2D and 3D graphics applications.

• Calendar Manager. A time management application that displays appointments and ToDo items for a day, week, or a month at a glance. It also contains a multibrowse feature that makes scheduling meetings among a group of users easy. Multiple calendars can be overlaid simultaneously to determine convenient meeting time slots at a glance.

• Image Tool. Enables you to load, view and save images of over 40 different formats including PICT, PostScript^TM, TIFF, GIF, JFIF.

• Other tools include a print tool, audio tool, shell tool, clock, and text editor.

Features for the System Administrator

For system administrators, the Solaris operating environment offers a variety of new tools to simplify the administration of a distributed computing environment. These include:

• A 64-bit Solaris application and operating environment (SPARC platforms only) for developing 64-bit applications, allowing new 64-bit applications to manipulate large address spaces, and running a larger number of existing 32-bit applications.

• Device information. Administrators can use these optional utilities to obtain information about installed devices including device names, attributes, and accessibility. Administration can be simplified by creating device allocation pools, a feature not previously found in UNIX systems.

• File system administration. These utilities enable administrators to create, copy, mount, debug, repair, and unmount file systems; create and remove hard file links and named pipes; and manage volumes.

• Interprocess communication. Two interprocess communication utilities create, remove, and report on the status of the system's interprocess communication facilities (message queues, semaphores, and shared memory IDs). They provide information helpful in tuning the system.

• Process management. The process management utilities help you control system scheduling. Using these utilities, you can generate reports on performance, logins, disk access locations; and seek distances to better tune system performance. In addition, you can change the system run level, kill active processes, time the execution of commands, and change the default scheduling priorities of kernel, timesharing, and real-time processes.

• System accounting. The accounting utilities enable system administrators to track system usage by CPU, user, and process for better resource allocation.

• System information. These utilities report system memory and system configuration. The system administrator can use the utilities to change the names of the systems and the network node.

• User and group management. With these utilities, a system administrator can create and delete entries in group and password databases, specify default home directories and environments, maintain user and system logins, and assign group and user IDs. The utilities support both primary and supplementary user groups.

• Admintool. Admintool, which runs under the OpenWindows^TM environment, provides system management facilities to help add hosts, manage the network, and perform many other routine tasks on local systems.

• Auto configuration. The Solaris operating environment has a dynamic kernel, which means that it loads drivers and other modules into memory when the devices are accessed. You no longer need to rebuild the kernel after installation, nor must you add or remove drivers.

• Network Information Services Plus (NIS+). An upward-compatible version of the NIS name service with simpler hierarchical administration, improved security, and faster updates.

• Installation. The Solaris operating environment has an install GUI to ease installation or upgrades. Automatic installations and upgrades are also possible over the network.

• Security. The automated security enhancement tool (ASET) is a utility that improves security by allowing system administrators to check system file settings including permissions, ownership, and file contents. ASET warns users about potential security problems and, where appropriate, sets the system file permissions autonomically according to the specified security level.

• AnswerBook2 man page format. Man pages are available in AnswerBook2 (SGML), rather than AnswerBook format. This provides improvements in navigation and links to man pages directly from other AnswerBook2 documents.

Features for the Developer

For application developers, the Solaris operating environment includes a variety of toolkits and features to simplify the development of complex applications with graphical user interfaces.

• Multithreaded (MT) kernel. MT provides for a symmetric multiprocessing kernel where multiple processors can execute the kernel at the same time. Applications can be structured as several independent computations rather than as one thread of control. Independent computations execute more efficiently because the operating system handles the interleaving of the independent operations. This benefit of multithreading is known as application concurrency.

• STREAMS. STREAMS is a flexible framework for character input and output (I/O) that has been implemented throughout SVR4. It is easily customized for applications.

• Expanded fundamental types. ID data types (uid, pid, device IDs, and the like) and certain other data types are expanded to 32 bits. This improves the scalability of the operating system in large systems and for use in large organizations.

• Device driver interfaces. There are three types of interfaces for Solaris device drivers: device kernel interface (DKI), device driver interface (DDI), and the device driver interface/device kernel interface (DDI/DKI). DDI/DKI conformance means that device drivers have better source and binary compatibility across SPARC platforms so developers can write one driver to support a peripheral on all SPARC platforms.

• Automatic device driver loading. This makes drivers easier to install and devices easier to access.

• Device configuration library. The libdevinfo library, used to obtain device configuration information, has been made more robust and comprehensive in Solaris 7 software. For more information, see the man page libdevinfo(3).

• Dynamic linking. The Solaris application environment supports static and dynamic linking of libraries. The linker uses the version numbers of the libraries and executables to link applications with the proper libraries, routines, and interfaces.

• Operating environment. Supports a 32-bit application and operating environment for developing 64-bit applications and running a large number of existing 32-bit applications. Also supports a 64-bit application and operating environment for developing 64-bit applications, allowing new 64-bit applications to manipulate large address spaces and running a large number of existing 32-bit applications.

• WebNFS Software Development Kit. The WebNFS Software Development Kit (SDK) provides remote file access for Java applications using WebNFS. Since it implements the NFS protocol directly, it requires no NFS support on the host system.

SVR4 Features Excluded From the Solaris Environment

In a few instances, features in SVR4 were not include in the Solaris operating environment. These features are specific to AT&T hardware, or features included primarily for backward compatibility with SVR3 features and are, therefore, of little value to SunOS users.

The Solaris operating environment does not include the System V file system and associated utilities because of their limitations compared to the UNIX file system. The SVR4 boot file system was not included because of its maintenance burden when compared to the SunOS traditional boot model.

The generic AT&T SVR4 model for device auto-configuration and for rebuilding kernels was replaced with a fully dynamically configurable kernel better suited to the needs of present and future users of SPARC systems.

Because there is no installed base of SPARC XENIX programs, the SPARC release of the Solaris operating environment does not include compatibility for XENIX applications.

The Solaris operating environment does not include the AT&T SVR4 sysadm utility. Because the sysadm menu utility was designed primarily for use with terminal devices on freestanding systems, GUI tools are used instead to simplify administration of distributed systems across a network. The Solaris operating environment provides the utilities and configuration directories that underlie the SVR4 sysadm utility but not the sysadm utility itself.

Chapter 2 Overview of Major Changes

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.

• "Software Packages and Clusters"

• "Disk Slices (or Partitions)"

• "Device Naming"

• "File Systems"

• "Kernel Configuration"

• "Automounting"

• "Admintool"

• "Network Information Service Plus (NIS+)"

• "Print Subsystem"

• "Service Access Facility"

• "Volume Management"

Software Packages and Clusters

Solaris 7 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 plus additional software.

• Core System Support is the minimum software configuration; it contains only the software necessary to boot and run the Solaris 7 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 7 operating environment. Compilers and debuggers are not included in the Solaris 7 operating environment.

• Entire Distribution contains the entire Solaris 7 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

Patch Administration

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.

See patchadd(1M) and patchrm(1M) for more information.

Disk Slices (or Partitions)

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 DiskSuite^TM. Table 2-1 describes how disk slices can be set up on each Solaris 2 platform.

See System Administration Guide, Volume I for a description of customary disk slice assignments for each platform.

Cylinder Groups

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.

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 Disk Slices and Cylinder Groups

Device Naming

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

File Systems

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.

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

Changes to File System Locations and Names

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 /sys directory is no longer needed because the kernel is dynamically loaded.

• The terminfo database replaces termcap.

• The SunOS release 5.7 core kernel is called genunix, and the kernel modules, including 64-bit versions, are stored in the /kernel, /usr/kernel, /platform, and /usr/platform directories.

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 the SunOS release 5.7 software.

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.

Added File Systems

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.

• The /vol file system, which provides the default file system for the Volume Management daemon, vold(1M). See the volfs(7) man page.

Removed File Systems

Support for the RFS file system type has been removed.

Kernel Configuration

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.

Kernel Layout

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:

• /kernel

• /usr/kernel

• /platform

• /usr/platform

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.

Automounting

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.

The following paths were reserved for use by AutoFS:

• /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.

See "Mounting File Systems and autofs" for more detailed information. Also, NFS Administration Guide describes how to use AutoFS.

Mail Administration

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.

To further support NIS+, a new command, aliasadm, has been included. The command aids in the administration of NIS+ alias lists.

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.

Admintool

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

• Package management

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.

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

$ admintool &

Network Information Service Plus (NIS+)

NIS+ is the preferred network information service for Solaris networks. Solaris networks can also use NIS either as an alternative to NIS+ or as a supplement to NIS+.

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.

• You can use the name service switch (/etc/nsswitch.conf) to set which name service a system will try to use first: NIS+, NIS, /etc, or DNS.

• You can use AdminSuite to make changes to NIS+ tables for adding, modifying, deleting, and searching for information.

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

See Chapter 13, Using Name Services, in this guide and NIS+ Transition Guide and NFS Administration Guide for more information.

Print Subsystem

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 AdminSuite^TM 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.

• The Solstice AdminSuite Print Manager, a graphical user interface used to manage printers in a name service environment, is available starting in the Solaris 2.6 release.

See Chapter 11, Managing Printers, Terminals, and Modems, and System Administration Guide, Volume II for more information.

Users can accomplish the same basic tasks using PrintTool or commands in a Shell Tool window.

PrintTool

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.

Command Changes

The following list summarizes command changes:

• lp(1) replaces lpr

• 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 the Solaris 7 environment

The lp service consists of several daemons, or processes, that monitor system work, a hierarchy of configuration files in the /etc/lp directory, and 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 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.

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.

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

Chapter 3 Converting a SunOS Release 4 System to the Solaris 7 Environment

Converting a SunOS release 4 system to the Solaris 7 environment is a three-phase process that includes pre-installation (backing up data), installing the Solaris environment, and post-installation (restoring data).

This chapter provides information about the pre-installation and post-installation phases for a single system or an entire network. See Chapter 10, Setting Up a Solaris 7 Server to Support SunOS Release 4 Diskless Clients, for information about creating an environment that serves both Solaris 7 and SunOS release 4 clients.

• "What's New About Installing"

• "What to Do Before You Install Solaris Software"

• "Backing Up Files and File Systems Before You Install"

• "Installing Solaris Software"

• "Restoring Files and File Systems After You Install"

What's New About Installing

The Solaris 7 environment introduces a number of changes in the way you install software on systems, which makes it different than installing the SunOS release 4 software. These include:

• The Solaris 7 software is distributed on compact disc (CD) only. This means you must have access to a CD-ROM drive before you can install the software. For systems without a local CD-ROM drive, you can set up a system that has a CD-ROM drive to act as an install server on the network. For more information about network installations, see Solaris Advanced Installation Guide.

• The Solaris 7 software is bundled into modules called packages. You can select which packages to install on your system and control the amount of space each installation requires.

  Also, related packages are grouped into clusters. This means that you can select a cluster to install without having to select each package separately.

• Solaris 7 installation also provides a set of software groups, which are groups of packages and clusters for typical users (for example, there is an end-user software group). You can select a software group to get systems running without selecting individual packages and clusters. This can be useful when you are first installing the Solaris 7 software in a limited environment for testing. You can add or remove packages later as you gain more experience with the system.

• The Solaris 7 environment includes architecture-specific kernels rather than the generic kernel configuration provided in earlier SunOS software releases. You will find the installed kernel in /kernel instead of /vmunix.

• The Solaris 7 installation program guides you step-by-step through the installation process.

• The Solaris 7 environment provides custom Solaris JumpStart^TM technology to automate installations. This can save time when you need to install many systems. For more information, see Solaris Advanced Installation Guide.

What to Do Before You Install Solaris Software

Converting a SunOS release 4 system to the Solaris 7 software involves more than just running the Solaris installation program and loading the software. Usually, there is data on the SunOS release 4 system that needs to be transferred to a Solaris 7 system. This data may be full file systems, such as /home, or locally customized system files, such as /etc/hosts or /etc/passwd.

No matter how you plan to handle the data transfer, you should back up all disk partitions by doing full dumps before you begin the installation process. Because the device naming conventions are different in the Solaris 7 operating environment, you might inadvertently choose the wrong disk when you install the Solaris 7 software. Backing up the file systems before you begin the installation procedure offers some protection should this occur. For information about device naming conventions, see "Device Naming Conventions".

Note about file system formats:

• If the Solaris 7 Extended Fundamental Types (EFT) are not used, the SunOS release 4 file system format is upwardly compatible with, and in some cases identical to that used in, the software.

• If you are running SunOS release 4.1.1 with QuickCheck or Backup Copilot^TM utilities, or if you have a SunOS release 4.1.2 system, the file system formats are identical.

• If you are running SunOS 4.1.1 software without QuickCheck or Backup Copilot utilities, SunOS 4.0.x, or SunOS 4.1 software, the file systems are upwardly and backwardly compatible, although not identical in all cases.

Saving Disk Partition Information

Before you begin the installation process, you should print a copy of the system's existing disk partitions. It can serve as a reference for many decisions that are made about configuring the Solaris 7 system. The following procedure is one way to obtain the disk partition information.

1. Obtain the names of the disks attached to the system.

   To obtain the names of the disks attached to the system, use the format(8) command.

2. Save the disk partition information.

   To obtain the partition information encoded on each disk, use the dkinfo(8) command. You can pipe the output to a printer or to a file that you can save to another system.

   ---

   Note -

   Using the previous command provides you with information only on the configured partitions. All nonconfigured partitions are displayed with the message: "No such device or address."

   ---

Saving File System Information

The mappings between file system names (for example, /usr, /home) and device names (for example, /dev/sd0g) reside in the configuration file /etc/fstab. Before proceeding, you should make a printed copy of the /etc/fstab file to help you construct the Solaris 7 file.

Saving Metadevice Configuration Information

Use this section only if you are upgrading a system running the SPARCserver^TM Manager or Solstice DiskSuite unbundled products. (These products are used to mirror, concatenate, or stripe multiple disks.)

To upgrade your system without this product, you have to modify your multiple-partition configurations to use single partitions. In particular, a concatenated or striped file system must be reorganized onto a single disk, and partitions and mirrors can no longer be used.

If the system is running SPARCserver Manager or Solstice DiskSuite utilities, you should save the metadevice configuration information before installing Solaris 7 software. This enables you to recover the state of the metadevices when you install Solaris 7 software, and serves as a reference as you construct the list of disks attached to your system.

1. Use the metastat(8) command to save information, as in the following example.

   # /etc/metastat -p | lpr

2. Save the output of the metadb(8) command.

   For example.

   # /etc/metadb -i | lpr

   The output of metadb tells you the state of the database configuration information. This information is necessary to reconstruct the state databases if you reinstall the Solstice DiskSuite product.

Determining What To Back Up

You should create a list of the SunOS release 4 files and file systems that you want to back up and restore after installing Solaris 7 software.

Making a List of System Components to Back Up

Make a list of all the system components in the existing SunOS release 4 environment and decide which are critical to the user's system. Consider:

• Locally developed applications

• Any unbundled software products

• Third-party applications

• Third-party peripheral devices and drivers (8 mm tape drives and SBus cards, for example)

Making a List of Files and File Systems to Back Up

Use the following guidelines to make the list of file systems to save:

• As a general rule, do not transfer entire file systems containing "system" files (for example, the /usr or / file systems).

• Do not save temporary file systems, such as /tmp.

• Do extract and transfer the data files that have changed locally or those on which the server depends for administrative data, such as some /etc files (for example, /etc/hosts), exported file systems (use the exportfs command to list them), and /tftpboot directory, which you should save as a safety precaution.

• Do completely preserve file systems containing only locally generated data, such as spool and user home directories.

• Save file systems that contain information about clients if you are migrating a server for SunOS release 4 clients. Typically, /export is such a file.

Making a List of SunOS System Configuration Files to Back Up

There are a number of SunOS release 4 system configuration files that can be merged or converted for the Solaris platform. Use the example list that follows to help select the system configuration files you want to back up.

The list contains suggestions. You should study the items in the list carefully and add or delete files depending on the configuration at your site. For example, if you have special files in directories from third-party software vendors, you may need to save them.

If the system is a NIS master server, you should save all the files that reside in the NIS master directory (for example, /etc). Additionally, save any other master files that you added to NIS. Examples of files to back up include:

• ./.cshrc

• ./.profile

• ./.login

• ./.logout

• ./.rhosts

• ./etc (if the system is a NIS client or has no name service)

• ./var/spool/calendar

• ./var/spool/cron

• ./var/spool/uucp

• ./var/nis (if the system is a NIS master server)

• Boot programs in./tftpboot

Determining Disk Space Requirements

Make a list of how much disk space each file system that you want to move to the Solaris 7 upgrade uses. Refer to this list when installing the Solaris 7 software, since you can partition disk space for your SunOS release 4 file systems when running the Solaris 7 installation program.

Deciding the Order of Installation for Networks

If you are converting a network of SunOS release 4 systems to the Solaris 7 software, decide the order of the systems to convert so that you do not inconvenience for the users. For example, you might want to convert all client systems before you convert any servers. The first system you convert should be a standalone system with a locally attached CD-ROM drive.

For a while, you will probably manage a network consisting of both SunOS release 4 and Solaris 7 systems, and part of your planning should involve determining priorities. For example, you may want to convert one domain and use it for system administration testing and for porting internally developed applications before you convert the entire network environment.

Backing Up Files and File Systems Before You Install

Once you decide which files or file systems you need to back up from the SunOS release 4, you can use the standard commands and procedures given in the SunOS release 4 documentation to do backups. The command you use depends on whether the tape drive is local or remote. No matter how you plan to handle the data transfer, it is still a good idea to back up all disk partitions by doing full dumps before you begin the installation process.

Installing Solaris Software

Install the Solaris 7 software on the server or standalone system using the software installation procedures given in Solaris 7 (SPARC Platform Edition) Installation Library or Solaris 7 (Intel Platform Edition) Installation Library. These are also known as the Start Here cards.

Preserve Option

The Solaris 7 Interactive Installation program has a preserve screen that enables you to preserve existing file systems during installation. This is a good way to preserve any SunOS release 4 file systems so you do not have to restore them.

If you cannot preserve a SunOS release 4 file system or you choose not to (because you want to change how the system's disks are partitioned), you should create new file systems with sufficient disk space for the SunOS release 4 file system that you want to restore (using the disk space requirements you recorded earlier). Then you can restore the SunOS release 4 file systems into the new file systems after Solaris is installed.

Restoring Files and File Systems After You Install

This section describes issues related to restoring SunOS release 4 files and file systems you backed up before installing the Solaris 7 software.

Restoring SunOS Release 4 File Systems and User Files

You can restore the SunOS release 4 file systems that you could not, or chose not to, preserve into the new file systems you created during the Solaris 7 installation. For information about backup and restore procedures, see System Administration Guide, Volume I.

Before proceeding make sure that the target slice is large enough to accommodate the file system being restored.

Restore any SunOS release 4 user files that you backed up and copy them to the new system.

Restoring SunOS Release 4 System Configuration Files

First, you must restore the SunOS release 4 system configuration files to a temporary directory on the Solaris 7 system. After the information is back on the system in the temporary directory, you need to make it available in the Solaris 7 operating environment. Some of the data can be merged into the files, while some types of data must be converted to new formats.

The system's configuration defines which files you need to work with. Complete the restore by merging or converting files as follows:

• Systems with no name service: If the system has no name service, merge or convert all the relevant system files located in /etc and /var.

• Systems that are NIS clients: If the system is a NIS client, merge or convert only the local system configuration files located in /etc and /var that are not provided via the NIS name service.

• Systems that are NIS master servers: If the system is a NIS master server, merge or convert all the files that reside in the NIS master directory (for example, /etc). Additionally, update other local configuration files in /etc and /var.

Files to Merge

To make data from any of the following files available, merge the changes into the Solaris 7 version of the same file. Note, however, that not all of these files were modified on the SunOS release 4 system. Identify files that were changed on the SunOS release 4 system and merge these only. As you read the list, note that some of the file names are slightly different. For example, /etc/auto.* files are now /etc/auto_*.

The following is an example list of the SunOS release 4 files backed up using the instructions in the first part of this chapter. These files are candidates for merging into the Solaris 7 operating environment. See Appendix D, System Files Reference Table, to examine SunOS release 4 files for changes.

• All automounter maps, including /etc/auto.master

• /etc/aliases

• /etc/bootparams

• /etc/ethers

• /etc/hosts

• /etc/format.dat

• /etc/inetd.conf

• /etc/netmasks

• /etc/networks

• /etc/protocols

• /etc/publickey

• /etc/rpc

• /etc/services

• /etc/hosts.equiv

• /etc/remote

• /.cshrc

• /.profile

• /.login

• /.logout

• /.rhosts

• /var/spool/cron

• /var/spool/mail

• /var/spool/calendar

• /var/spool/uucp

Files to Convert

Many system files, such as the /etc/fstab file, have been replaced and do not exist under the Solaris 7 operating environment. Information from these files must be extracted and manually converted in the Solaris 7 environment. See Appendix D, System Files Reference Table, to examine SunOS release 4 files for changes.

Do not restore operating system executable files (such as system commands in /usr/bin) from the SunOS release 4 system to your system after installing the Solaris 7 software.

You must change the following files before merging the data onto the Solaris 7 system:

• /etc/uucp - There have been some changes to the UUCP system. The Config, Grades, and Limits files are new in the Solaris 7 operating environment. The files Devconfig, Devices, Dialcodes, Dialers, Permissions, Poll, Sysfiles, and systems are the same in the Solaris 7 operating environment as they were in the SunOS release 4 software. These files can be merged together. There are also several SunOS release 4 files that are not used in the Solaris 7 operating environment.

• /etc/group - The basic format of this file is the same as it was in the SunOS 4.1 and SunOS 4.1.x releases. However, previous releases used a group entry beginning with a plus sign (+) or minus sign (-) to selectively incorporate entries from NIS maps for group. See the group(4) man page if that compatibility is needed under the Solaris 7 operating environment.

• /etc/netgroup - There is no /etc/netgroup file in the SunOS release 5.7 environment.

• /etc/exports - File systems to be shared on the network under the Solaris 7 operating environment use the /etc/dfs/dfstab file instead of /etc/exports. The format of entries in this file is like the following.

share -F fstype -o options -d "text" pathname resource

See the dfstab(4) man page for additional information.

• /etc/fstab - File systems to be mounted under the Solaris 7 operating environment use the /etc/vfstab file instead of /etc/fstab. The format of entries in the /etc/vfstab file is as follows.

Refer to the vfstab(4) man page for additional information.

• /etc/passwd - The format of the passwd file is the same as that under the SunOS release 4 software. However, user passwords are now stored in the /etc/shadow file. Refer to the passwd(4) and shadow(4) man pages for additional information.

• /etc/sendmail.cf - The format of sendmail.cf is the same as that under the SunOS release 4 structure. The location of the file is now /etc/mail/sendmail.cf.

• /etc/ttytab - Under the SunOS release 4 system, ttytab was used to control serial ports and the characteristics of the terminals on those serial lines. Under the Solaris 7 operating environment, the Service Access Facility is used to configure this capability.

• /etc/printcap - Under the Solaris 7 operating environment, printers are configured using the SunOS release 5.7 LP print service. See System Administration Guide, Volume I for additional information.

Chapter 4 Using the Compatibility Packages

The SunOS release 5.7 software is neither source nor binary compatible with the SunOS release 4 software. This means that SunOS release 4 programs and user applications based on those releases may not run correctly under the Solaris 7 operating environment. Compatibility packages make it possible for these programs to run on a Solaris 7 system.

This chapter discusses porting your applications, then describes the SunOS/BSD Source Compatibility Package and the Binary Compatibility Package. These packages make the transition easier by enabling you to use SunOS release 4 commands and applications while your environment and applications migrate to the Solaris 7 operating environment.

• "Why Port Applications?"

• "SunOS/BSD Source Compatibility Package"

• "Binary Compatibility Package"

Some SunOS release 4 commands are not available in the Solaris 7 operating environment. Others exist but have changed. For information about changes to SunOS release 4 commands in the Solaris 7 operating environment, see Appendix A, Commands Reference Table.

Why Port Applications?

Although the SunOS Binary Compatibility Package and the SunOS/BSD Source Compatibility Package allow you to use applications as they are, you should port applications as soon as possible. Long-term reliance on the compatibility packages is not advised for the following reasons:

• The application's performance is reduced.

• You will not be able to take advantage of the Solaris 7 operating environment's increased range of operations and portability.

• Compatibility packages are temporary aids to help sites through the transition.

SunOS/BSD Source Compatibility Package

The SunOS BSD/Source Compatibility Package is an optional package available with the Solaris 7 operating environment. The package contains a collection of SunOS release 4 and BSD commands, library routines, and header files otherwise not available with the Solaris 7 operating environment. The Binary Compatibility Package must be installed in order to use the SunOS/BSD Source Compatibility Package.

The interfaces in the SunOS/BSD Source Compatibility Package are installed in the /usr/ucb directory, thereby avoiding conflicts with existing SunOS release 5.7 interfaces. These interfaces provide a familiar SunOS environment while your environment and applications are migrating to the SunOS release 5.7 software. To use these interfaces, you must either specify the full path name or modify your PATH environment variable. When modifying your PATH environment variable, note that /usr/ucb should precede /usr/bin.

For detailed information about the Source Compatibility Package, see Source Compatibility Guide

Binary Compatibility Package

The Binary Compatibility Package is an optional package available with the Solaris 7 operating environment. The package allows existing SunOS release 4 applications, both statically and dynamically linked, to run under the Solaris 7 operating environment without modification or recompilation. It handles most binary interface discrepancies between the two releases transparently. This results in a Solaris 7 operating environment where SunOS release 4 applications can run properly.

See Binary Compatibility Guide for procedures about setting up your environment to access this package. This guide also details the limitations of the Binary Compatibility Package.

Using the Binary Compatibility Package to SunOS Release 4 Applications

The Binary Compatibility Package allows most applications to run under the Solaris 7 operating environment, making them available for use before they are ported to SunOS release 5.7. With this package, well-behaved application binaries based on SunOS release 4 system software will run under the SunOS release 5.7 software without modifications or recompilation.

The Binary Compatibility Package is intended for end-user environments, not for use as a development environment. All SunOS release 5.7 application development should be done under the base SunOS release 5.7 environment.

Chapter 5 Security

Security for the Solaris 7 operating environment combines several features from SunOS release 4 and AT&T SVR4 with capabilities added specifically for the new environment. There are also changes in the packaging of some SunOS release 4 security programs.

This chapter describes major differences between SunOS release 4 and Solaris 7 operating environment security, and points out how those changes may affect system administration procedures. System Administration Guide, Volume II describes the administration and use of these features more fully.

• "Solaris 7 Security Features"

• "Password Aging Changes"

• "Automated Security Enhancement Tool (ASET)"

• "Security Options"

Solaris 7 Security Features

Most of the security features from SunOS release 4 systems are also available in the Solaris 7 operating environment. These include:

• Internet security

• .rhosts and .rhosts.equiv files

• Secure RPC and NFS

RPC has been modified based on the GSS-API. This increases security integrity and confidentiality, and NFS services are no longer tied to a specific or a single security mechanism. Also, NIS+ security is enhanced by increasing the authentication key length from 192 bits to 640 bits.

NFS Administration Guide describes secure NFS and the .rhosts files. TCP/IP and Data Communications Administration Guide describes administering Internet security.

Security for local SunOS release 5.7 systems includes storing encrypted passwords in a separate file, controlling login defaults, and restricted shells. Equivalent NIS+ security, described in NIS+ Transition Guide and NFS Administration Guide, controls network-wide access to systems.

The following subsections summarize security features under local system control.

/etc/passwd and /etc/shadow Files

The SunOS release 5.7 passwd command stores encrypted versions of passwords in a separate file, /etc/shadow, and allows only root access to it. This prevents general access to the encrypted passwords that formerly appeared in the /etc/passwd file, which anyone could read.

The /etc/shadow file also includes entries that force password aging for individual user login accounts. The mechanism for changing entries to the passwd and shadow files is described in System Administration Guide, Volume II.

/etc/default Files

Several files that control default system access are stored in the /etc/default directory. These files limit access to specific systems on a network. Table 5-1 summarizes the files in the /etc/default directory.

Restricted Shells

System administrators can use restricted versions of the Korn shell (rksh) and Bourne shell (rsh) to limit the operations allowed for a particular user account.

Restricted shells do not allow the following operations:

• Changing directories

• Setting the $PATH variable

• Specifying path or command names beginning with "/"

• Redirecting output

See the ksh and sh man pages for a description of these shells.

Note that the restricted shell and the remote shell have the same command name (rsh) with different path names:

• /usr/lib/rsh is the restricted shell

• /usr/bin/rsh is the remote shell

Password Aging Changes

The SunOS release 5.7 system features password aging. This feature assigns a limited lifetime to each user password to maintain password secrecy. As a password reaches the end of its life, the password owner is notified and prompted to select a new one.

You can implement password aging using one of the following methods:

• Method 1 - Use Admintool to manage users if you are running an X-window environment. For information about this method, see OpenWindows Advanced User's Guide.

• Method 2 - Use new passwd or nispasswd command options (depending on which name service stores the account).

A system administrator can also set up password aging.

You can change a user password in one of two ways:

• Method 1- Use either passwd or nispasswd, depending on which name service is used to store your account.

• Method 2 - Use Admintool to manage users if you are running an X-window environment. For information about this method, see OpenWindows Advanced User's Guide.

For more information on passwd and nispasswd, see the command tables in Appendix D, System Files Reference Table.

Access Control Lists (ACLs)

Access control lists (ACLs), supported in both UFS and NFS, provide greater flexibility in managing file permissions than traditional UNIX file protection. The traditional UNIX file protection provides read, write, and execute permissions for three user classes: owner, group, and other.

Using ACLs allows you to define file permissions for the owner, owner's group, others, specific users and groups, and default permissions for each of those categories. For example, you can set up an ACL that defines read permission to a group of users and write permission to only one user in the group. You could not do this with standard UNIX file permissions.

The setfacl(1) command sets, adds, modifies, and deletes ACL entries, and the getfacl(1) command displays ACL entries.

See System Administration Guide, Volume II for more information about using ACLs.

Automated Security Enhancement Tool (ASET)

The Automated Security Enhancement Tool (ASET), available as a separate option with SunOS release 4 systems, is included with the Solaris 7 operating environment. ASET enables you to specify an overall system security level (low, medium, or high) and automatically maintain systems at those levels. This tool can be set up to run on a server and all its clients or on individual clients.

ASET performs these tasks:

• Verifies system file permissions

• Verifies system file contents

• Checks integrity of group file entries

• Checks system configuration files

• Checks environment files (.profile,.login, and .cshrc)

• Verifies EEPROM settings to restrict console login access

• Allows establishment of a firewall or gateway system

System Administration Guide, Volume II describes ASET setup and monitoring in detail.

Security Options

Currently available bundled security options are Kerberos security, the SunSHIELD^TM package, and Pluggable Authentication Module (PAM).

Kerberos 4.0 Security

The Solaris 7 operating environment includes support for Kerberos V4 authentication for secure RPC. (Kerberos source code and administrative utilities are available from MIT.) Included in this release are:

• Client applications library that can use Kerberos

• Kerberos option to Secure RPC

• Sun's NFS^TM distributed computing file system application with Kerberos

• Commands to administer user tickets on the client

System Administration Guide, Volume II describes the client-side utilities included in the release. NFS Administration Guide describes the use of Kerberos with the NFS application.

SunSHIELD Package

The Solaris 7 release includes the SunSHIELD Basic Security Module (BSM) package. This product provides the security features defined as C2 in the Trusted Computer System Evaluation Criteria (TCSEC). The features provided by the BSM are a security auditing subsystem and a device allocation mechanism. C2 discretionary access control and identification and authentication features are provided in the operating system.

The administration of BSM is included in SunSHIELD Basic Security Module Guide.

PAM

The Pluggable Authentication Module (PAM) framework enables new authentication technologies to be "plugged-in" without changing commands, such as login, ftp, telnet and so on. The framework enables a system administrator to choose any combination of services to provide authentication. Mechanisms for account, session, and password management can also be "plugged-in" using this framework.

System Administration Guide, Volume II describes the administration of PAM.

Chapter 6 User Environment Administration

This chapter describes differences in tasks you may perform to set up the local user environment after installing the Solaris 7 software.

• "Selecting a Default Shell"

• "Customizing User Environments"

• "Window Systems"

• "User and Group Administration"

• "Using Mail"

• "Using Document Tools"

• "Man Page Organization Differences"

Selecting a Default Shell

The login shell is the command interpreter that runs when you are logged in. The Solaris 7 operating environment offers three shells:

• Bourne shell, the default shell (/bin/sh)

• C shell (/bin/csh)

• Korn shell (/bin/ksh)

If you use the shell often, you may prefer to use the C shell or the Korn shell because of their interactive capabilities. Table 6-1 lists the features of all three shells.

To change from one shell to another, use one of the following methods:

• Method 1 - Edit the information in the last field of the line in the /etc/passwd file that begins with your login name. If this entry is blank or sh, the login shell is the Bourne shell. If the entry is csh, the login shell is the C shell. If the entry is ksh, the login shell is the Korn shell.

• Method 2 - In a windows environment, use Admintool. See OpenWindows Advanced User's Guide for information.

After you change to a new shell, log out and log in again to activate the shell.

Customizing User Environments

This section describes how to determine which initialization files you can edit to customize the local environment based on your choice of login shell, and where to find them in the SunOS release 5.7 file systems. Set up your environment by editing the variables in the initialization files. The default shell determines which files you need to edit: .profile, .login, or .cshrc. Table 6-2 shows the initialization files for the Bourne, C, and Korn shells.

In this release, the shell initialization-file templates have moved to the /etc/skel directory from /usr/lib, where they were in the SunOS release 4 software. The template file locations are shown in Table 6-3. Copy the template file (or files) for the appropriate default shell to your home directory before you modify it.

For information on setting up initialization files, see System Administration Guide, Volume I.

Using the SunOS Release 4 Work Environment With the Solaris Software

The SunOS release 5.7 software can use the old SunOS release 4 system files and initialization files such as .login, .cshrc, and.profile to re-create the look and feel of the SunOS release 4 work environment. Many of these SunOS release 4 files can be converted, or used as they are, and executed easily.

The installation process in Chapter 3, Converting a SunOS Release 4 System to the Solaris 7 Environment, explains how to re-create the SunOS release 4 environment within the Solaris 7 operating environment.

Window Systems

The Common Desktop Environment (CDE) is the default Solaris 7 windowing environment and offers a simple and intuitive interface. See Chapter 14, Solaris Common Desktop Environment, for more information about CDE.

The OpenWindows 3.1 software can also be used as your preferred desktop with the Solaris 7 environment. If you have been using the OpenWindows 2.0 environment, you will notice that the OpenWindows 3.1 icons have changed and some applications are not compatible with the OpenWindows 3.1 platform.

The OpenWindows Developer's Guide File Chooser (gfm) regular-expression file-pattern matching code (filter_pat) is slightly different from the regular-expression file-pattern matching code in the XView File Chooser object. This could result in the same regular expression matching slightly different sets of files in the two different choosers. The XView File Chooser uses /usr/include/reexp.h in the SunOS release 5.7 software and its usage is correct.

SunView software is not part of the Solaris 7 operating environment. SunView applications are incompatible with the OpenWindows environment and must be converted.

See OpenWindows Version 3.1 User's Guide for information about:

• Features of the OpenWindows 3.1 environment

• The applications that are not compatible between OpenWindows Version 2.0 and 3.1 platforms

• Guidelines for modifying incompatible applications

User and Group Administration

This section describes your options for performing user and group administration.

User and Group Administration Choices

You can add, modify, and remove users and groups through the command-line interface using useradd, userdel, and usermod. Although these commands are not as robust as Admintool, they do enable you to do most of the tasks supported by Admintool from the command line without running the OpenWindows or CDE software.

The useradd, userdel, and usermod commands are similar to editing the /etc files in that they also affect only the local system. These commands cannot be used to change any information in the network naming service. However, you can use useradd to verify the uniqueness of the user name and user ID and the existence of group names in the network naming service.

Adding User Accounts

This section describes changes to the general procedure for adding user accounts.

The general procedure for adding new users to a SunOS release 4 system was:

1. Edit the /etc/passwd file and add an entry for the new user.

2. Create a home directory and set the permissions for the new user.

3. Set up skeletal files for the new user (.cshrc, .login, .profile, and so on).

4. Add the new user to the naming service (NIS).

In the Solaris 7 operating environment, there are three ways to add (and maintain) user accounts:

• Use Admintool - This is the most straightforward method to use if the system is running the OpenWindows environment.

• Use command-line interfaces (useradd, usermod, and userdel) - Use this method if you don't want to use Admintool.

• Manually edit files (similar to the SunOS release 4 procedure with a few exceptions)

Because the SunOS release 5.7 software uses a shadow password file, simply editing the /etc/passwd file is no longer sufficient. You should not attempt this method unless you have ample experience with this type of administration.

System Administration Guide, Volume I describes in detail the policy decisions you should consider before you begin to set up accounts. It also explains security considerations for controlling user access to systems and networks.

Using Mail

The SunOS release 4 mail programs are different in the Solaris 7 operating environment; however, procedures for setting up mail are still the same. The SunOS release 4 version of mail is included in the SunOS/BSD Source Compatibility Package. Its user interface is different from the Solaris 7 operating environment's version of mail. Additionally, some useful mail facilities are included for compatibility.

In the Solaris 7 operating environment, there are three programs for sending and retrieving your mail. All three are backward compatible and can be used to read your SunOS release 4 mail. They are:

• mailtool, the OpenWindows interface for the mail program. New Solaris 7 mailtool options enable you to attach files to your messages, include third-party messages with your mail, deliver mail to multiple recipients, and send audio messages.

  See OpenWindows Version 3.1 User's Guide for a complete discussion of mailtool.

• mailx, which is installed under /usr/bin/mailx. This is the Solaris 7 mail reading program. It is an enhanced version of SunOS release 4 /usr/ucb/mail. In the Solaris 7 operating environment, /usr/ucb/mail is a link to /usr/bin/mailx. mailx offers message headers that enable you to preview the sender and subject of each message before you read it. You can also switch between reading, sending, and editing mail messages.

  See the mailx(1) man page for more information on mailx.

• mail refers to the mail program under /usr/bin/mail. The Solaris 7 interface is similar to the SunOS release 4 /usr/bin/mail version (see the bin-mail(1) manual page in SunOS release 4 Reference Manual).

  See the mail(1) man page for more information on mail.

For a complete discussion of all Solaris 7 mail programs, see Mail Administration Guide.

Using Document Tools

This section outlines the main differences in document tools used in SunOS release 4 and the Solaris 7 operating environment.

• The Solaris 7 operating environment provides a set of PostScript filters and device-independent fonts. However, most SunOS release 4 TranScript filters have SunOS release 5.7 equivalents while a few less common ones do not. In SunOS release 5.7 systems, there is no T_EX filter, no pscat (C/A/T) filter, and no raster image filter.

• The Solaris 7 operating environment provides device-independent troff, with the following features: SunOS release 4 troff input files work with Solaris 7 troff; troff default output goes to the standard output instead of the printer. Therefore, you must specify a printer when you send troff output to the printer.

Man Page Organization Differences

Man page organization has changed to be compatible with SVR4 organization. As a result, some sections have been renamed. For example, man(8) is now man(1M).

Table 6-4 shows SunOS release 5.7 man page directories.

Customizing the man Command Search Path

Unlike the SunOS release 4 software, which searched the individual man directories according to a predetermined order, the SunOS release 5.7 software lets you determine the search path. The man command uses the path set in the man page configuration file, man.cf.

Each component of the MANPATH environment variable can contain a different man.cf file. You can modify man.cf to change the order of the search; for example, to search 3b before 3c. The configuration file for the /usr/share/man directory follows.

#
# Default configuration file for the on-line manual pages.
#

MANSECTS=1,1m,1c,1f,1s,1b,2,3,3c,3s,3x,3i,3t,3r,3n,3m,3k,3g, \
3e,3b,9f,9s,9e,9,4,5,7,4b,6,l,n

The arguments to MANSECTS are derived from the man subdirectories available. The number of subdirectories has increased dramatically in this release because each subsection has its own directory. This new structure improves the performance of the man command and gives you finer control over the search path. The next two figures compare the man directories for the two releases.

sunos4.1% ls /usr/share/man
man1/   man2/   man3/   man4/   man5/   man6/   man7/   man8/  
manl/   mann/

sunos5.6% ls /usr/share/man
man.cf  man1f/  man3/   man3g/  man3n/  man3x/  man6/   man9f/
man1/   man1m/  man3b/  man3i/  man3r/  man4/   man7/   man9s/
man1b/  man1s/  man3c/  man3k/  man3s/  man4b/  man9/   manl/
man1c/  man2/   man3e/  man3m/  man3t/  man5/   man9e/  mann/

whatis and windex Databases

The SunOS release 4 man page table of contents and keyword database is called whatis. In the SunOS release 5.7 software, this information is in the windex file. In both releases, the database is created by the catman command, and is used by the man, apropos, and whatis commands.

The windex file also has a slightly different format than the whatis file, as you can see from the following comparison of the two release versions.

sunos4.1% man -k tset
tset, reset (1)    - establish or restore terminal characteristics

sunos5.6% man -k tset
reset  tset (1b)   - establish or restore terminal characteristics
tset   tset (1b)   - establish or restore terminal characteristics

Using the man Command

Table 6-5 shows that SunOS release 5.7 version of the man command has additional search options.

See the man(1) man page for a complete description of the SunOS release 5.7 man command.

Chapter 7 Device Administration

This chapter explains SunOS release 5.7 device naming conventions and discusses changes to device-related tasks such as getting information about disks, adding devices to a system, and using Volume Management.

• "Device Naming Conventions"

• "Obtaining Disk Information"

• "Adding Devices to the System"

• "Using Volume Management"

Device Naming Conventions

Device naming conventions have changed between the SunOS release 4 and SunOS release 5.7 platforms. In addition, the /dev directory, which 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.

SunOS release 5.7 commands that take device names as arguments must use the SunOS release 5.7 device naming conventions. However, you can still use and recognize the SunOS release 4 device names if you install the SunOS/BSD Source Compatibility Package. See Source Compatibility Guide for additional information.

Convention for Disks

The disk partition slice numbers (0 through 7) correspond to partitions a through h of previous SunOS releases.

Most SCSI disks have embedded controllers. This means that the drive number will always be 0 but the target number varies. For example, if an external disk drive has its rear switch set to 2, the device name for the first slice is /dev/dsk/c0t2d0s0, not /dev/dsk/c0t0d2s0.

Because the names for SCSI targets 0 and 3 were reversed on some sun4c systems, device naming can be confusing. Under the SunOS 4.1.x software, SCSI target 3 was called sd0(), but it is now properly named c0t3d0. SCSI target 0 was called sd3(), but it is now named c0t0d0. Other SCSI disk names translate normally. For example, in the SunOS release 5.7 software, sd2a is c0t2d0s0 and sd2b is c0t2d0s1.

Convention for Tape Drives

Table 7-1 provides some examples that compare the SunOS release 4 and SunOS release 5.7 device naming conventions.

Obtaining Disk Information

The commands that report disk information in the SunOS release 5.7 software have changed. df(1M) and du(1M) are still available, but have changed. dkinfo(8), and devinfo(1M) are replaced by prtvtoc and sysdef -d. This section provides an overview of these changes.

If you have installed the compatibility packages, SunOS release 4 command versions can be found under /usr/ucb/df and /usr/ucb/du.

df Command

The df command has been changed to support the VFS architecture. As with the other VFS commands, there are generic and file-system versions of the command. The syntax in the SunOS release 5.7 command differs significantly from that used in the SunOS release 4 version (see Appendix A, Commands Reference Table, for more information). For more information on VFS, see "Virtual File System Architecture".

The df command now reports disk space in 512-byte blocks instead of kilobytes, but the -k option can be used to report disk space in kilobytes. Also, the -t option behaves differently; formerly, it restricted the output to file systems of a specified type (for example, "nfs" or "4.2"). The SunOS release 5.7 version produces a full listing with totals.

Finally, use the SunOS release 5.7 device naming conventions when specifying special device names to this command. See "Device Naming Conventions" for details.

du Command

Like df, the du command reports disk usage in 512-byte blocks instead of kilobytes. There's also a -r option that causes the normally "silent" command to generate messages when it has difficulty reading a directory or opening a file.

dkinfo Command

The SunOS release 4 dkinfo command is no longer available. To print device information, use prtvtoc(1M) instead of dkinfo.

The prtvtoc command reports the important information stored on a disk's label, including information on the disk's partitions. For more information about prtvtoc, see System Administration Guide, Volume I.

The following screen shows sample output for the SunOS release 5.7 prtvtoc command.

# prtvtoc /dev/rdsk/c0t2d0s2 
* /dev/rdsk/c0t2d0s2 partition map 
* 
* Dimensions: 
*     512 bytes/sector 
*      36 sectors/track 
*       9 tracks/cylinder 
*     324 sectors/cylinder 
*    1272 cylinders 
*    1254 accessible cylinders 
* 
* Flags: 
*   1: unmountable 
*  10: read-only 
*                         First   Sector      Last       Mount
*  Partition  Tag  Flags  Sector   Count    Sector   Directory
        0       0     00       0   32724    32723       / 
        1       0     00   32724   65448    98171
        2       0     00       0  406296   406295
        6       0     00   98172  308124   406295       /usr

devinfo Command

The SunOS release 4 version of devinfo is incompatible with the SunOS release 5.7 version. To produce output similar to the SunOS release 4 version, use prtconf with the -v option.

Adding Devices to the System

When you boot the system, it does a self-test and checks for all attached devices that are attached. After you add a new device to the system, use boot -r to activate dynamic reconfiguration of the kernel. A reconfiguration script is run to load all the device drivers listed in the module's directories and to create the corresponding hardware nodes. See the kernel(1M) man page for more information.

You can also use boot -a to interactively add drivers or modules to the system, but if you do, you will be asked to provide other boot parameters, including what to boot and where the root file system is.

Paths to the system files and kernel modules are stored in /etc/system. When the system boots, it reads the information in /etc/system to determine which modules to load. You can specify a different path by using the MODDIR syntax of the system(4) file or by using boot -a.

For more information about boot(1m) or about adding devices and drivers, see System Administration Guide, Volume I.

Dynamic Reconfiguration

Dynamic reconfiguration, available on certain SPARC servers with the Solaris 7 release, allows a service provider to remove or replace hot-pluggable system I/O boards in a running system, eliminating the time lost in rebooting. Also, if a replacement board is not immediately available, the system administrator can use dynamic reconfiguration to shut down a failing board while allowing the system to continue operation.

See your hardware manufacturer's documentation for information about whether dynamic reconfiguration is supported on your server.

Using Volume Management

Beginning with the Solaris 2.2 release, 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.

The OpenWindows and CDE File Manager applications have been modified to use Volume Management to provide immediate user access to CDs and diskettes with file systems. 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.

Volume Management automatically mounts CD and diskette file systems when removable media is inserted into the devices. Any CD or diskette file system will be automatically mounted in the locations described in Table 7-2.

If the CD or diskette does not contain a file system, it will be accessible in the locations described in Table 7-3.

For security reasons, these file systems are mounted setuid. See the mount(1M) man page for a description of this and other mount options.

For more information on configuring Volume Management and on using diskettes and CDs, see System Administration Guide, Volume I.

Man pages for Volume Management components are also available. See rmmount(1), rmmount.conf(4), volcancel(1), volcheck(1), vold(1M), volmgt(3), vold.conf(4), volfs(7), and volmissing(1).

Volume Management now controls these CD-ROM paths: /dev/dsk/c0t6d0s0 and /dev/rdsk/c0t6d0s0; and these diskette paths: /dev/diskette and /dev/rdiskette. Attempts to mount or access a CD or diskette using these paths will result in an error message.

There are several new commands to help you administer Volume Management on your system, as described in Table 7-4.

There are also two configuration files to define Volume Management's actions: /etc/vold.conf and /etc/rmmount.conf. See the vold.conf(4) and rmmount.conf(4) man pages for descriptions of these files, and see System Administration Guide, Volume I for information on managing CD-ROM and diskette devices.

Chapter 8 Startup and Shutdown

This chapter describes changes to procedures for booting and shutting down a system.

• "Booting"

• "Using the init Command"

• "Shutting Down"

See System Administration Guide, Volume I for detailed descriptions of boot procedures.

Booting

The Solaris 7 boot process makes system administration easier. Some of the major changes include:

• The kernel is self-configuring so you no longer need to rebuild it manually.

• Kernel memory consumption is reduced because devices load automatically when first opened.

• File systems are checked only when necessary, improving boot time.

• The boot block can read UNIX file systems, eliminating boot errors when the boot program moves.

• Third-party bootable devices are supported.

• Secondary boot programs, ufsboot and inetboot, have been modified to read CacheFS file systems. This new booting capability enables Solstice AutoClient^TM systems to boot more quickly and with less impact on network resources.

• The SunOS release 4 fastboot command is available only on Solaris 7 systems that have the SunOS/BSD Source Compatibility Package installed. The fastboot command is obsolete in Solaris 7 systems because file systems are only checked if the file system state is identified as not clean.

• The SunOS release 4 halt and reboot commands have shutdown(1M) and init(1M) equivalents in the SunOS release 5.7 software.

In the Solaris 7 operating environment, the shutdown and init commands are the preferred way to halt, shut down, or reboot your system. While the reboot command is available in the Solaris 7 operating environment, it brings the system down quickly without shutting down services in an orderly way. Table 8-1 shows the SunOS release 5.7 commands that replace SunOS release 4 commands.

boot Command Changes

The SunOS release 5.7 software has these additional options for the boot command:

• Type boot -r when you add new hardware or alter its location. This option creates the physical and logical device names, with the logical device name linked to the physical device name.

• Type boot -v when you want to see all the system bootup messages; the default is to boot silently. The messages are always stored in the /var/adm/messages file.

• Type boot -a when you want to be prompted for the name of an alternate kernel, /etc/system file, or path name for kernel module directories.

Booting From the PROM

Be aware of these changes when booting from the PROM:

• The PROM loads bootblk from the disk. This file is similar to the previous SunOS release 4 boot block except that it is specific to the UFS file system.

  As in the SunOS release 4 software, you need to use installboot(1M) to install boot blocks on a partition to be used for booting.

• bootblk opens the boot device and, using the file system you specify, finds and loads ufsboot.

• The boot PROM loads the kernel, /kernel/genunix, after ufsboot is loaded into memory. SunOS release 4 systems used /vmunix; however, in the SunOS release 5.7 software the /kernel directory contains all platform-independent kernel modules, including unix, needed to boot the system.

• The kernel, in turn, loads other drivers, such as esp, from the /kernel/drv directory. These drivers had to be built as part of the SunOS release 4 kernel but can be dynamically loaded in SunOS release 5.7 systems when they are needed.

• The /sbin/init command generates processes to set up the system based on the directions in /etc/inittab. The next section describes the run levels that init uses.

Summary of Boot Differences

Table 8-2 summarizes booting differences.

Using the init Command

The init(1M) command replaces the SunOS release 4 fasthalt command in the SunOS release 5.7 software. Use it to shut down a single-user system. You can use init to place the system in a power-down state (init 0) or into single-user state (init 1).

init Command Changes

Note the following changes to the init command:

• SunOS release 5.7 system software has eight initialization states (init states or run levels). The default init state is defined in the /etc/inittab file.

• The SunOS release 5.7 init command uses a different script for each run level instead of grouping all the run levels together in the /etc/rc, /etc/rc.boot, and /etc/rc.local files. The files, named by run level, are located in the /sbin directory.

System Administration Guide, Volume I describes this command in detail.

Changing System Run Levels

The SunOS release 5.7 init command enables you to control the run level (initialization state) of your system and move easily between various modes of operation. The SunOS release 5.7 /sbin/rc scripts control each individual run level instead of putting all system states into one file. This enables you to make changes in a unique file if you create new scripts or modify existing ones. SunOS release 4 systems controlled run levels using /etc/rc, /etc/rc.boot, and /etc/rc.local files.

The SunOS release 4 software had three run levels: PROM monitor, single user, and multiuser. These correspond to run levels 0, 1, and 3 in the SunOS release 5.7 software.

Table 8-3 gives an overview of what each run level's /sbin/rc script does.

Shutting Down

Use the shutdown(1M) command when shutting down a system with multiple users. The command sends a warning to all logged-in users and, after 60 seconds, shuts the system down to single-user state.

• The SunOS release 4 fasthalt commands are available only on SunOS release 5.7 systems that have the SunOS /BSD Source Compatibility Package installed.

• The SunOS release 4 halt and reboot commands have shutdown and init equivalents.

See System Administration Guide, Volume I for detailed descriptions of shutdown procedures.

In the SunOS release 5.7 software, the shutdown command is the preferred way to halt or shut down a system. shutdown and init use rc scripts to kill running processes. While the halt command is available in the SunOS release 5.7 software, it stops the system quickly without shutting down services in an orderly way. Table 8-4 shows the SunOS release 5.7 commands that replace those in the SunOS release 4 system.

The shutdown and init commands accept a numerical "run-level" argument that controls the shutdown sequence. See the shutdown and init man pages for information about the run-level numbers.

Changes to the shutdown Command

The SunOS release 5.7 shutdown command includes only the options in Table 8-5. This command and its options are described in System Administration Guide, Volume I.

By default, the SunOS release 5.7 shutdown command asks you to confirm before an actual shutdown begins. You can use the -y option to run it without operator intervention.

The shutdown options are available only in BSD source compatibility mode on Solaris 7 systems.

See Appendix A, Commands Reference Table, for a summary of changes. See shutdown(1M) for information about how the command works.

Using the fasthalt and fastboot Commands

The SunOS release 4 fastboot and fasthalt commands are available if you are running the SunOS/BSD Source Compatibility Package on Solaris 7 systems. The file-system checking features of these commands are not appropriate to a Solaris 7 system.

Using the halt and reboot Commands

The halt and reboot commands do not run the rc scripts in /sbin, so they are not recommended. Since the halt and reboot commands in SunOS release 5.7 systems are not available on other AT&T SVR4 systems, both commands have shutdown and init equivalents.

Chapter 9 File System Administration

This chapter familiarizes you with changes to file systems, virtual file systems, directories, and files. The chapter also describes changes to file system administration including:

• "File System Changes"

• "Default File Systems and Directories"

• "Virtual File System Architecture"

• "Directory and File Changes"

• "Using File System Administration Commands"

For more information on understanding and managing file systems, see System Administration Guide, Volume I.

File System Changes

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 and new pseudo file systems, and one directory was removed.

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 has changed and contains specific 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 size 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 /sys directory is no longer needed because the kernel is dynamically loaded.

• The /RFS file system has been removed.

• The terminfo database replaces termcap.

Pseudo File Systems

The TFS pseudo file system is not included in the SunOS release 5.7 software.

Following are the pseudo file system systems that are included:

• CACHEFS--used to improve performance of slow devices such as CD-ROM.

• PROCFS--memory resident file system that contains a list of active processes, by process number, in the /proc directory. See the proc(4) man page.

• FDFS--lists explicit names for opening files using file descriptors.

• FIFOFS--contains pipe files that give processes common access to data.

• NAMEFS--used mostly by STREAMS for dynamic mounts of file descriptors on top of files.

• SWAPFS--provides 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.7 directory structure:

• The kernel (now called unix) and the kernel modules are stored in the /kernel directory.

• 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) man page.

Default File Systems and Directories

The SunOS release 5.7 file system is hierarchical. Figure 9-1 graphically depicts SunOS release 5.7 default directories and file systems (indicated by dotted lines). Subdirectories shown are just a sample of what the directory or file system actually holds. Table 9-1 gives a brief description of each.

Figure 9-1 Solaris 7 Default File Systems and Directory Hierarchy

The Solaris 7 software contains a default set of file systems and directories, and uses a set of conventions to group similar types of files together. Table 9-1 lists the default file systems and directories with a brief description.

Virtual File System Architecture

The SunOS release 5.7 software features a virtual file system (VFS) architecture that simplifies file system management for systems that support multiple file systems.

Over the years, several different UNIX file systems were developed, each with its own set of commands for file system management. Learning all the variations can be confusing and difficult. The SunOS release 5.7 software addresses this issue with a set of generic commands for file system management. These commands are a part of a common VFS interface that makes differences between file systems transparent with respect to maintenance. The subsections below provide a summary of supported file systems and the generic file system commands.

Supported File System Types

Most file system types included in the SunOS release 4 software are also included in the SunOS release 5.7 software. There is one exception: The translucent file system (TFS) type has been withdrawn from the SunOS release 5.7 software. Table 9-2 summarizes file-system type availability in the SunOS release 4 and SunOS release 5.7 environment.

For more information on file systems, see the proc(4) and fd(4) man pages and System Administration Guide, Volume I.

Cache File System (CACHEFS)

The Cache File System can be used to improve performance of remote file systems or slow devices such as CD-ROMs. When a file system is cached, the data read from the remote file system or CD-ROM is stored in a cache on the local system.

Swap File Changes

In the SunOS release 5.7 software, SWAPFS is the default swap device when the system boots or you create additional swap space. This swap device uses physical memory as swap space, but also requires physical swap space on a disk.

In SunOS release 4 systems, the default physical swap device depends on the system configuration. Standalone systems default to sd0b and diskless systems get their swap files from the bootparam server. The SunOS release 5.7 software uses the swap file as the default dump device instead of specifying a file on disk.

Unsupported SVR4 File System Types

Table 9-3 shows SVR4 file system types that are not supported in the SunOS release 5.7 software.

Generic File System Commands

Most file system administration commands have a generic and a file system component. Use the generic commands, which call the file system component. Table 9-4 lists the generic file-system administrative commands, which are located in the /usr/bin directory.

Most of these commands also have a file system counterpart.

Do not use the file system commands directly. If you specify an operation on a file system that does not support it, the generic command displays this error message: command: Operation not applicable for FSType type.

Syntax of Generic Commands

Most of these commands use this syntax:

command [-F type] [-V] [generic-options] [-o specific-options] [special|mount-point] [operands] 

The options and arguments to the generic commands are:

-F type

Specifies the type of file system. If you do not use this option, the command looks for an entry that matches special or mount point in the /etc/vfstab file. Otherwise, the default is taken from the file /etc/default/fs for local file systems and from the file /etc/dfs/fstypes for remote file systems.

-V

Echoes the completed command line. The echoed line may include additional information derived from /etc/vfstab. Use this option to verify and validate the command line. The command is not run.

generic-options

Options common to different types of file systems.

-o specific-options

A list of options specific to the type of file system. The list must have the following format: -o followed by a space, followed by a series of keyword [=value] pairs separated by commas with no intervening spaces.

special|mount-point

Identifies the file system. The name must be either the mount point or the special device file for the slice holding the file system. For some commands, the special file must be the raw (character) device; for other commands it must be the block device. In some cases, this argument is used as a key to search the file /etc/vfstab for a matching entry from which to obtain other information. In most cases, this argument is required and must come immediately after specific-options. However, the argument is not required when you want a command to act on all the file systems (optionally limited by type) listed in the /etc/vfstab file.

operands

Arguments specific to a type of file system. See the specific man page of the command (for example, mkfs_ufs(4) for a detailed description.

System-wide Default File System Type

The default remote file system type is /etc/dfs/fstype. The default local file system type is /etc/default/fs. See the default_fs(4) man page for more information.

Command Locations

In previous SunOS releases, all file system commands were located in the /etc directory. In the SunOS release 5.7 software, file system commands are organized into separate hierarchies for convenience. All of the file system commands are included in /usr/lib/fs/fstype. Commands needed before /usr is mounted are duplicated in /etc/fs/fstype.

The generic commands are located in /usr/sbin. The commands needed before /usr is mounted are duplicated in /sbin.

Table 9-5 lists the locations of the file-system commands.

New UFS Mount Option

To ignore access time updates on files, you can specify the o noatime option when mounting a UFS file system. This option reduces disk activity on file systems where access times are unimportant (for example, a Usenet news spool).

Directory and File Changes

This section describes the changes to directories and files between the SunOS release 4 and SunOS release 5.7 environment.

/dev Directory

The /dev directory has changed from a flat directory to a hierarchical one. Table 9-6 describes the subdirectories that have been added.

/etc Directory

The /etc directory contains system configuration information. Several files and subdirectories have been added, removed, or changed.

• File system commands, such as mount*, have been moved to subdirectories of the /usr/lib/fs directory.

• The SunOS release 4 /etc/fstab file has been replaced by /etc/vfstab.

  Initialization scripts, such as rc, rc.boot, rc.local, and rc.single, are not available in the SunOS release 5.7 software. They are replaced by the scripts shown in Table 9-7, which are run by their corresponding run control files. Table 9-8 describes the subdirectories that have been added to the SunOS release 5.7 /etc directory.

/etc/vfstab File

In the SunOS release 5.7 software, the virtual file system file /etc/vfstab replaces the /etc/fstab file. In the virtual file system architecture, the /etc/vfstab file provides default file system parameters used by the generic commands for file system management. For information about these commands, see "Generic File System Commands".

In addition to the name change, the /etc/vfstab file is different from the /etc/fstab file in the following ways:

• A device to fsck field has been added to specify the names of raw devices to be checked by fsck.

• An automount field has been added to control the routine mounting of file systems by mountall (the automount daemon does not use this field).

• The freq field, which specified the number of days between dumps, has been eliminated.

  The file system table has seven fields, each separated by a tab. Table 9-9 explains the field entries.

  ---

  Note -

  You must have an entry in each field in the /etc/vfstab file. If there is no value for a field, be sure to type a dash (-).

  ---

For detailed information about the /etc/vfstab file, see System Administration Guide, Volume I.

/etc/shadow File

The SunOS release 5.7 software contains an /etc/shadow file, which includes entries that force password aging for individual user login accounts. The /etc/shadow file also contains encrypted passwords. The /etc/shadow file does not have general read permissions. This prevents general access to the encrypted passwords that formerly appeared in the /etc/passwd file.

/sbin Directory

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. See the rc man pages and "Changing System Run Levels" for a description of the scripts.

/usr Directory

The SunOS release 5.7 /usr directory contains sharable files and executables provided by the system. Table 9-10 describes the subdirectories that have been added to the SunOS release 5.7 /usr directory.

Table 9-11 shows files that were in the SunOS release 4 /usr directory but have been moved in the SunOS release 5.7 software.

Appendix E, / and /usr File Systems Changes, contains tables with detailed information about the directories and files in each of these file systems.

/var Directory

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/opt/packagename directory contains software package objects that change sizes, such as log and spool files.

• The /var/sadm directory contains databases maintained by the software package management utilities.

• The /var/saf directory contains Service Access Facility (SAF) logging and accounting files.

• The SunOS release 4 /var/spool/mail directory has been moved to /var/mail.

  Two directories were added to the SunOS release 5 file system: /kernel and /opt.

/kernel Directory

The SunOS release 5.7 /kernel directory contains the operating system kernel and kernel-level object modules that were in the SunOS release 4 /sys directory. Table 9-12 describes the subdirectories that have been added to the /kernel directory.

/opt Directory

The SunOS release 5.7 /opt directory contains optional add-on application software packages. These packages were installed in the SunOS release 4 /usr directory.

/sys Directory

The /sys directory has been retired. Its files, used to reconfigure the kernel, have been made obsolete by the dynamic kernel.

Using File System Administration Commands

The file system administration commands that have changed in the SunOS release 5.7 software include:

• Mounting file systems

• Monitoring file systems

• Sharing file systems

• Creating a new file system

• Checking a file system

• Backing up and restoring files

  When you are ready to administer file systems on your SunOS release 5.7 system, see System Administration Guide, Volume I for details on performing the tasks involved.

Mounting File Systems and autofs

The biggest change to the mounting capability is automatic mounting or autofs. The autofs program automatically mounts directories when you access them using, for example cd(1) or ls(1). This capability includes file hierarchies, CD-ROM, and diskette file systems.

autofs starts automatically when the system enters run level 3, or you can invoke it from a shell command line.

autofs works with the file systems specified in maps. These maps can be maintained as NIS, NIS+, or local files. The autofs maps can specify several remote locations for a particular file. This way, if one of the servers is down, autofs can try to mount from another system. You can specify in the maps which servers are preferred for each resource by assigning each server a weighting factor.

Mounting some file hierarchies with autofs does not exclude the ability to mount others with the mount command. A diskless system must have entries for / (root), /usr, and /usr/kvm in the /etc/vfstab file. Because shared file systems should always remain available, do not use autofs to mount /usr/share.

The following example shows how to manually mount a file system listed in the /etc/vfstab file using the mount command.

1. Change to the directory in which you want to create the mount point.

2. Create the mount-point directory.

3. Specify either the mount point or the block device.

   Specifying the mount point is usually easier. The rest of the information is read from /etc/vfstab.

4. Become root and type the mount command, specifying either the mount point or the block device.

   Specifying the mount point is usually easier. The rest of the information is read from /etc/vfstab.

   # mount mount-point

   The file system is now mounted.

   For instructions showing how to mount different types of file systems using mount with or without options, see System Administration Guide, Volume I.

Changes to the mount Command

Some of the names and forms of the mount commands are different, as listed in Table 9-13.

See Appendix A, Commands Reference Table, for more information on changes to these commands.

Automatic Mounting of /cdrom and /floppy

In this release, the CD-ROM and diskette file systems are automatically mounted in /cdrom and /floppy when removable media are inserted into these drives. Since these file systems are now managed by the Volume Management daemon, vold(1M), you cannot mount these devices yourself. See "Using Volume Management" for more information.

Specifying File Systems in the /etc/vfstab File

In the SunOS release 5.7 system, you need to list file systems that you want mounted at system startup in your /etc/vfstab, instead of in the /etc/fstab file. The format of /etc/vfstab differs from that of /etc/fstab. For a discussion of the /etc/vfstab file, see "/etc/vfstab File ".

Monitoring File Systems

Table 9-14 shows the file and directory monitoring commands and changes.

Sharing File Systems

File systems were "exported" in the SunOS release 4 software to make them available to other systems. This was done through the /etc/exports file and the exportfs command. However, only NFS systems could be exported.

In the SunOS release 5.7 software, this same concept is referred to as "sharing resources," and it has been expanded to include more file systems. File systems are shared with the share(1M) and shareall(1M) commands. The share command is similar to the exportfs pathname command, while shareall is similar to the exportfs -a command.

The share -F fstype option specifies the type of file system to be shared. If the -F option is not specified, share uses the first file-system type listed in the /etc/dfs/dfstab file.

File systems that you want to be shared automatically should have share command entries in the /etc/dfs/dfstab file (which replaces the /etc/export file). The commands specified in this file are run automatically when the system enters run level 3 (multiuser mode with network file sharing).

Example of /etc/dfs/dfstab File Entries

The following entry gives clients on mercury, venus, and mars read-write access to /export/home1; the second entry gives clients on saturn and jupiter read-only access to /export/news.

share -F nfs -o rw=mercury:venus:mars -d "Home Dir" /export/home1
share -F nfs -o ro=saturn:jupiter -d "News Postings" /export/news

When the system is running in multiuser mode, these file systems are available to the clients listed. The share command displays all resources shared by the local system.

% share
-               /export/home1   rw=mercury:venus:mars   "Home Dir"
-               /export/news    ro=saturn:jupiter   "News Postings"

Creating New File Systems

You define, specify, and create a new file system using either the newfs(1M) or the mkfs(1M) command. The following sections highlight changes in the newfs and mkfs commands.

newfs Command

The SunOS release 5.7 newfs command is a convenient front end to the mkfs command. The newfs command does not support the virtual file-system architecture; it is intended for creating UFS-type file systems only. When you use newfs, it calls and passes arguments to mkfs, which does the real work when creating a ufs file system.

The newfs command accepts only names that conform to the SunOS release 5.7 device naming conventions (see "Device Naming Conventions").

mkfs Command

The SunOS release 5.7 mkfs command differs significantly from the SunOS release 4 version of the command. The SunOS release 5.7 version provides for different file system types, and its command syntax is entirely different (see "Generic File System Commands"). Like newfs, mkfs accepts only names conforming to the SunOS release 5.7 device naming conventions.

Although mkfs now supports different types of file systems, in practice it is almost always used to create ufs file systems. However, mkfs isn't usually run directly; it is usually called by the newfs command.

See mkfs(1) man pages for additional details.

Checking File Systems

The SunOS release 5.7 fsck(1M) command differs significantly from the SunOS release 4 version of the command. In keeping with the virtual file-system (VFS) architecture, the fsck file-checking utility has two parts:

• A generic command that is called first, regardless of the type of file system.

• A specific command that is called by the generic command, depending on the type of the target file system (see "Generic File System Commands").

  In addition, fsck accepts only names conforming to the SunOS release 5.7 device naming conventions. For more information, see "Device Naming Conventions".

  The fsck command performs faster consistency checks at mount time. In addition, the SunOS release 5.7 software does not require you to reboot the system after running fsck on the root and /usr file systems. This results in faster system startup compared to previous SunOS releases. The fsck -m command enables you to skip checking for file systems that are clean. See fsck(1m) for additional details.

Backing Up and Restoring Files

This section discusses the changes to backup and restore commands and SunOS release 5.7 and describes how to use the ufsdump, ufsrestore, dd, tar, and cpio commands.

The SunOS release 4 software supported several utilities for backing up and restoring files: dump, restore, tar, cpio, dd, and bar, as well as the unbundled Backup CoPilot program. This release supports all of these utilities except bar and Backup Copilot. SunOS release 4 bar files can be restored on a SunOS release 5.7 system but you cannot create new bar files. The dump(8) and restore(8) commands were renamed ufsdump(1M) and ufsrestore(1M). Files created with the SunOS release 4 dump command can be restored on a SunOS release 5.7 system with ufsrestore.

The SunOS release 5.7 software has two additional utilities for copying file systems: volcopy(1M) and labelit(1M).

ufsdump Command

The ufsdump command accepts the same command syntax as the SunOS release 4 dump command. ufsdump also accepts options listed in Table 9-15.

Unlike dump, ufsdump can detect the end of medium, so you no longer have to use the -s size option to force dump programs to move to the next tape before reaching the end. Nevertheless, to ensure compatibility with older versions of the restore command, the -s option has been retained in ufsdump.

Even though ufsdump now can detect the end of medium, it has no way to predict the number of diskettes or tapes needed for a dump--unless you specify the medium size with the -s option. Therefore, the messages displayed at the start of a backup do not indicate the number of diskettes or tapes required unless you have specified the medium size.

The -w and -W options behave a little differently in the SunOS release 5.7 software. In the SunOS release 4 software, these options list all file systems that are scheduled for backup according to the backup frequencies specified in the /etc/fstab file. Since the SunOS release 5.7 equivalent file, /etc/vfstab, has no provision for specifying backup frequencies, these options now assume that each file system will be backed up daily. Therefore, they now list any file systems that have not been backed up within a day.

When performing backups across the network (backing up local file systems to a remote tape drive), use the device naming convention that is appropriate for the system with the tape drive. If the system with the tape drive is a SunOS release 5.7 system, use the device naming convention to identify the tape drive; otherwise, use the SunOS release 4 convention.

ufsrestore Command

The ufsrestore command in the SunOS release 5.7 software is similar to the restore command in the SunOS release 4 software. You will be able to restore backups made with the SunOS release 4 dump command with one exception: you cannot restore multivolume backups from diskette. If you have backup scripts that invoke restore, change them to invoke ufsrestore instead.

dd Command

In the SunOS release 4 version of the dd command, the size suffix -w (words) denotes a size unit of 4 bytes. In the SunOS release 5.7 version, -w denotes a unit of 2 bytes. In addition, the SunOS release 5.7 version now supports the -unblock and -block conversion options.

tar and cpio Commands

Because they use a nonbinary format, the tar and cpio commands are the only utilities to successfully interchange data between SVR4 implementations. Other backup utilities, such as ufsdump and dd, are unique to the vendor and are not guaranteed to work successfully from one SVR4 implementation to another.

The tar command is unchanged in this release; it accepts the same options and command syntax as the SunOS release 4 command. However, since the device naming scheme has changed in the SunOS release 5.7 software, the tarfile (or device) argument is affected. When using the -f function modifier, specify the device argument as /dev/rmt/unit, where unit is a tape drive number and density. Table 9-16 shows the tape drive density characters in tape device names.

The tar command no longer uses /dev/rmt8 as its default output device. When the -f modifier is not used and the TAPE environment variable is not set, the tar command uses the defaults set in the /etc/default/tar file.

The SunOS release 5.7 cpio command supports the SunOS release 4 options and command syntax. cpio has been expanded to include many new options, as listed in Table 9-17.

cpio requires one of three mutually exclusive options to specify the action to take: -i (copy in), -o (copy out), or -p (pass).

UFS Logging

The Solaris 7 release provides UFS logging, the process of storing transactions (changes that make up a complete UFS operation) into a log before the transactions are applied to the UFS file system. Once a transaction is stored, the transaction can be applied to the file system later.

UFS logging provides two advantages. It prevents file systems from becoming inconsistent, therefore eliminating the need to run fsck(1M). And, because fsck can be bypassed, UFS logging reduces the time required to reboot a system if it crashes, or after an unclean halt.

UFS logging is not enabled by default. To enable UFS logging, you must specify the -o logging option with the mount(1M) command when mounting the file system. Also, the fsdb(1M) command has been updated with new debugging commands to support UFS logging.

See System Administration Guide, Volume I, for more information.

Chapter 10 Setting Up a Solaris 7 Server to Support SunOS Release 4 Diskless Clients

This chapter discusses the set up of a Solaris 7 server to support SunOS release 4 diskless clients.

The following sections describe programs included in the SUNWhinst package used to configure the Solaris 7 server.

• "Adding SunOS Release 4 Support to a Solaris 7 Server"

• "Running discover4x"

• "Setting Up the CD-ROM Drive for install4x"

• "Running install4x"

• "Running convert4x"

The SUNWhinst package is available on the Solaris Easy Access Server 2.0 software CD in the AdminSuite_2.3+AutoClient_2.1/4.x directory.

Adding SunOS Release 4 Support to a Solaris 7 Server

This section explains how to prepare a Solaris 7 system to serve SunOS release 4 diskless client.

Ensure that all system data has been restored before you use the commands in this procedure. The /export file system is particularly important because it contains client information. See Chapter 3, Converting a SunOS Release 4 System to the Solaris 7 Environment.

Some sites continue to use SunOS release 4 clients systems after a server has been upgraded with Solaris 7 software.

Systems such as Sun-3^TM machines, for example, cannot be upgraded with Solaris 2.2 or Solaris 7 software. For those systems and other SunOS release 4 clients on a Solaris 7 network, you can add the SUNWhinst package to the /export partition on the server to establish the multiple OS operation required for SunOS release 4 clients.

The SUNWhinst package includes three programs you run to configure the /export directory on a Solaris 7 server. The three programs are:

• discover4x - This program analyzes the support that remains for SunOS release 4 clients after the Solaris 7 operating environment has been installed on a server. The program looks at the SunOS release 4 client support and creates the databases that are required for installation of SunOS release 4 diskless clients on the Solaris 7 server. If client support for a given architecture is missing, discover4x attempts to notify users that they will have to re-install this support using install4x. If there are SunOS release 4 clients with the same architecture as the server that migrated to the Solaris 7 operating environment, you must re-install that architecture using the install4x command.

• install4x - This program is used to install the components of a SunOS release 4 system required to support diskless clients that existed before the migration to the Solaris 7 operating environment.

• convert4x - This program updates the Solaris 7 server with information about all the existing SunOS release 4 clients. This command is used after issuing the discover4x and install4x commands. The updated information enables the existing SunOS release 4 clients to work with the Solaris 7 server.

Before beginning any of these installation procedures, ensure that the SUNWhinst package is properly loaded. Use the pkginfo(1) command to generate a list of installed packages and then check the list to ensure that all necessary packages were installed, including the SUNWhinst package.

For details on adding and removing packages, see System Administration Guide, Volume I.

Running discover4x

discover4x analyzes the support that remains for SunOS release 4 clients after the server has migrated to the Solaris 7 operating environment.

As superuser, type the following.

# discover4x

The discover4x program runs from 1 - 60 seconds, depending on the amount of software examined.

discover4x may report messages such as the following.

Setting up proto root for sun4c arch

Updating server databases to include sun4c sunos 4.1.2 support

Support for sun4c clients must be added using install4x, if \

           sun4c clients are served by this machine.

If your site has completed a custom Solaris 7 installation that changed the location of the /export directory, discover4x examines that directory if you invoke it with the directory name as a single argument. For instance, if the /export software is stored in /clients directory, use the following command.

# discover4x /clients

Setting Up the CD-ROM Drive for install4x

Run the install4x program on a server with the Solaris 7 operating environment using one of the three procedures listed in the following section.

• If the system has a local CD-ROM drive, see "Using a Local CD-ROM Drive"

• If the system will use a remote CD-ROM drive on a system running the Solaris 7 operating environment, see "Using a Remote CD-ROM Drive (Solaris 7 Software)"

• If the system will use a remote CD-ROM drive on a system running the SunOS release 4 software, see "Using a Remote CD-ROM Drive (SunOS Release 4 Software)"

Insert the SunOS release 4 CD into the CD-ROM drive before you proceed.

Using a Local CD-ROM Drive

If you are running install4x on a system with a local CD-ROM drive, Volume Management automatically mounts the CD directory on /cdrom/volume1/s0 after you install the CD into the drive.

Using a Remote CD-ROM Drive (Solaris 7 Software)

If install4x is to use a CD-ROM drive on a remote system running the Solaris 7 operating environment, Volume Management automatically mounts the CD directory on /cdrom/volume1/s0. Then type the following command after you install the CD into the drive.

# share -F nfs -o ro /cdrom/volume1/s0 

If you are not sharing other NFS systems at boot time, you need to invoke the mountd(1M) and nfsd(1M) daemons.

Type the following commands on the local system.

# mkdir /cdrom

# mount -F nfs -o ro cd-host:/cdrom/volume1/s0 /cdrom 

Using a Remote CD-ROM Drive (SunOS Release 4 Software)

If install4x is to use a CD-ROM drive on a remote system that is running the SunOS release 4 software, type the following as superuser on the remote system.

# mkdir /cdrom

# mount -t hsfs -r /dev/sr0 /cdrom 

Once you have typed the previous commands, edit the /etc/exports and insert the following line.

/cdrom -ro

Then type the following command on the remote system.

# exportfs /cdrom 

Type the following commands on the local system.

# mkdir /cdrom

# mount -F nfs -o ro cd-host:/cdrom /cdrom

Running install4x

After you use one of the previous procedures, the CD is mounted on /cdrom. Invoke install4x by typing the following command.

# /usr/sbin/install4x -m /cdrom/volume1/s0 -e /export

If the -m option is not specified, the following prompt is displayed.

Enter name of directory where the 4.1* cd is mounted [/cdrom]: 

If the -e option is not specified, the following prompt is displayed.

Enter name of export directory [/export]: 

As before, if your site has customized the location of the /export directory, you can direct install4x to load software to a different directory by specifying additional arguments, as in the following command.

# /usr/sbin/install4x -m /cdrom -e /clients

Choosing Software to Load

install4x displays the Install Main Menu shown here.

         *** 4.1* Install Main Menu ***

Choose an Architecture (then select modules to load):
                
                                       Modules

                               Selected         Loaded

[a] sun4.sun4c.sunos.4.1.2         8               0
[b] sun4.sun4.sunos.4.1.2          8               0
[c] sun4.sun4m.sunos.4.1.2         7               0

or begin the loading process for all selected modules:

   [L] Load selected module            +----------------------+
                                       |  Disk Usage:         |
or abort without loading any modules   |     0K Selected      |
                                       |   53634K Free        |
   [Q] Quit without loading            +----------------------+
 
Type any bracketed letter to select that function.

Type ? for help.

The Install Main Menu screen presents several options. The first set (labeled here as a, b, and c) is used to specify the architecture for which software is to be loaded. Other options enable the user to direct software loading to begin (L), quit the program (Q), or ask for help (?).

After you choose each appropriate architecture, the program displays the Module Selection.

Select sun4.sun4c.sunos.4.1.2 modules:
+[a] R proto root......240K  |  [o]   User_Diag...........6352K
+[a] R proto root......240K  |  [o]   User_Diag...........6352K
+[b] R usr...........26240K  |  [p]   Manual..............7456K
+[c] R Kvm............4832K  | +[q] D TLI...................48K
+[d] R Install.........936K  |  [r] D RFS..................912K
 [e] D Networking.....1040K  |  [s] D Debugging...........2928K
 [f] D System_V.......4008K  |  [t]   SunView_Programmers.1840K
 [g] D Sys............5288K  |  [u]   Shlib_Custom........1376K
 [h] C SunView_Users..2664K  |  [v]   Graphics............1784K
 [i]   SunView_Demo....512K  | +[w]   uucp.................608K
+[j]   Text............712K  | +[x]   Games...............3136K
 [k]   Demo...........4264K  |  [y]   Versatec............5960K
 [l] C OpenWin_Users.25936K  |  [z]   Security.............312K
 [m] C OpenWin_Demo...4288K  |  [A]   OpenWindows_Progr..10200K
 [n] C OpenWin_Fonts..7840K  |

Module     + = already loaded        R = Required    C= Common
Legend:   ** = selected for loading  D = Desirable   Others opt

Select [a-A] or a Quick-Pick Option:      +-------------------+
 [1] All Req'd Modules [4] All Opt Moduls | Disk Usage:       |
 [2] All Desr'ble  Mod  [5] All Modules   |    0K Selected    |
 [3] All Common Modules                   |   53634K Free     |
or [D] (done) to return to the main scrn  +-------------------+ 

Packages already loaded are shown on the Module Selection screen with a plus sign (+) before the selection letter (that is, in the previous screen the packages associated with letters a, b, c, d, j, q, w, and x are already loaded). Note that loading packages for one architecture may cause those packages to show as being loaded for other architectures since many packages are shared.

Select modules to load by typing the associated character that is shown in brackets. Pressing the key associated with a module toggles the selection status (that is, the module is selected or deselected). Modules selected to be loaded have asterisks (**) displayed before the selection character. You can reload modules already present by answering Y or y when asked to confirm the apparent redundancy.

The software you must be load in order for a release to operate normally is shown with an R to the right of the selection letter. Software that commonly loaded is shown as with a C, and software it is desirable to load is shown with a D.

The Module Selection screen enables you to pick groups of modules to be loaded. When you enter a 1, it marks all required modules for loading. When you enter a 2, it marks all recommended modules. When you enter a 3, it marks all commonly loaded modules. When you enter a 4, it marks all optional modules. When you enter a 5, it marks all modules shown on the Module Selection screen.

Return to the Install Main Menu by typing D.

            *** 4.1* Install Main Menu ***

 Choose an Architecture (then select modules to load):

                                 Modules
                           Loaded      Selected

[a] sun4.sun4c.sunos.4.1.2    8           0
[b] sun4.sun4.sunos.4.1.2     8           0
[c] sun4.sun4m.sunos.4.1.2    7           0

or begin the loading process for all selected modules:

 [L] Load selected modules                   +-------------------+
                                             |  Disk Usage:      |
or abort without loading any modules:        |    0K Selected    |
                                             |   53634K Free     |
[Q] Quit without loading                     +-------------------+

Type any bracketed letter to select that function.
Type ? for help.

By typing L on the Install Main Menu, you can load all selected modules. Output similar to the following is displayed.

Installing module `proto root' [size: 248K]
        in directory /export/exec/proto.root.sunos.4.1.2 ...

Updating server databases ...

Press any key to continue:

Running convert4x

convert4x updates the Solaris 7 server with information about all SunOS release 4 clients. The following files and directories are updated when you run convert4x:

• /tftpboot--Directory containing network bootable images

• /etc/dfs/dfstab--File containing file systems exported by NFS

• /etc/inet.conf - File containing list of servers that inetd(1M) invokes when it receives an Internet request

• /etc/bootparams - File containing per-client boot specifications

• /etc/hosts--File containing IP-to-host name mapping

Before running convert4x, make certain that the Ethernet addresses are entered in the /etc/ethers file for the clients you are converting. This is necessary because convert4x invokes the rpc.rarpd(1m) daemon.

As superuser, run convert4x by typing the following command.

# /usr/sbin/convert4x 

Optionally, you can specify a single fully qualified path to the location to an alternate client hierarchy. By default, convert4x looks in /export.

As convert4x runs, it displays information on the screen about the actions taken by the script. It warns you if there are any discrepancies in client information. If there is insufficient information for a given client, convert4x reports the error and exits.

If convert4x is successful for existing clients, you do not have to add clients again using Solstice Host Manager.

Chapter 11 Managing Printers, Terminals, and Modems

This chapter describes how to manage printing, and the differences in print commands, in the Solaris 7 environment. It also describes serial port management (which enables terminal and modem connections) through Admintool or the Service Access Facility (SAF).

• "Summary of Printing Differences"

• "Using Printer Commands"

• "Terminal and Modem Management"

• "Service Access Facility (SAF)"

Printing

This section describes how to set up and administer printers after you install Solaris 7 software. This chapter also describes the changes to printer commands that have taken place between the SunOS release 4 and the Solaris 7 release environments.

Summary of Printing Differences

The SunOS release 5.7 LP print service replaces the SunOS release 4 printing facilities, which were provided by the lpd daemon and lpr, lpq, lprm, and lpc commands. Admintool enables youto set up and administer printers through a graphical user interface. You can also use a command-line interface for the LP print service to administer SunOS release 5.7 printers. For detailed information about Admintool and the command-line interface to the LP service, see System Administration Guide, Volume II.

The services provided by the /etc/printcap file in the SunOS release 4 software are handled in the Solaris 7 operating environment by the terminfo database and by the files in the /etc/lp directory.

Print Commands and the Compatibility Package

You can still use many SunOS release 4 print commands if the system is running the SunOS/BSD Source Compatibility Package. Compatibility mode uses SunOS release 4 command names as an interface to underlying Solaris 7 LP print services and does not actually run them the way a SunOS release 4 system would. When a user types SunOS release 4 commands to set up printing or to print files from a Solaris 7 system, the commands create message files that are handled by the SunOS release 5.7 LP print service scheduler.

Solaris 7 printing provides additional capabilities not available in SunOS release 4 systems. These capabilities enable you to control forms, print wheels, and interface programs, and to set up network print services.

Using Printer Commands

As discussed in a previous section, you can continue to use SunOS release 4 print commands if you have the SunOS/BSD Source Compatibility Package. Table 11-1 shows the basic user print command equivalents.

Using SunOS Release 5.7 Printer Administration Commands

This section describes differences between printer setup and administration on SunOS release 4 and Solaris 7 systems. All the underlying system services described are available only in the Solaris 7 operating environment. The SunOS release 4 counterparts are not available even in compatibility mode.

You must use the System V printer administration commands lpadmin(1M) and lpsystem(1M) , the terminfo database, and the configuration files in the /etc/lp directory. See System Administration Guide, Volume II for details.

Table 11-2 shows the command equivalents for setting up printing.

Printing troff

In the SunOS release 4 software, you need the following command to send a troff file to the default printer.

% troff filename

In the Solaris 7 operating environment, you must specify that you want the file printed by piping (|) the output to the lp command. Table 11-3 shows the SunOS release 5.7 troff commands.

Serial Port Management

This section describes serial port management (which enables terminal and modem connections) through Admintool or the Service Access Facility (SAF).

System Administration Guide, Volume II describes the details of Solaris 7 setup and installation procedures for serial devices.

Terminal and Modem Management

Admintool enables you to set up and modify serial port software for terminals and modems.

Admintool provides:

• Templates for common terminal and modem configurations

• Multiple port setup, modification, or deletion

• Quick visual status of each port

This tool provides the capabilities of the Service Access Facility's pmadm command.

Service Access Facility (SAF)

Using SAF, you can manage access to all services in a similar way, whether they are on the network or attached only to local systems. SAF uses Service Access Control (SAC) commands to set up and manage services. It provides uniform access to system services, such as:

• Adding, removing, and modifying terminal line settings

• Adding, enabling, disabling, or removing a port monitor

• Printing information from administrative database files

• Using and administering port monitors

• Adding, enabling, disabling, and removing listen(1M) port monitors

In previous versions of SunOS operating systems, the method for controlling devices depended both on the device providing the access and on the location of that device. Managing user access involved editing many device files.

SAF helps isolate the system administrator from these device dependencies and provides a common interface for managing a range of services, including the ability to:

• Log in (either locally or remotely)

• Access files across the network

SAF's common interface consists primarily of two commands: sacadm and pmadm. The sacadm command controls daemons called port monitors. The pmadm command controls the services associated with the port monitors.

Controlling Port Monitors

SAF's common interface helps control services called port monitors. A port monitor is a program that continuously monitors for requests to log in or requests to access printers or files.

Once a port monitor detects a request, it sets whatever parameters are required to establish communication between the operating system and the device requesting service. Then the port monitor transfers control to other processes (for example, the login program) that provide the services needed.

There are two types of port monitors included in the Solaris 7 operating environment: ttymon and listen. The listen port monitor controls access to network services and handles remote print and file system requests. The ttymon port monitor provides access to the login services needed by modems and alphanumeric terminals.

SAF Functions and Related Programs

SAF's common interface consists primarily of two commands: sacadm and pmadm. The sacadm command controls the port monitors. The pmadm command controls the services associated with the port monitors.

The sacadm command enables you to add and remove port monitors. You can also use the sacadm command to list the status of a port monitor, and to administer configuration scripts for customizing port monitors.

Using the pmadm command, you can add or remove a service, and enable or disable a service. You can, for example, disable all remote logins with one pmadm command. You can also install or replace per-service configuration scripts, or display information about a service.

Using only the sacadm and pmadm commands, a system administrator has complete control over access to resources. However, these two commands are only the interface to the SAF suite of programs and processes that make the integrated management environment possible. The functions and associated programs are:

• Overall administration - sacadm

• Port monitor service administrator - pmadm

• Service Access Control - sac

• Port monitors - ttymon and listen

• Services - logins, remote procedures

The service access control, sac, is the most important program in the SAF suite. It is launched by the init program when a machine is first started. In turn, sac starts all the port monitors listed in its administrative file.

For more information on the SAF in general, or on the different ways to use the sacadm and pmadm commands, see System Administration Guide, Volume II.

Chapter 12 Network Service Administration

This chapter outlines changes to the network facilities, TCP/IP and UUCP.

• "Changes to TCP/IP"

• "Changes to NFS"

• "PPP"

• "UUCP"

Changes to TCP/IP

The user interface to TCP/IP is virtually the same as in previous releases of the Solaris software, but the administration of NIS+ maps is handled through AdminTool, which is different from the process in the SunOS release 4 software and traditional AT&T SVR4.

The NIS+ maps administered by AdminTool include:

• Hosts

• Services

• RPC

• Ethers

When you are ready to configure SunOS release 5.7 TCP/IP facilities, see TCP/IP and Data Communications Administration Guide for information about setting up TCP/IP.

Also, Solaris 7 software bundles the popular traceroute utility. The traceroute utility is used to trace the route an IP packet follows to an Internet host. It is especially useful for determining routing misconfiguration and routing path failures.

TCP With SACK

TCP selective acknowledgment (TCP SACK) provides the support described in RFC 2018 to solve the problems related to congestion and multiple packet drops, especially in applications using TCP large windows (RFC 1323) over satellite links or transcontinental links.

Changes to NFS

The Solaris 7 operating environment simplifies resource sharing with a new set of commands and files to administer NFS resources. Specifically, exportfs and /etc/exports have been replaced by share, shareall, and /etc/dfs/dfstab.This new command set was designed to allow for future distributed file system types.

Several of the daemons associated with NFS have been renamed. rpc.statd, rpc.lockd, and rpc.mountd are now simply called statd, lockd, and mountd.

Unlike the SunOS release 4 environment, there are no client side block I/O daemons (biods) in the Solaris 7 release. They have been superceded by kernel threads. Also, the NFS daemon, nfsd, has been altered so that it does not spawn multiple copies to handle concurrent requests.

Other features included in this release:

• NFS over TCP

• NFS Version 3

• Improved NFS Lock Manager

• Support for Access Control Lists (ACLs)

• WebNFS

• NFS Client Failover

• Kerberos support for NFS file systems

• NFS Large File Support

All these features are described in NFS Administration Guide.

PPP

PPP for Solaris 7 systems is an asynchronous implementation of the standard data link-level, point-to-point protocol (PPP) included in the internet protocol suite. PPP enables a network administrator to create a communications link using modems and telephone lines. See TCP/IP and Data Communications Administration Guide for detailed information about expanding your network with PPP.

LDAP

The Lightweight Directory Access Protocol (LDAP) is an open-standard, platform-independent, access protocol based on the X.500 informational model. It is designed to run over TCP/IP and uses simple string encodings. LDAP applications are client-server applications and the client library included in this release enables developers to write LDAP applications and users to run LDAP enabled applications.

IIIMP

Solaris 7 software implements the Internet Intranet Input Method Protocol (IIIMP) to enable seamless interoperability between the input methods provided in Solaris, Java, and non-X Windows applications.

UUCP

The Solaris 7 UNIX-to-UNIX Copy (UUCP) is similar to the HoneyDanBer UUCP available with SunOS release 4 systems. It uses the same set of configuration files, scripts, and commands, so you should be able to restore most changes you made in SunOS release 4 files and scripts to run with this release. However, the spool directory is organized differently in Solaris 7 due to job grades, a mechanism to help sort and prioritize the work load.

Table 12-1 describes the new files and commands offered with Solaris 7 UUCP that were not part of the SunOS release 4 implementation. Table 12-2 describes the log files added to Solaris 7 UUCP.

Solaris 7 UUCP includes a few additional features that can affect system administration:

• Checkpoint-restart facilities

• Job grades that control UUCP transmission