You can use this part of the guide to help install Solaris 2.6 software, and to understand changes to the local computing environment and to routine tasks.
The Solaris 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.
The UNIX\256 standard, SVR4, accommodates the leading UNIX variants (System V, BSD, SunOS, 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, SunSoft has added extensive functionality 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:
Cross-functional compatibility, which enables the SunOS release 5.6 software to run on SPARC(TM) as well as Intel 386, 486, Pentium and other DOS-compatible CPUs
Industry standards including SVR4 and the ONC family of networking protocols
Common Desktop Environment, a desktop graphical interface. This window environment helps you organize and manage your work. The desktop provides windows, workspaces, controls, menus, and a Front Panel allowing simple access to Mail, File Manager, Printers, Image Tool, Calendar Manager, and others
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
Audio, a new, Motif-based audio application for playing and recording AU, WAV, and AIFF files.
Installation GUI for easing install 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
Java Virtual Machine(TM), provides access to the Java platform for the Solaris operating environment
WebNFS, makes it possible to make a file system accessible through a Web browser.
AnswerBook2(TM) Viewer, Sun's premier online documentation system that uses a web-browser-based interface
The Solaris operating environment is portable, scalable, interoperable, and compatible.
The SunSoft SunOS 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.
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. SunSoft's operating system runs on machines of all sizes, from laptops to supercomputers.
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. Solaris systems can interoperate with every popular system on the market today, and applications running on UNIX can communicate easily.
Computing technology continues to advance rapidly, but the need to remain competitive requires vendors to minimize their costs and to maximize their investments. SunSoft will ensure that as new technology is introduced, the existing software investment is preserved. Users can take advantage of today's solutions and still be compatible with tomorrow's technologies.
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.
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.
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 to the product with few features being withdrawn.
For users, the Solaris operating environment incorporates a suite of powerful DeskSet 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. Specifically, some of the features are:
A 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, 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), Xlib, 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, and many more.
For system administrators, the Solaris operating environment offers a variety of new tools to simplify the administration of a distributed computing environment. These include:
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, administrators 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 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.
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/Device Kernel Interface (DDI/DKI), and Sun Device Driver Interface (Sun DDI). The 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.
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.
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 therefore, are 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, SunSoft chose to concentrate its efforts on tools with graphical user interfaces that simplify the 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.
As you use the Solaris 2.6 operating environment, you will find similarities to the SunOS release 4.x operating environment; however, you will also notice some differences. The rest of this guide focuses on the 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.
Solaris 2.6 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 2.6 operating environment.
End User System Support contains Core System Support plus end user support such as the OpenWindows windowing system and the related DeskSet application files; this cluster includes the recommended software for an end user.
Developer System Support contains End User System Support plus the libraries, include files, and tools needed to develop software in the Solaris 2.6 operating environment. Compilers and debuggers are not included in the Solaris 2.6 operating environment.
For more information about this section's topics, see System Administration Guide.
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:
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.
You can use command-line utilities to install, remove, and check the installation of software packages. The commands are:
The patchadd(1M) and patchrm(1M) commands are used to install and remove patches from a Solaris 2.x 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.
A single range of contiguous blocks or a physical subset of a disk is known as a disk partition in the SunOS release 4.x software. In the SunOS release 5.x 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.x installation program. See System Administration Guide 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.x 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 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(TM) DiskSuite(TM). Table 2-1 describes how disk slices can be set up on each Solaris 2.x platform.
Table 2-1 Slice Differences on Platforms
SPARC |
Intel-based |
---|---|
The whole disk is devoted to the Solaris operating environment. |
The disk is divided into four fdisk partitions, one per operating environment. |
The disk is divided into eight slices, numbered 0-7. |
The Solaris fdisk partition is divided into 10 slices, numbered 0-9. Only 0-7 can be used to store user data. |
See System Administration Guide for a description of customary disk slice assignments for each platform.
You create a UFS file system on a disk slice, which is divided into one or more areas called cylinder groups. A cylinder group is composed of one or more consecutive disk cylinders (the set of tracks on a group of platters that have the same radial distance from the center of the platter). See System Administration Guide 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.
SunOS release 5.6 device names make it easier to infer certain device characteristics from a device name. SunOS release 4.x systems convey type rather than device attributes, which makes it difficult for programs and scripts to derive necessary information about devices. SunOS release 5.6 conventions are slightly different from AT&T SVR4 device names because SunOS release 5.6 allows only eight user-configurable slices on a disk.
In addition, special device files are now stored in the hierarchical /devices directory, with symbolic links to the hierarchical /dev directory, which is used by administrators and users to access devices. The /dev directory contains subdirectories, such as /dev/dsk/*, used to access disk devices, and /dev/rdsk/*, used to access raw disk devices. For more information, see "Device Naming Conventions". For discussions on device naming conventions, see "Device Naming From a Developer's Perspective".
SunOS release 5.6 and SunOS release 4.x file systems are similar, but there are changes in the locations and names of system directories and files. There are also new file systems, new pseudo file systems, and one directory is not used.
"File System Changes", describes file system changes. System Administration Guide describes file system concepts and administration in detail.
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.6 /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.6 /usr directory contains sharable files and executables provided by the system.
The /var directory contains files that change sizes during normal operation. Several files and subdirectories in the /var directory have been added, removed, or changed.
The /var/mail directory replaces /var/spool/mail.
The terminfo database replaces termcap.
The SunOS release 5.6 core kernel is called genunix, and the kernel modules are stored in the /kernel, /usr/kernel, /platform, and /usr/platform directories.
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.6 software.
The SunOS release 5.6 pseudo file systems are:
CACHEFS pseudo file system - can be used to improve performance of slow devices such as a CD-ROM drive.
PROCFS pseudo file system - resides in memory and contains a list of active processes, by process number, in the /proc directory. See the proc(4) man page.
FDFS pseudo file system - provides explicit names for opening files using file descriptors.
FIFOFS pseudo file system - contains pipe files that give processes common access to data.
NAMEFS pseudo file system - used mostly by STREAMS for dynamic mounts of file descriptors on top of files.
SWAPFS pseudo file system - the default swap device when the system boots, or you create additional swap space.
The following file systems are included in the SunOS release 5.6 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.
Support for the RFS file system type has been removed.
Unlike in the SunOS release 4.x software, the SunOS release 5.6 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 for a description of the platform-dependent directories and their contents.
Drivers, file systems, 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.x command, but it includes the capability to unload all unloadable (and not busy) modules, as the following example illustrates.
# modunload -i 0 |
Chapter 18, System and Device Configuration, discusses these topics in more detail.
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.
A new version of the automounter, called AutoFS, has been included. In the SunOS 4.X 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 4.X, the maps for the automounter were named auto.master and auto.home. For Solaris 2.6, 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 4.X releases did not include the maps, so additional installation steps were required.
The Solaris 2.6 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 which 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 which answers AutoFS file system mount and unmount requests. These two programs replace the 4.1.X 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 2.6 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 will be dynamically mounted without mounting all of the other file systems in the hierarchy. Other file systems will be 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.
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 will aid 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 2.6 clients can safely mount mailboxes from both Solaris 2.X and SunOS 4.X mail servers. This enhancement eases administration of mail, especially in large sites.
In the Solaris 2.6 release, /usr/bin/mailx supersedes /usr/ucb/mail. The mailx program has been enhanced to behave the same way as the SunOS 4.x version of /usr/ucb/mail. The /usr/ucb/mail file is now a symbolic link to /usr/bin/mailx.
In SunOS 4.X releases, a program called sendmail.mx was used in DNS sites to access mail exchange records. The new version of sendmail includes the needed functionality and can be configured through /etc/nsswitch.conf.
Mail Administration Guide describes the administration of sendmail.
One of the major changes between SunOS release 4.x and SunOS release 5.6 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 & |
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 on line.
See Chapter 13, Using Name Services, in this guide and NIS+ Transition Guide and NFS Administration Guide for more information.
The print management commands have changed between the SunOS release 4.x and Solaris 2.6 operating environments. In the Solaris 2.6 operating environment, you can use command-line procedures or Admintool to set up printers, and you can use administrative commands or the PrintTool to control print jobs.
See Chapter 11, Managing Printers, Terminals, and Modems, and System Administration Guide for more information.
Users can accomplish the same basic tasks using PrintTool or commands in a shell.
PrintTool is a software tool available in the Solaris 2.6 user environment. It provides a graphical user interface within OpenWindows or CDE through which a user can monitor printers and monitor and cancel print jobs.
The following list summarizes command changes:
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.
The Service Access Facility (SAF) is the tool used for administering terminals, modems, and other network devices. In particular, the SAF enables you to:
The SAF is an open systems solution that controls access to system and network resources through TTY devices and local-area networks (LANs). The SAF offers well-defined interfaces so you can easily add new features and configure existing ones.
The SAF is not a program. It is a hierarchy of background processes and administrative commands. The top-level SAF program is the SAC. The SAC controls port monitors that you administer through the sacadm command. Each port monitor can manage one or more ports.
You administer the services associated with ports through the pmadm command. While services provided through SAC may differ from network to network, SAC and the administrative programs sacadm and pmadm are not tailored to network types.
Table 2-2 illustrates the SAF control hierarchy. The sacadm command is used to administer the SAC, which controls the ttymon and listen port monitors.
Table 2-2 SAF Functions and Associated ProgramsFunction | Program | Description |
---|---|---|
Overall administration |
sacadm |
Command for adding and removing port monitors |
Service Access Controller |
sac | |
ttymon listen |
Monitors serial port login requests Monitors requests for network services |
|
administrator |
pmadm |
Controls port monitor services |
logins, remote procedure calls, and so on |
Services to which SAF provides access |
The services of ttymon and listen are in turn controlled by pmadm. One instance of ttymon can service multiple ports and one instance of listen can provide multiple services on a network interface.
See Chapter 11, Managing Printers, Terminals, and Modems for more information.
Beginning with the Solaris 2.2 software, a new layer of software manages CD-ROM and diskette devices: Volume Management. This software automates the interaction between you and your CDs and diskettes.
CDE OpenWindows File Manager has been modified to use Volume Management to provide immediate user access to CDs and diskettes with file systems on them. See Solaris User's Guide for more information on File Manager's new features.
There are also several new commands to help you administer Volume Management on your system.
For more information, see "Using Volume Management " in Chapter 7, Device Administration.
Converting a SunOS 4.x system to the Solaris 2.6 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 2.6 Server to Support SunOS Release 4.x Diskless/Dataless Clients, for information about creating an environment that serves both Solaris 2.6 and SunOS release 4.x clients.
The Solaris 2.6 environment introduces a number of changes in the way you install software on systems, which makes it different than installing the SunOS 4.x software. These include:
The Solaris 2.6 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 local CD-ROM drives, 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 2.6 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 2.6 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 2.6 software in a limited environment for testing. You can add or remove packages later as you gain more experience with the system.
The Solaris 2.6 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 2.6 installation program guides you step-by-step through the installation process.
The Solaris 2.6 environment provides custom JumpStart(TM) technology to automate installations. This can save you time when you need to install many systems. For more information, see Solaris Advanced Installation Guide.
Converting a SunOS 4.x system to the Solaris 2.6 software involves more than just running the Solaris installation program and loading the software. Usually, there is data on the SunOS 4.x system that needs to be transferred to a Solaris 2.6 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 2.6 operating environment, you might inadvertently choose the wrong disk when you install the Solaris 2.6 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 2.6 Extended Fundamental Types (EFT) are not used, the SunOS release 4.x file system format is upwardly compatible with, and in some cases identical to that used in, the software.
If you are running SunOS 4.1.1 software with QuickCheck or Backup Copilot(TM) utilities installed or the SunOS 4.1.2 software, 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.
Before you begin the installation process, you should save a hard copy of the system's existing disk partitions. It can serve as a reference for many decisions that are made about configuring the Solaris 2.6 system. The following procedure is one way to obtain the disk partition information.
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.
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.
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."
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 2.6 file.
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 2.6 software. This enables you to recover the state of the metadevices when you install Solaris 2.6 software, and serves as a reference as you construct the list of disks attached to your system.
Use the metastat(8) command to save information, as in the following example.
# /etc/metastat -p | lpr |
Save the output of the metadb(8) command.
For example.
# /etc/metadb -i | lpr |
The output of metadb tells you the state database configuration information. This information is necessary to reconstruct the state databases if you reinstall the Solstice DiskSuite product.
You should create a list of the SunOS 4.x files and file systems that you want to back up and restore after installing Solaris 2.6 software.
Make a list of all the system components in the existing SunOS release 4.x 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)
Use the following guidelines to make the list of file systems to save:
As a general rule, do not transfer file systems containing "system" files (for example, the /usr or / file systems) in their entirety.
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.x clients. Typically, /export would be such a file.
There are a number of SunOS 4.x 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 carefully and add to or delete from the list 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 an 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. The suggestions for files to back up include:
./.cshrc
./.profile
./.login
./.logout
./.rhosts
./etc (if the system is an NIS client or has no name service)
./var/spool/calendar
./var/spool/cron
./var/spool/uucp
./var/nis (if the system is an NIS master server)
Boot programs in./tftpboot
Make a list of how much disk space each file system that you want to move to the Solaris 2.6 upgrade, uses. Refer to this list when installing the Solaris 2.6 software, since you can partition disk space for your SunOS 4.x file systems when running the Solaris 2.6 installation program.
If you are converting a network of SunOS 4.x systems to the Solaris 2.6 software, decide the order of the systems to convert to maximize convenience 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 4.x and Solaris 2.6 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.
Once you decide which files or file systems you need to back up from the SunOS 4.x system, you can use the standard commands and procedures given in the SunOS 4.x 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.
Install the Solaris 2.6 software on the server or standalone system using the software installation procedures given in Installation Instructions for Solaris 2.6 (SPARC Platform Edition) or Installation Instructions for Solaris 2.6 (Intel Platform Edition).
The Solaris 2.6 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 4.x file systems so you don't have to restore them.
If you cannot preserve a SunOS 4.x 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 4.x file system that you want to restore (using the disk space requirements you recorded earlier). Then you can restore the SunOS 4.x file systems into the new file systems after Solaris is installed.
This section describes issues related to restoring SunOS 4.x files and file systems you backed up before installing the Solaris 2.6 software.
You can restore the SunOS 4.x file systems that you could not or chose not to preserve into the new file systems you created during the Solaris 2.6 installation. For information about backup and restore procedures, see System Administration Guide.
Before proceeding make sure that the target slice is large enough to accommodate the file system being restored.
Restore any SunOS 4.x user files that you backed up, and copy them to the new system.
First, you must restore the SunOS 4.x system configuration files to a temporary directory on the Solaris 2.6 system. After the information is back on the system in the temporary directory, you need to make it available in the Solaris 2.6 operating environment. Some of the data can just 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 an 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 an 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.
To make data from any of the following files available, merge the changes into the Solaris 2.6 version of the same file. Note, however, that not all of these files were modified on the SunOS 4.x system. Identify files that were changed on the SunOS 4.x 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.x files backed up using the instructions in the first part of this chapter. These files are candidates for merging into the Solaris 2.6 operating environment. See Appendix D, System Files Reference Table, to examine SunOS release 4.x files for changes.
All automounter maps, including /etc/auto.master and any others
/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
Many system files, such as the /etc/fstab file, have been replaced and do not exist under the Solaris 2.6 operating environment. Information from these files must be extracted and manually converted in the Solaris 2.6 environment. See Appendix D, System Files Reference Table, to examine SunOS release 4.x files for changes.
Do not restore operating system executable files (such as system commands in /usr/bin) from the SunOS release 4.x system to your system after installing the Solaris 2.6 software.
You must change the following files before merging the data onto the Solaris 2.6 system:
/etc/uucp - There have been some changes to the UUCP system. The Config, Grades, and Limits files are new in the Solaris 2.6 operating environment. The files Devconfig, Devices, Dialcodes, Dialers, Permissions, Poll, Sysfiles, and systems are the same in the Solaris 2.6 operating environment as they were in the SunOS release 4.x software. These files can be merged together. There are also several SunOS release 4.x files that are not used in the Solaris 2.6 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 2.6 operating environment.
/etc/exports - File systems to be shared on the network under the Solaris 2.6 operating environment use the /etc/dfs/dfstab file instead of /etc/exports. The format of entries in this file follows.
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 2.6 operating environment use the /etc/vfstab file instead of /etc/fstab. The format of entries in the /etc/vfstab file follows.
dev raw_dev mnt_pt fs_type fsck_pass auto_mnt mnt_option |
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.x 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.x structure. The location of the file is now /etc/mail/sendmail.cf.
/etc/ttytab - Under the SunOS release 4.x system, ttytab was used to control serial ports and the characteristics of the terminals on those serial lines. Under the Solaris 2.6 operating environment, the Service Access Facility is used to configure this capability.
/etc/printcap - Under the Solaris 2.6 operating environment, printers are configured using the SunOS release 5.6 LP print service. See System Administration Guide for additional information.
The SunOS release 5.6 software is neither source nor binary compatible with the SunOS release 4.x software. This means that SunOS release 4.x programs and user applications based on those releases may not run correctly under the Solaris 2.6 operating environment. Compatibility packages make it possible for these programs to run on a Solaris 2.6 system.
This chapter briefly discusses two compatibility packages: 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.x commands and applications while your environment and applications migrate to the Solaris 2.6 operating environment.
Some SunOS release 4.x commands are not available in the Solaris 2.6 operating environment. Others exist, but have changed. For information about changes to SunOS release 4.x commands in the Solaris 2.6 operating environment, see Appendix A, Commands Reference Table.
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 2.6 operating environment's increased range of operations and portability.
Compatibility packages are temporary aids to help sites through the transition.
The SunOS BSD/Source Compatibility Package is an optional package available with the Solaris 2.6 operating environment. The package contains a collection of SunOS release 4.x and BSD commands, library routines, and header files otherwise not available with the Solaris 2.6 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.6 interfaces. These interfaces provide a familiar SunOS environment while your environment and applications are migrating to the SunOS release 5.6 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
The Binary Compatibility Package is an optional package available with the Solaris 2.6 operating environment. The package allows existing SunOS release 4.x applications, both statically and dynamically linked, to run under the Solaris 2.6 operating environment without modification or recompilation. It handles most binary interface discrepancies between the two releases transparently. This results in a Solaris 2.6 operating environment where SunOS release 4.x 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.
The Binary Compatibility Package allows most applications to run under the Solaris 2.6 operating environment, making them available for use before they are ported to SunOS release 5.6. With this package, well-behaved application binaries based on SunOS release 4.x system software will run under the SunOS release 5.6 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.6 application development should be done under the base SunOS release 5.6 environment.
Security for the Solaris 2.6 operating environment combines several features from SunOS release 4.x and AT&T SVR4 with capabilities added specifically for the new environment. There are also changes in the packaging of some SunOS release 4.x security programs.
This chapter describes major differences between SunOS release 4.x and Solaris 2.6 operating environment security, and points out how those changes may affect system administration procedures. System Administration Guide describes the administration and use of these features more fully.
Most of the security features from SunOS release 4.x systems are also available in the Solaris 2.6 operating environment. These include:
NFS Administration Guide documents secure NFS and the .rhosts files. TCP/IP and Data Communications Administration Guide describes administering Internet security.
Security for local SunOS release 5.6 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 subsections below summarize security features under local system control.
The SunOS release 5.6 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.
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.
Table 5-1 Files in /etc/default Directory
Controls system login policies, including root access. The default is to limit root access to the console. |
|
Controls default policy on password aging |
|
Controls which root (su) access to the system will be logged and where it will be displayed |
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
The SunOS release 5.6 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 Solaris 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 Solaris 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), 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 for more information about using ACLs.
The Automated Security Enhancement Tool (ASET), available as a separate option with SunOS release 4.x systems, is included with the Solaris 2.6 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 describes ASET setup and monitoring in detail.
Currently available bundled security options are Kerberos security, the SunSHIELD(TM) package, and Pluggable Authentication Module (PAM).
The Solaris 2.6 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 describes the client-side utilities. included in the release. NFS Administration Guide describes the use of Kerberos with the NFS application.
The Solaris 2.6 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.
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 describes the administration of PAM.
This chapter describes differences in tasks you may perform to set up the local user environment after installing the Solaris 2.6 software.
The login shell is the command interpreter that runs when you are logged in. The Solaris 2.6 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. Failed Cross Reference Format lists the features of all three shells.
Table 6-1 Basic Features of the Bourne, C, and Korn Shells
Feature |
Bourne |
C |
Korn |
---|---|---|---|
Syntax compatible with sh |
Yes |
No |
Yes |
Job control |
Yes |
Yes |
Yes |
History list |
No |
Yes |
Yes |
Command-line editing |
No |
Yes |
Yes |
Aliases |
No |
Yes |
Yes |
Single-character abbreviation for login directory |
No |
Yes |
Yes |
Protect files from overwriting (noclobber) |
No |
Yes |
Yes |
Ignore Control-D (ignoreeof) |
No |
Yes |
Yes |
Enhanced cd |
No |
Yes |
Yes |
Initialization file separate from .profile |
No |
Yes |
Yes |
Logout file |
No |
Yes |
No |
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 Solaris Advanced User's Guide for information.
After you change to a new shell, log out and log in again to activate the shell.
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.6 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.
Table 6-2 Initialization Files for Bourne, C, and Korn Shells
Shell |
Initialization File |
Purpose |
---|---|---|
/etc/profile |
Defines system profile at login |
|
|
Defines user's profile at login |
|
/etc/.login |
Defines system environment at login |
|
|
Defines user's environment at login |
|
|
$HOME/.login |
Defines user's profile at login |
Korn |
/etc/profile |
Defines system profile at login |
|
$HOME/.profile |
Defines user's profile at login |
|
Defines user's environment at login in the file specified by the ksh_env variable |
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.x software. The template file locations are shown in Failed Cross Reference Format. Copy the template file (or files) for the appropriate default shell to your home directory before you modify it.
Table 6-3 Default Home Directory Startup Files
Shell |
File |
---|---|
/etc/skel/local.profile |
|
/etc/skel/local.login /etc/skel/local.cshrc |
|
Korn |
/etc/skel/local.profile |
For information on setting up initialization files, see System Administration Guide.
The SunOS release 5.6 software can use the old SunOS release 4.x system files and initialization files such as .login, .cshrc, and.profile to re-create the look and feel of the SunOS release 4.x work environment. Many of these SunOS release 4.x files can be converted, or used as they are, and executed easily.
The installation process in Chapter 3, Converting a SunOS 4.x System to the Solaris 2.6 Environment, explains how to re-create the SunOS release 4.x environment within the Solaris 2.6 operating environment.
The Common Desktop Environment (CDE) is the default Solaris 2.6 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 2.6 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(TM) 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.6 software and its usage is correct.
SunView(TM) software is not part of the Solaris 2.6 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
This section describes your options for performing user and group administration.
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.
This section describes changes to the general procedure for adding user accounts.
The general procedure for adding new users to a SunOS release 4.x system was:
Edit the /etc/passwd file and add an entry for the new user.
Create a home directory and set the permissions for the new user.
Set up skeletal files for the new user (.cshrc, .login, .profile, and so on).
Add the new user to the naming service (NIS).
In the Solaris 2.6 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.x procedure with a few exceptions)
Because the SunOS release 5.6 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 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.
The SunOS release 4.x mail programs are different in the Solaris 2.6 operating environment; however, procedures for setting up mail are still the same. The SunOS release 4.x version of mail is included in the SunOS/BSD Source Compatibility Package. Its user interface is different from the Solaris 2.6 operating environment's version of mail. Additionally, some useful mail facilities are included for compatibility.
In the Solaris 2.6 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.x mail. They are:
mailtool, the OpenWindows interface for the mail program. New Solaris 2.6 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 2.6 mail reading program. It is an enhanced version of SunOS release 4.x /usr/ucb/mail. In the Solaris 2.6 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 them. 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 2.6 interface is similar to the SunOS release 4.x /usr/bin/mail version (see the bin-mail(1) manual page in SunOS 4.x Reference Manual).
See the mail(1) man page for more information on mail.
For a complete discussion of all Solaris 2.6 mail programs, see Mail Administration Guide.
This section outlines the main differences in using document tools between SunOS release 4.x and the Solaris 2.6 operating environment.
The Solaris 2.6 operating environment provides a set of PostScript filters and device-independent fonts. However, most SunOS release 4.x TranScript filters have SunOS release 5.6 equivalents while a few less common ones do not. In SunOS release 5.6 systems, there is no TEX filter, no pscat (C/A/T) filter, and no raster image filter.
The Solaris 2.6 operating environment provides device-independent troff, with the following features: SunOS release 4.x troff input files work with Solaris 2.6 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 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.6 man page directories.
Table 6-4 SunOS release 5.6 man Page Directories
/man Directory |
Contents |
Suffixes |
---|---|---|
man1 |
User commands |
1B - SunOS/BSD compatibility commands |
|
|
1C - Communication commands |
|
|
1F - FMLI commands |
|
|
1S - SunOS commands |
man1M |
System administration commands |
|
man2 |
System calls |
|
man3 |
Library functions |
3B - SunOS/BSD compatibility libraries |
|
|
3C - C library functions |
|
|
3E - ELF library functions |
|
|
3G - C library functions |
|
|
3I - Wide Character functions |
|
|
3K - Kernel VM library functions |
|
|
3M - Math library |
|
|
3N - Network functions |
|
|
3R - RPC services library |
|
|
3S - Standard I/O functions |
|
|
3T - Threads library functions |
|
|
3X - Miscellaneous library functions |
man4 |
File formats |
4B - SunOS/BSD compatibility file formats |
man5 |
Headers, tables, and macros |
|
man7 |
Special files |
|
man9 |
DDI/DKI |
|
man9E |
DDI/DKI entry points |
|
man9F |
DDI/DKI kernel functions |
|
man9S |
DDI/DKI data structures |
Unlike in the SunOS release 4.x software, which searched the individual man directories according to a predetermined order, the SunOS release 5.6 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/ |
The SunOS release 4.x man page table of contents and keyword database is called whatis. In the SunOS release 5.6 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 |
Table 6-5 shows that SunOS release 5.6 version of the man command has additional search options.
Table 6-5 New man Command Options
Option |
Description |
---|---|
-a |
Displays all man pages that match file name. The pages are displayed sequentially in the order they are found. |
-l |
Lists all man pages that match file name. You can use the output of this command to specify a section number with the -s option. |
-s section-number |
Searches section-number for file name. In the SunOS release 4.x software, the man command accepted the section number as an option; in this release, the section number must be preceded by -s. |
-F |
Forces the man command to search all directories until file name is found. This option overrides the windex database and the man.cf file. |
See the man(1) man page for a complete description of the SunOS release 5.6 man command.
This chapter explains SunOS release 5.6 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 have changed between the SunOS release 4.x and SunOS release 5.6 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.6 commands that take device names as arguments must use the SunOS release 5.6 device naming conventions. However, you can still use and recognize the SunOS release 4.x device names if you install the SunOS/BSD Source Compatibility Package. See Source Compatibility Guide for additional information.
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.6 software, sd2a is c0t2d0s0 and sd2b is c0t2d0s1.
Table 7-1 provides some examples that compare the SunOS release 4.x and SunOS release 5.6 device naming conventions.
Table 7-1 SunOS release 4.x and SunOS release 5.6 Device Names
Device Description |
SunOS release 4.x Device Name | |
---|---|---|
/dev/sd0g |
/dev/dsk/c0t3d0s6 |
|
|
/dev/rsd3b |
/dev/rdsk/c0t0d0s1 |
|
/dev/rsd3a |
/dev/rdsk/c0t0d0s0 |
Magnetic tape devices |
/dev/nrmt8 |
/dev/rmt/8hn |
|
/dev/rst0 |
/dev/rmt/0 |
/dev/sr0 |
The commands that report disk information in the SunOS release 5.6 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 those changes.
If you have installed the compatibility packages, SunOS release 4.x command versions can be found under /usr/ucb/df and /usr/ucb/du.
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.6 command differs significantly from that used in the SunOS release 4.x 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.6 version produces a full listing with totals.
Finally, use the SunOS release 5.6 device naming conventions when specifying special device names to this command. See "Device Naming Conventions" for details.
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.
The SunOS release 4.x 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.
The following screen shows sample output for the SunOS release 5.6 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 * Partition Tag Flags Sector Count Sector Mount 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 |
The SunOS release 4.x version of devinfo is incompatible with the SunOS release 5.6 version. To produce output similar to the SunOS release 4.x version, use prtconf with the -v option.
At boot time, the system does a self-test and checks for all devices that are attached to it. 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.
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.
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 Solaris User's Guide for more information on File Manager's new features.
There are also several new commands to help you administer Volume Management on your system.
Volume Management automatically mounts CD and diskette file systems when removable media are inserted into the devices. Any CD or diskette file system will be automatically mounted in the locations described in Table 7-2.
Table 7-2 Location of CD-ROM and Diskette With a File System
Media |
Location |
---|---|
/cdrom/cdrom_name |
|
/floppy/floppy_name |
If the CD or diskette does not contain a file system, it will be accessible in the locations described in Table 7-3.
Table 7-3 Location of CD-ROM and Diskette Without a File System
Media |
Location |
---|---|
/vol/dev/aliases/cdrom0 |
|
/vol/dev/aliases/floppy0 |
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.
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.
Table 7-4 Volume Management Commands
Command |
Description |
---|---|
Removable media mounter. Used by vold to automatically mount /cdrom and /floppy when a CD or diskette is installed. |
|
Cancels a user's request to access a particular CD-ROM or diskette file system |
|
Checks drive for installed media. By default, checks drive pointed to by /dev/diskette. |
|
Notifies user when an attempt is made to access a CD or diskette that is no longer in the drive |
|
Volume Management daemon, controlled by /etc/vold.conf |
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 for information on managing CD-ROM and diskette devices.
This chapter describes changes to procedures for booting and shutting down a system.
See System Administration Guide for detailed descriptions of boot procedures. Man pages for each command are available on line in the "User Commands" section of SunOS 4.x Reference Manual, or in man Pages(1): User Commands.
The Solaris 2.6 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 by automatic loading of devices 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.x fastboot command is available only on Solaris 2.6 systems that have the SunOS/BSD Source Compatibility Package installed. The fastboot command is obsolete in Solaris 2.6 systems because file systems are only checked if the file system state is identified as not clean.
The SunOS release 4.x halt and reboot commands have shutdown(1M) and init(1M) equivalents in the SunOS release 5.6 software.
In the Solaris 2.6 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 2.6 operating environment, it brings the system down quickly without shutting down services in an orderly way. Table 8-1 shows the SunOS release 5.6 commands that replace SunOS release 4.x commands.
Table 8-1 SunOS release 5.6 Replacements for reboot and fastboot
SunOS release 4.x Command |
SunOS release 5.6 Command Replacement |
---|---|
reboot |
shutdown -i -6, init 6 |
fastboot |
boot, init 6 |
The SunOS release 5.6 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.
Be aware of these changes when booting from PROM:
The PROM loads bootblk from the disk. This file is similar to the previous SunOS release 4.x boot block except that it is specific to the UFS file system.
As in the SunOS release 4.x 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.x systems used /vmunix; however, in the SunOS release 5.6 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.x kernel but can be dynamically loaded in SunOS release 5.6 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.
Table 8-2 summarizes booting differences.
Table 8-2 Summary of Booting Differences
SunOS release 4.x |
SunOS release 5.6 |
Feature |
---|---|---|
Now loads ufsboot from disk |
||
boot program |
ufsboot |
Now loads unix from disk |
Bootable kernel image |
||
Mounts and copies unix from network |
||
Mounts /usr and checks file systems |
||
System config scripts |
||
Customizes system kernel, loads modules as needed |
||
Prom monitor, single user, multiuser |
Run states 0 - 6, and S |
System run levels |
/dev/dsk/c0t1d0s6 |
More descriptive logical device names. See "Device Naming Conventions". |
|
boot -r, |
The init(1M) command replaces the SunOS release 4.x fasthalt command in the SunOS release 5.6 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).
Note the following changes to the init command:
SunOS release 5.6 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.6 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 describes this command in detail.
The SunOS release 5.6 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.6 /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.x systems controlled run levels using /etc/rc, /etc/rc.boot, and /etc/rc.local files.
The SunOS release 4.x 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.6 software.
Table 8-3 gives an overview of what each run level's /sbin/rc script does.
Table 8-3 SunOS release 5.6 System Initialization Run Levels
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.x fasthalt commands are available only on SunOS release 5.6 systems that have the SunOS /BSD Source Compatibility Package installed.
See System Administration Guide for detailed descriptions of shutdown procedures. .
In the SunOS release 5.6 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.6 software, it stops the system quickly without shutting down services in an orderly way. Table 8-4 shows the SunOS release 5.6 commands that replace those in the SunOS release 4.x system.
Table 8-4 SunOS release 5.6 Replacements for halt and fasthalt
SunOS release 4.x Command |
SunOS release 5.6 Command Replacement |
---|---|
halt |
shutdown -i 0, init 0 |
fasthalt |
shutdown -i 0, init 0 |
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.
The SunOS release 5.6 shutdown command includes only the options in Table 8-5. This command and its options are described in System Administration Guide.
Table 8-5 SunOS release 5.6 shutdown Command Options
Option |
Description |
---|---|
-g |
Selects "grace" period before shutdown begins. |
-i [init state] |
Specifies an initial run level (see Table 8-3). |
-y |
Runs shutdown without asking confirmation questions. Assumes a "yes" response to all questions. |
-message |
Specifies user-supported message. If more than one word, use quotes around the message. |
By default, the SunOS release 5.6 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 2.6 systems.
See Appendix A, Commands Reference Table, for a summary of changes. See shutdown(1M) for information about how the command works.
The SunOS release 4.x fastboot and fasthalt commands are available if you are running the SunOS/BSD Source Compatibility Package on Solaris 2.6 systems. The file-system checking features of these commands are not appropriate to a Solaris 2.6 system.
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.6 systems are not available on other AT&T SVR4 systems, both commands have shutdown and init equivalents.
This chapter familiarizes you with changes to file system layout and the changes to file systems, virtual file systems, directories, and files. The chapter also describes changes to file system administration including:
Mounting file systems
Monitoring file systems
Sharing file systems
Creating new file systems
Checking file systems
Backing up and restoring files
For more information on understanding and managing file systems, see System Administration Guide.
SunOS release 5.6 and SunOS release 4.x file systems are similar, but there are changes in the locations and names of system directories and files. There are also new file systems 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 SunOS release 5.6 /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.6 /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 TFS pseudo file system is not included in the SunOS release 5.6 software.
The added pseudo file systems are:
The 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.
The NAMEFS pseudo file system is used mostly by STREAMS for dynamic mounts of file descriptors on top of files.
The SWAPFS pseudo file system is the default swap device when the system boots or you create additional swap space.
The following file systems are included in the SunOS release 5.6 directory structure:
The optional /opt file system can be used to store third-party or unbundled software. If /opt is not a separate file system, it may be a symbolic link to /usr/opt.
The /vol file system provides the default file system for the Volume Management daemon, vold(1M). See the volfs(7) man page.
The SunOS release 5.6 file system is hierarchical. Figure 9-1 graphically depicts SunOS release 5.6 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.
The Solaris 2.6 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.
Table 9-1 Solaris 2.6 File Systems and Directories
The SunOS release 5.6 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, with each its own set of commands for file system management. Learning all the variations can be confusing and difficult. The SunOS release 5.6 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 list a summary of supported file systems and the generic file system commands.
Most file system types included in the SunOS release 4.x software are also included in the SunOS release 5.6 software. There is one exception: The translucent file system (TFS) type has been withdrawn from the SunOS release 5.6 software. Table 9-2 summarizes file-system type availability in the SunOS release 4.x and SunOS release 5.6 environment.
Table 9-2 Summary of File System Types
Category |
Name |
Description |
SunOS release 4.x |
SunOS release 5.6 |
---|---|---|---|---|
Disk-based |
UNIX file system |
Yes |
Yes |
|
CD-ROM file system |
Yes |
Yes |
||
PC file system |
Yes |
Yes |
||
NFS |
Sun's distributed computing file system |
Yes |
Yes |
|
Device special file system |
Yes |
Yes |
||
/tmp temporary file system |
Yes |
Yes |
||
Loopback file system |
Yes |
Yes |
||
Translucent file system |
Yes |
No |
||
|
Process access file system |
No |
Yes |
|
|
File descriptor file system |
No |
Yes |
|
|
FIFO/Pipe file system |
No |
Yes |
|
|
Name file system |
No |
Yes |
|
|
Swap file system |
No |
Yes |
|
|
Cache file system |
No |
For more information on file systems, see the proc(4) and fd(4) man pages and System Administration Guide.
The Cache File System can be used to improve performance of remote file systems or slow devices such as CD-ROM. 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.
In the SunOS release 5.6 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 disk.
In SunOS release 4.x 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.6 software uses the swap file as the default dump device instead of specifying a file on disk.
Table 9-3 shows SVR4 file system types that are not supported in the SunOS release 5.6 software.
Table 9-3 Not Supported SVR4 File System Types
Name |
Description |
---|---|
Boot file system |
|
System V file system |
|
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.
Table 9-4 Generic File-System Administrative Commands
Command |
Description |
---|---|
Clears inodes |
|
Reports the number of free disk blocks and files |
|
Lists file names and statistics for a file system |
|
Checks the integrity of a file system and repairs any damage found |
|
File system debugger |
|
Determines the file-system type |
|
Lists or provides labels for file systems when copied to tape (for use by the volcopy command only) |
|
Makes a new file system |
|
Mounts file systems and remote resources |
|
Mounts all file systems specified in a file-system table |
|
Generates a list of path names with their i-numbers |
|
Unmounts file systems and remote resources |
|
Unmounts all file systems specified in a file-system table |
|
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.
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.
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.
In previous SunOS releases, all file system commands were located in the /etc directory. In the SunOS release 5.6 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.
Table 9-5 Locations of File System Commands
Type |
Location of Primary Version |
Location of Duplicate Version (root) |
---|---|---|
Generic |
/usr/sbin |
/sbin |
Specific |
/usr/lib/fs |
This section describes the changes to directories and files between the SunOS release 4.x and SunOS release 5.6 environment.
The /dev directory has changed from a flat directory to a hierarchical one. Table 9-6 describes the subdirectories that have been added.
Table 9-6 Additions to the /dev Directory
Subdirectory |
Description |
---|---|
Contains block disk devices |
|
Contains raw disk devices |
|
Contains pseudo terminal (pty) slave devices |
|
Contains raw tape devices |
|
Contains entry points for the STREAMS Administrative Driver |
|
Contains terminal devices |
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.x /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.6 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.6 /etc directory.
Scripts |
Run Control Files |
---|---|
/sbin/rc0 |
|
/etc/rc1.d |
/sbin/rc1 |
/etc/rc2.d |
/sbin/rc2 |
/etc/rc3.d |
/sbin/rc3 |
/etc/rc4.d |
/sbin/rc4 |
/etc/rc5.d |
/sbin/rc5 |
/etc/rc6.d |
/sbin/rc6 |
/sbin/rcS |
Table 9-8 Additions to the /etc Directory
Subdirectory |
Description |
---|---|
Defines default system configuration |
|
Defines Internet services configuration |
|
Defines LP system configuration |
|
Defines installed optional software |
|
Defines run-state transition operations |
|
Defines Service Access Facility (SAF) configuration |
In the SunOS release 5.6 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.
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 (-).
Field Name |
Content |
---|---|
device to mount |
The entry in this field may be any of the following: The block special device for local UFS file systems (for example, /dev/dsk/c0t0d0s0) The resource name for remote file systems (for example, myserver:/export/home for an NFS system) The name of the slice on which to swap (for example, /dev/dsk/c0t3d0s1) The /proc directory and proc file system type CD-ROM as hsfs file system type /dev/diskette as pcfs or ufs file system type This field is also used to specify swap file systems. For more information on remote file systems, see NFS Administration Guide . |
device to fsck |
The raw (character) special device that corresponds to the file system identified by the device to mount field (for example, /dev/rdsk/c0t0d0s0). This field determines the raw interface that is used by fsck. Use a dash (-) when there is no applicable device, such as for a read-only file system or a network-based file system. |
mount point |
The default mount-point directory (for example, /usr for /dev/dsk/c0t0d0s6). |
FS type |
The type of file system identified by the device to mount field. |
fsck pass |
The pass number used by fsck to determine whether to check a file system. When the field contains a dash (-), the file system is not checked. When the field contains a value of 1 or more, the file system is checked; non-UFS file systems with a 0 fsck pass are checked. For UFS file systems only, when the field contains a 0, the file system is not checked. When fsck is run on multiple UFS file systems that have fsck pass values greater than 1 and the preen option (-o p) is used, fsck automatically checks the file systems on different disks in parallel to maximize efficiency. When the field contains a value of 1, the file system is checked sequentially. Otherwise, the value of the pass number does not have any effect. In SunOS 5.6 system software, the fsck pass field does not explicitly specify the order in which file systems are checked. |
automount? |
yes or no for whether the file system should be automatically mounted by mountall when the system is booted. An auto in the fourth column of your SunOS release 4.x /etc/fstab would translate to a "yes" in this column; a noauto, a "no." Note that this field has nothing to do with the automount program. |
mount options |
A list of comma-separated options (with no spaces) that are used in mounting the file system. Use a dash (-) to show no options. See the mount(1M) man page for a list of the available options. |
For detailed information about the /etc/vfstab file, see System Administration Guide.
The SunOS release 5.6 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.
The SunOS release 5.6 /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.
The SunOS release 5.6 /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.6 /usr directory.
Table 9-10 Additions to the /usr Directory
Subdirectory |
Description |
---|---|
C compilation systems |
|
Executables and other files used by admintool |
Table 9-11 shows files that were in the SunOS release 4.x /usr directory but have been moved in the SunOS release 5.6 software.
Table 9-11 Files Changed in the /usr Directory
SunOS release 4.x Location |
SunOS release 5.6 Location |
---|---|
/usr/sbin |
|
Contents removed |
|
/usr/bin |
|
/usr/lib |
|
/usr/include |
Appendix E, / and /usr File Systems Changes, contains tables with detailed information about the directories and files in each of these file systems.
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 SunOS release 4.x /var/spool/mail directory has been moved to /var/mail.
Two directories were added to the SunOS release 5.x file system: /kernel and /opt.
The SunOS release 5.6 /kernel directory contains the operating system kernel and kernel-level object modules that were in the SunOS release 4.x /sys directory. Table 9-12 describes the subdirectories that have been added to the /kernel directory.
Table 9-12 Additions to the /kernel Directory
Subdirectory |
Description |
---|---|
Device driver and pseudo-device driver modules |
|
Kernel modules to run ELF or a.out executable files |
|
Kernel modules that implement file systems such as ufs, nfs, proc, fifo, and so on |
|
Miscellaneous modules |
|
Modules containing scheduling classes and corresponding dispatch tables |
|
STREAMS modules |
|
Loadable system calls such as system accounting and semaphore operations |
|
Operating system kernel, loaded at boot time |
The SunOS release 5.6 /opt directory contains optional add-on application software packages. These packages were installed in the SunOS release 4.x /usr directory..
The /sys directory has been retired. Its files, used to reconfigure the kernel, have been made obsolete by the dynamic kernel.
The file system administration commands that have changed in the SunOS release 5.6 software include those for:
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.6 system, see System Administration Guide for details on performing the tasks involved.
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.
Change to the directory in which you want to create the mount point.
Create the mount-point directory.
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.
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.
Some of the names and forms of the mount commands are different, as listed in Table 9-13.
Table 9-13 mount Command Differences
SunOS Release 4.x |
SunOS release 5.6 |
---|---|
mount |
mount |
mount -a |
mountall |
umount |
|
exportfs | |
showmount -e |
See Appendix A, Commands Reference Table, for more information on changes to these commands.
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.
In the SunOS release 5.6 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 ".
Table 9-14 shows the file and directory monitoring commands and changes, where they apply.
Table 9-14 File and Directory Monitoring Commands
Command |
Information Provided |
Change (if applicable) |
---|---|---|
Size, age, permissions, owner of files |
None |
|
Total size of directories and their contents |
None |
|
Disk space occupied by file systems, directories, or mounted resources; used and available disk space |
The SunOS release 4.x version of this command provides a different output format containing somewhat different output than the SunOS release 5.6 df command. The SunOS release 5.6 -k option provides output formats similar to those in the SunOS release 4.x command. The SunOS release 4.x df -t filesystem type reports on files of the specified type, whereas the SunOS release 5.6 df-t command prints full listings with totals. |
|
Number of blocks owned by users |
None |
|
Names of files meeting search criteria |
The -n cpio-device SunOS release 4.x option is not available in the SunOS release 5.6 command. Write the current file on device in cpio -c format. |
File systems were "exported" in the SunOS release 4.x 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.6 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).
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" |
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.
The SunOS release 5.6 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.6 device naming conventions (see "Device Naming Conventions").
The SunOS release 5.6 mkfs command differs significantly from the SunOS release 4.x version of the command. The SunOS release 5.6 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.6 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.
The SunOS release 5.6 fsck(1M) command differs significantly from the SunOS release 4.x 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.6 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.6 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.
This section discusses the changes to backup and restore commands and SunOS release 5.6 and describes how to use the ufsdump, ufsrestore, dd, tar, and cpio commands.
The SunOS release 4.x 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.x bar files can be restored on a SunOS release 5.6 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.x dump command can be restored on a SunOS release 5.6 system with ufsrestore.
The SunOS release 5.6 software has two additional utilities for copying file systems: volcopy(1M) and labelit(1M).
The ufsdump command accepts the same command syntax as the SunOS release 4.x dump command. ufsdump also accepts options listed in Table 9-15.
Table 9-15 ufsdump Command Options Not Available With the dump Command
Option |
Function |
---|---|
-l |
Autoload. When reaching the end of a tape (before completing the dump), take the drive off line and wait up to two minutes for the tape drive to be ready again. This gives autoloading (stackloader) tape drives a chance to load a new tape. If the drive is ready within two minutes, continue. If it is not ready after two minutes, prompt an operator to load another tape, as usual, and wait. |
-o |
Off line. When finished with a tape or diskette (completing the dump or reaching the end of the medium), take the drive off line. In the case of a diskette drive, also eject the diskette. In the case of a tape drive, also rewind the tape. This prevents another process that rushes in to use the drive from inadvertently converting the data. |
-S |
Estimate size of dump. Determine the amount of space that is needed to perform the dump and output a single number indicating the estimated size of the dump in bytes. This is most useful for incremental backups. |
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.6 software. In the SunOS release 4.x 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.6 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's appropriate for the system with the tape drive. If the system with the tape drive is a SunOS release 5.6 system, use the device naming convention to identify the tape drive; otherwise, use the SunOS release 4.x convention.
The ufsrestore command in the SunOS release 5.6 software is similar to the restore command in the SunOS release 4.x software. You will be able to restore backups made with the SunOS release 4.x 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.
In the SunOS release 4.x version of the dd command, the size suffix -w (words) denotes a size unit of 4 bytes. In the SunOS release 5.6 version, -w denotes a unit of 2 bytes. In addition, the SunOS release 5.6 version now supports the -unblock and -block conversion options.
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.x command. However, since the device naming scheme has changed in the SunOS release 5.6 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.
Table 9-16 Tape Drive Density Characters in Tape Device Names
Density |
Description |
---|---|
Null |
Default "preferred" (highest) density |
l |
Low |
m |
Medium |
h |
High |
c |
Compressed |
u |
Ultra |
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.6 cpio command supports the SunOS release 4.x options and command syntax. cpio has been expanded to include many new options, as listed in Table 9-17.
Table 9-17 Additional cpio Options
Option |
Command Available With Option |
Description |
---|---|---|
-A |
cpio -o |
Appends files to an archive. |
-k |
cpio -i |
Attempts to skip corrupt file headers and I/O errors encountered. This option lets you copy files from a medium that is corrupted or out of sequence. |
-L |
cpio -o or cpio -p |
Follows symbolic links. |
-V |
cpio -i, cpio -o, or cpio -p |
Special verbose. Prints a dot for each file read or written. This option assures you that cpio is working, without printing all file names. |
-C bufsize |
cpio -i or cpio -o |
Blocks I/O bufsize bytes to the record, where bufsize is a positive integer. When neither -C nor -B is specified, the default buffer size is 512 bytes. |
-E filename |
cpio -i |
Specifies and inputs file containing a list of file names to be extracted from the archive. |
-H header |
cpio -i or cpio -o |
Reads or writes header information in header format. header can be one of: bar (read only), crc, CRC, odc, tar, TAR, ustar, or USTAR. |
-I filename |
cpio -i |
Reads filename as an input archive. |
-M message |
cpio -i -I filename or cpio -o -O filename |
Defines a message to use when switching media. |
-O filename |
cpio -o |
Directs the output to filename. |
-R userid |
cpio -i or cpio -p |
Reassigns ownership and group information for each file to userid. |
cpio requires one of three mutually exclusive options to specify the action to take: -i (copy in), -o (copy out), or -p (pass).
This chapter outlines how to set up a Solaris 2.6 system as a server for SunOS release 4.x diskless/dataless clients by using the discover4x, install4x, and convert4x programs.
Make sure you have read Chapter 3, Converting a SunOS 4.x System to the Solaris 2.6 Environment, if you are setting up a Solaris 2.6 server for SunOS release 4.x clients on a Solaris 2.6 network.
This section explains how to prepare a Solaris 2.6 server so it can serve SunOS release 4.x diskless and dataless clients.
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 4.x System to the Solaris 2.6 Environment.
Some sites will need to continue using SunOS release 4.x clients after the server has been upgraded to Solaris 2.6 software. For instance, Sun-3(TM) systems cannot run Solaris 2.2 or later software and must continue to use the SunOS release 4.x software.
When a SunOS release 4.x /export partition is set up on a server running Solaris 2.6 software, it is referred to as multiple OS operation. Multiple OS operation enables the server to continue serving SunOS release 4.x clients while it runs the Solaris 2.6 operating environment.
The multiple OS operation package is called SUNWhinst and includes three programs that you will need to run to set up a SunOS release 4.x /export directory on a Solaris 2.6 server. The three programs are:
discover4x - This program analyzes the support that remains for SunOS release 4.x clients after the server has migrated to the Solaris 2.6 operating environment. The program looks at the SunOS release 4.x client support and creates the databases that are required for installation of SunOS release 4.x diskless/dataless clients on the Solaris 2.6 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.x clients with the same architecture as the server that migrated to the Solaris 2.6 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.x system required to support diskless/dataless clients that existed before the migration to the Solaris 2.6 operating environment.
convert4x - This program updates the Solaris 2.6 server with information about all the existing SunOS release 4.x clients. This command is used after issuing the discover4x and install4x commands. The updated information enables the existing SunOS release 4.x clients to work with the Solaris 2.6 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.
discover4x analyzes the support that remains for SunOS release 4.x clients after the server has migrated to the Solaris 2.6 operating environment.
As superuser (root), 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 2.6 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 |
Run the install4x program on a server with the Solaris 2.6 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 2.6 operating environment, see "Using a Remote CD-ROM Drive (Solaris 2.6 Software)"
If the system will use a remote CD-ROM drive on a system running the SunOS release 4.x software, see "Using a Remote CD-ROM Drive (SunOS Release 4.x Software)"
Insert the SunOS release 4.x CD into the CD-ROM drive before you proceed.
If you are running install4x on a system with a local CD-ROM drive, after you install the CD into the drive, Volume Management automatically mounts the CD directory on /cdrom/volume1/s0.
If install4x is to use a CD-ROM drive on a remote system running the Solaris 2.6 operating environment, after you install the CD into the drive, Volume Management automatically mounts the CD directory on /cdrom/volume1/s0. Then type the following command.
# 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 |
If install4x is to use a CD-ROM drive on a remote system that is running the SunOS release 4.x 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 |
After you use one of the previous procedures, the CD is mounted on /cdrom. Now 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 |
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, will select or deselect the module, depending on its previous status). 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.
SunSoft has determined which software must be loaded for a release to operate normally (shown with R to the right of the selection letter), which software is commonly loaded (shown as C), and which software should be loaded (shown as D).
Additionally, the Module Selection screen readily 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: |
convert4x updates the Solaris 2.6 server with information about all SunOS release 4.x 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 via 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 the convert4x is successful for existing clients, you do not have to add them again using Solstice Host Manager.
This chapter describes how to manage printing, and the differences in print commands, in the Solaris 2.6 environment. It also describes serial port management (which enables terminal and modem connections) through Admintool or the Service Access Facility (SAF),
This section describes how to set up and administer printers after you install Solaris 2.6 software. This chapter also describes the changes to printer commands that have taken place between the SunOS release 4.x and the Solaris 2.6 release environments.
The SunOS release 5.6 LP print service replaces the SunOS release 4.x 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.6 printers. For detailed information about Admintool and the command-line interface to the LP service, see System Administration Guide.
The services provided by the /etc/printcap file in the SunOS release 4.x software are handled in the Solaris 2.6 operating environment by the terminfo database and by the files in the /etc/lp directory.
You can still use many SunOS release 4.x print commands if the system is running the SunOS/BSD Source Compatibility Package. Compatibility mode uses SunOS release 4.x command names as an interface to underlying Solaris 2.6 LP print services and does not actually run them the way a SunOS release 4.x system would. When a user types SunOS release 4.x commands to set up printing or to print files from a Solaris 2.6 system, the commands create message files that are handled by the SunOS release 5.6 LP print service scheduler.
Solaris 2.6 printing provides additional capabilities not available in SunOS release 4.x systems. These capabilities enable you to control forms, print wheels, and interface programs, and to set up network print services.
As discussed in a previous section, you can continue to use SunOS release 4.x print commands if you have the SunOS/BSD Source Compatibility Package. Table 11-1 shows the basic user print command equivalents.
Table 11-1 User Print Command Equivalents
SunOS release 4.x |
SunOS release 5.6 |
Function |
---|---|---|
|
Print a file to the default printer |
|
lpr -P printer filename |
lp -d printer file |
Print a file to a specific printer |
Look at a list of the files waiting to print on the default printer |
||
lpstat -d |
Determine which is the default printer |
|
Check /etc/printcap
|
lpstat -a |
Determine which printers are available |
|
|
Cancel a print job on the default printer |
This section describes differences between printer setup and administration on SunOS release 4.x and Solaris 2.6 systems. All the underlying system services described are available only in the Solaris 2.6 operating environment. The SunOS release 4.x counterparts are not available even in compatibility mode.
You must use the System V printer administration commands, lpadmin(1M) and lpsystem(1M) instead. Use the terminfo database and the configuration files in the /etc/lp directory instead. See System Administration Guide for details.
Table 11-2 shows the command equivalents for setting up printing.
Table 11-2 Printer Administration, Setup, and File Equivalents
SunOS release 4.x |
SunOS release 5.6 |
Function |
---|---|---|
Control line printer functions |
||
/etc/lp/printers/printername/* |
File that defines printer functions |
|
|
Directory where printing system stores spool and lock files |
|
Not available |
Move print queues between printers |
|
lpc down |
Stop queueing to a printer |
In the SunOS release 4.x software, you need the following command to send a troff file to the default printer.
% troff filename |
In the Solaris 2.6 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.6 troff commands.
Table 11-3 SunOS release 5.6 troff Commands
SunOS release 5.6 Command |
Function |
---|---|
troff file | /usr/lib/lp/postscript/dpost|lp |
Sends to default printer that supports troff jobs |
troff file| /usr/lib/lp/postscript/dpost|lp -d printer |
Sends to a particular printer |
troff file | lp-Ttroff |
This section describes serial port management (which enables terminal and modem connections) through Admintool or the Service Access Facility (SAF).
System Administration Guide describes the details of Solaris 2.6 setup and installation procedures for serial devices.
Admintool is a tool that readily 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.
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 printers across the network
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.
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 2.6 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'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.
This chapter outlines changes to the network facilities, TCP/IP and UUCP.
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.x 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.6 TCP/IP facilities, see TCP/IP and Data Communications Administration Guide for information about setting up TCP/IP.
The Solaris 2.6 operating environment simplifies resource sharing with a new set of commands and files to administer NFS resources. In specific, exportfs and /etc/exports has 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.x environment, there are no client side block I/O daemons (biods) in the Solaris 2.6 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 for Solaris 2.6 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.
The Solaris 2.6 UNIX-to-UNIX Copy (UUCP) is similar to the HoneyDanBer UUCP available with SunOS release 4.x 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.x files and scripts to run with this release. However, the spool directory is organized differently in Solaris 2.6 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 2.6 UUCP that were not part of the SunOS release 4.x implementation. Table 12-2 describes the log files added to Solaris 2.6 UUCP.
Table 12-1 New SunOS release 5.6 UUCP Files and Commands
Command or File |
Description |
---|---|
D. data files P. data files |
These data files are created when a UUCP command line specifies copying the source file to a spool directory. All data files have this format: systmxxxxyyy. systm is the first five characters in the name of the remote system. xxxx is a four-digit job sequence number assigned by UUCP. yyy is a subsequence number used to distinguish between several D. files created for a work (C.) file. |
Maps text grade names to system names. |
|
Specifies the number of concurrent UUCP sessions that can occur. Replaces Maxuuscheds and Maxuuxqts files in previous versions. |
|
Contains information to override UUCP parameters that can be tuned. Currently, the only parameter of this type is Protocol, so system administrators normally will not have to modify this file. |
|
Prints the list of service grades available on the system to use with the -g option of uucp(1C) and uux(1C). |
Solaris 2.6 UUCP includes a few additional features that can affect system administration:
Checkpoint-restart facilities
Job grades that control UUCP transmission
Two new configuration files to limit the number of concurrent UUCP sessions that the system can run, and to override UUCP parameters that can be tuned
The following sections describe the system administration differences made by each of these additions.
When communication link failures interrupt UUCP transmissions between SunOS release 4.x systems, the transmission starts again from the beginning of the file as soon as communication resumes. Communication between two systems running Solaris 2.6 UUCP resumes where it was interrupted instead of restarting at the beginning. This makes better throughput possible, especially on erratic or noisy transmission lines.
The systems use two new files to store sent and received data and to compare the sizes of the files to determine where to restart transmission. The systems use.P files to store received data and.D files to store transmitted data. These files replace the TM. files of previous UUCP versions. If only one system is running SunOS release 5.6 UUCP, no comparison can take place and transmissions restarts from the beginning.
Job grading enables administrators to divide jobs into work loads that compete against others of similar size, type, priority, or all three. You can sort work loads using any one or a combination of these factors. You can also set access permissions allowing users and groups to obtain each grade of UUCP service.
In the SunOS release 4.x software, the user has to choose the grade when the job is submitted. Grades are a single letter, not a name, as they are in the Solaris 2.6 operating environment. Solaris 2.6 systems enable administrators to define job grades for an entire site.
The /etc/uucp/Limits file specifies the maximum number of concurrent uucico, uuxqt, and uusched processes permitted on a system. This single file replaces the Maxuusched and Maxuuxqt parameters on previous releases.
The /etc/uucp/Config file contains information to override UUCP parameters that can be tuned. Currently the only parameter available is Protocol and it should normally not be altered by system administrators.
Solaris 2.6 UUCP provides four log files in addition to the four supplied in previous versions. These files record accounting, command, performance, and security information. The command and security log files are created if they do not exist. The accounting and performance log files are written only if they already exist.
Table 12-2 Additional SunOS release 5.6 UUCP Log Files
File Name |
Function |
---|---|
Records account information for billing |
|
Records statistics on uucico operations |
|
Records attempted security violations |
|
Records information on commands issued by users or administrators |
When you are ready to set up and use SunOS release 5.6 UUCP, see TCP/IP and Data Communications Administration Guide for complete information.
The network information service (NIS), which is part of the SunOS release 4.x environment, is widely being replaced with the network information service plus (NIS+). NIS+, introduced with the SunOS 5.0 system, is a completely redesigned name service that takes into account changes in customer client/server environments. DNS ( domain name system) is an existing, complementary name service used for intercompany Internet communication. This chapter discusses NIS+ and compares it to NIS and DNS.
For more information about planning an NIS+ upgrade and installing NIS+, see NIS+ Transition Guide and NFS Administration Guide.
The system administration documentation set for the Solaris 2.6 operating environment emphasizes a system that is using NIS+.
The Solaris 2.6 operating environment uses standard naming interfaces (for example, gethostbyname) to support multiple naming services (such as NIS, NIS+, and DNS, among others), thereby allowing applications to access data transparently from different services. One instance of this is the Name Service Switch capability in the Solaris 2.6 operating environment, which allows applications to use a UNIX standard naming interface (for example, getxxbyyy interfaces). See the nsswitch.conf(4) man page for more information.
NIS+ is a name service built on top of the ONC transport-independent remote procedure call (TI-RPC) interface. NIS+ has significant advantages over NIS in the areas of security, performance, scalability, and administration.
DNS supports the model of a hierarchical name space with autonomously administered name servers. Although NIS+ uses a similar hierarchical naming model, it focuses on supporting changing system administration data and other requirements of enterprise networks.
DNS and NIS+, therefore, are complementary name services:
DNS is used for intercompany communication
NIS+ supports administration of enterprise networks
Table 13-1 shows the features and benefits of DNS compared to NIS+.
Table 13-1 DNS and NIS+ Features and Benefits Compared
Feature |
DNS |
NIS+ |
---|---|---|
Security |
Unrestricted access to data |
All operations can be authenticated |
|
|
Administrator designates access rights for objects and entries |
API and human interface |
Allows read-only access to name service |
Allows read-write access to name service. Provides: - Efficient support of changing network environment - API support of administrative operations - Support of administrative and other distributed applications |
Updating |
By transfer of zone master files |
By incremental data transfer - Fast support of changing network environments - Stronger consistency |
Compatibility with NIS |
Not applicable |
Existing NIS applications can migrate smoothly |
Data support |
ASCII data only with packet size restriction |
Binary and ASCII data. Provides: - Support of variable information - Support of larger objects |
The main strength of DNS is supporting hierarchical database partitions and replicas containing entries of relatively static information (such as host name and IP address). DNS enables you to access the Internet.
NIS+, in contrast, is a secure repository of changing administrative information (such as email aliases, Ethernet addresses, RPC program numbers) for enterprise networks.
Table 13-2 summarizes several major enhancements in NIS+ compared to NIS.
Table 13-2 NIS and NIS+ Features Compared
Feature |
NIS |
NIS+ |
---|---|---|
Name space |
Has a flat ; is non-hierarchical organization; centralized flat file database for each independent network domain |
Has a hierarchical organization; partitioned into directories to support each network subset or autonomous domain |
Data Storage Scheme |
Multiple bicolumn "maps" (files) having key-value pairs |
Multicolumn database with multiple, searchable columns |
Resource Access Across Domains |
Not supported |
Permitted for authorized users |
Privileges for Updating |
Updates require superuser privileges on master server |
Updates can be performed remotely by authorized users |
Update Process |
Updates require using make files on master servers |
Updates are performed easily through command-line interface |
Update Propagation |
Is administrator initiated and requires transfer of whole maps |
Automatic and high-performance updating via incremental transfer |
Security |
Database not secure |
Fine-grained access control to NIS+ directories, table column, and entries |
Commands and Functions Prefixes |
Prefixed by the letters yp, as in ypmatch(1) and ypcat(1) |
Prefixed by the letters nis, as in nismatch(1) and nischown(1) |
NIS+ includes features that enable NIS sites to migrate to the new name service in a smooth, phased manner. NIS sites that migrate to NIS+ will gain the following benefits:
Distributed and remote administration of network domains by authorized users
Support for hierarchical domains
Fast and automatic propagation of updates from master to replica servers
Fine-grained access to tables and network resources
Easier and more consistent administrative operations
Increased naming service reliability and availability
NIS+ supports the following combinations of systems:
SunOS release 5.6 software installed on all servers and clients
SunOS release 5.6 software installed on one server, but combined with some SunOS release 4.x servers
For a network, there are three main migration paths from NIS to the NIS+ name service:
Upgrade all servers and clients to NIS+
Upgrade all servers at once to NIS+ and enable its compatibility mode to support SunOS 4.x clients
Use different domain names so NIS and NIS+ can coexist
The first step to upgrading your network is to decide which servers to upgrade to the NIS+ name service and which servers can continue to run NIS. See NIS+ Transition Guide for more information.
The Solaris Common Desktop Environment (CDE), compatible among various workstation manufacturers, provides users with a desktop graphical interface on a Sun(TM) Workstation(TM) running Solaris 2.4 software or later. This window environment helps you organize and manage your work. The desktop provides windows, workspaces, controls, menus, and a Front Panel. When you login to your windows environment the first time, you have a choice of using either OpenWindows or Solaris CDE as your default desktop.
In March of 1993, Sun, Hewlett-Packard, IBM and Novell announced an agreement to develop a graphical user interface that would bring a consistent look and feel to major UNIX system-based workstations and desktop computers. From the start, the CDE development effort was guided by one goal: to make UNIX easier to use for end users and application developers.
The result of this joint development effort is the Common Desktop Environment. CDE is one of two desktops packaged with the Solaris 2.6 environment (the other is the OpenWindows desktop). Over time, CDE will emerge as the standard desktop for Sun, Hewlett-Packard, IBM, Novell and many others in the UNIX workstation market.
Solaris CDE includes a desktop server, a Session Manager, a Window Manager (based on Hewlett-Packard's Visual User Environment), and numerous desktop utilities.
To learn how to use Solaris CDE, see Solaris Common Desktop Environment: User's Guide.
Because CDE provides a consistent computing environment across major UNIX platforms, end users can easily move between different machines. CDE also aids application development by supplying a single, standard set of programming interfaces for any conforming Sun, HP, IBM, and Novell platform. A single API enables developers to create applications that are consistent in appearance and behavior across CDE-compliant systems.
The CDE development environment is based on the X11R5 server and produces applications with a look and feel based on the Open Software Foundation's Motif 1.2 specification.
Some of the features of the Solaris CDE desktop include:
The Front Panel
Style Manager
File Manager
Application Manager
The Front Panel is a special window at the bottom of the display. It provides controls, indicators, and subpanels you use in your everyday work. The Front Panel also provides the workspace switch for selecting a workspace.
Many controls in the Front Panel, such as the File Manager control, start applications when you click them. Some controls, like the Printer control, are also drop zones. You can drag a file icon from File Manager and drop it on the Printer control to be printed.
Arrow buttons over Front Panel controls identify subpanels--click an arrow button to open a subpanel.
Click this icon:
To use Style Manager to easily customize many elements of the desktop including:
Colors
Workspace backdrops
Font size
Keyboard, mouse, and window behavior
Click the File Manager icon:
To display the files, folders, and applications on your system as icons.
Click this icon to open the Application Manager window:
Application Manager provides access to applications you use in your everyday work through action icons. You use action icons to start applications. Application Manager stores action icons in special folders called application groups.
You can place the action icons you use frequently on the workspace backdrop.
With the Solaris 2.6 software you can choose to log in to either the OpenWindows desktop or the CDE desktop from your login screen. For more information on logging in, refer to the Login Manager help volume or Chapter 2, "Starting a Desktop Session," in Solaris Common Desktop Environment: User's Guide.
Some of the desktop services you are used to using in the OpenWindows environment are located in different places in Solaris CDE. Table 14-1 highlights some of the differences.
Table 14-1 Location of Desktop Services
Desktop Service |
OpenWindows |
CDE |
---|---|---|
Logout |
Workspace menu |
Front Panel |
LockScreen |
Utilities menu |
Front Panel |
Customize Workspace |
Workspace menu |
Style Manager |
Save Workspace |
Utilities menu |
Style Manager |
Refresh |
Utilities menu |
Front Panel |
Properties |
Workspace menu |
Style Manager |
Help |
Workspace menu |
Front Panel, Application Manager, Workspace menu |
Windows, menus, buttons and the mouse are used in Solaris CDE slightly differently than in the OpenWindows environment. For complete information on using window, menus, buttons and the mouse, refer to Chapter 1, "Basic Skills," in Solaris Common Desktop Environment: User's Guide.
In the OpenWindows environment, the main way to start an application was through the Workspace menu. A Workspace menu still exists in Solaris CDE; however, the main access point for workspace functionality is the Front Panel.
The applications available through the Workspace menu include the items on the Front Panel and also a subset of the applications available to you within Application Manager. Refer to Chapter 6, "Running Applications from the Desktop," in Solaris Common Desktop Environment: User's Guide for complete information on Application Manager.
The items available through Style Manager are: Color, Font, Backdrop, Keyboard, Mouse, Audio, Screen, Window, and Startup. This replaces the Workspace Properties window in the OpenWindows environment. For complete information on Style Manager, refer to Chapter 7, "Customizing the Desktop Environment," in Solaris Common Desktop Environment: User's Guide.
A folder in CDE Application Manager, titled OpenWindows, contains your OpenWindow applications.
If you ran OpenWindows applications from the command line, you can run them the same way from the terminal emulator (Terminal application) in Solaris CDE. Refer to Chapter 6, "Running Applications from the Desktop," in Solaris Common Desktop Environment: User's Guide for complete information on Application Manager.
In the OpenWindows environment, application-wide settings are set via the Properties dialog box, accessed from the Edit menu. In CDE, application-wide settings are set via the Options areas. Options choices are generally located under the application's File menu or the separate menu item, Options.
In CDE, Properties (if they exist in an application) are found under the application's Edit menu and are used to set characteristics of an object, such as its date or name, or display identifying characteristics of an object, such as typefaces. In CDE, format settings are usually found under the Format menu and enable margin and paragraph alignment to be set for a single paragraph, file, or message.
CDE Global options are like the properties you set from the Workspace menu in the OpenWindows environment. You now set these properties from the CDE Style Manager application. See Chapter 7, "Customizing the Desktop Environment," in Solaris Common Desktop Environment: User's Guide.
If you did not change your keyboard defaults in the OpenWindows environment they should stay the same within CDE. If you want to change your defaults, use the Style Manager Keyboard dialog box. See Chapter 7, "Customizing the Desktop Environment," in Solaris Common Desktop Environment: User's Guide. If you need to make changes to your UNIX keyboard bindings, refer to Chapter 10, "Using Text Editor," in Solaris Common Desktop Environment: User's Guide.
If you did not change your mouse defaults in the OpenWindows environment they should stay the same within CDE. If you want to change your defaults, use the Style Manager Mouse dialog box. Some of the names have been changed for the functions: You still have double-click, acceleration, and threshold. Mouse button order in CDE is called "handedness. See Chapter 1, "Basic Skills," in Solaris Common Desktop Environment: User's Guide.