Education Solaris 10 System Administration Essentials Pdf


Sunday, July 7, 2019

Preface Solaris™ 10 System Administration Essentials Solaris™ 10 System Administration Essentials is the centerpiece of the new series on Solaris system. CHAPTER 1 Managing File Systems. CHAPTER 2 Installing the Solaris 10 Operating Environment. CHAPTER 3 Perform System Boot and Shutdown. For the Oracle Solaris 10 release, new features that might be interesting to system administrators are covered in sections called What's New in.

Solaris 10 System Administration Essentials Pdf

Language:English, Spanish, German
Genre:Fiction & Literature
Published (Last):31.07.2016
ePub File Size:22.85 MB
PDF File Size:13.64 MB
Distribution:Free* [*Regsitration Required]
Uploaded by: MARCIA

essential system administration tasks in the Solaris 10 OS. You will be instructed in Solaris 10 Operating System Essentials (SAS10). Course Objectives. (c) >>> page 1 of 9 PDF File: d3ba Solaris 10 System Administration Essentials (Oracle Solaris System. Get Instant Access to PDF File: #d3e4b8a Solaris 10 Zfs Essentials (Oracle Solaris System Administration Series) By Scott Watanabe [EBOOK.

You can choose None if you do not have a router or do not want the software to detect an IP address at this time. The software automatically tries to detect an IP address on reboot. Locales For which geographic regions do you want to install support? Note that, if your system has Energy Star version 3 or later, you are not prompted for this information. Select Default installation to format the entire hard disk and install a preselected set of software.

Select Custom installation to modify the hard disk layout and select the software that you want to install. This option is not available in text installer. Note that, if you want select packages to add or remove, you will need to know about software dependencies and how Solaris software is packaged. Select Disks On which disks do you want to install the Solaris software? Select Disks for fdisk Partition Customization? IP Address: Remote File System: Local Mount Point: From the Library of Daniel Johnson This page intentionally left blank From the Library of Daniel Johnson 2 Boot, Service Management, and Shutdown This chapter describes how the Solaris 10 operating system boots and explains options users and administrators have for changing the boot process.

The chapter also describes the two methods of shutting down a Solaris 10 system. Some of the information in this chapter describes Solaris boot processes that apply to both the x86 and SPARC platform, but the chapter focuses primarily on booting the x86 platform. By default, the bootloader displays a boot menu with two entries: See the boot 1M manual page for more about the boot archive. The failsafe entry facilitates troubleshooting and recovery. SunOS Release 5.

Use is subject to license terms. Instead, the processes that implement most systemdelivered functionality on Solaris are started by the service management facility or SMF.

Accordingly, the Solaris init contains special-purpose functionality to start and restart as necessary the daemons that implement SMF. In turn, the facility is responsible for executing the init scripts. SMF is described in more detail in the next section. Users accustomed to the Solaris 9 operating system will notice that the Solaris 10 operating system displays much less information on the console during boot. From the Library of Daniel Johnson 35 2. Figure 2.

Recognized arguments are listed in the kernel 1M manual page. Commonly used arguments are shown in Table 2. Table 2. See the kmdb 1M manual page and later in this chapter. Start only basic services and present an sulogin prompt. The boot arguments for a single boot sequence can be set from the GRUB menu. Select an entry and press the e key.

GRUB will display the entry editing screen, as shown in Figure 2. This menu is accessed at boot time, by typing e to interrupt the boot process, then with the boot entry selected, typing e again to enter the edit menu for the selected entry. Select the line beginning with kernel and press the e key.

After the path for unix, add the boot arguments. Boot arguments for a single boot can also be set on the reboot command line. See the reboot 1M manual page. Boot arguments can be installed permanently by modifying menu.

From the Library of Daniel Johnson 37 2. Each run level is associated with particular system behaviors see Table 2. By default, Solaris boots into run level 3. It can be changed to a single boot sequence by specifying -s in the boot arguments refer to Table 2. To change the run level while the operating system is running, use the init command.

See its manual page for a detailed description of run levels. No login services running except for sulogin on the console. Local login services running. Some applications—usually local—may be running. Third-party applications may behave differently than under run level 3.

From the Library of Daniel Johnson 2. Once logged in, svcadm milestone all can be used to instruct SMF to continue initialization as usual. If the kernel panics, kmdb will stop the kernel and present a debugging prompt on the console. For more information, see the kmdb 1 manual page. Selecting it will start the same kernel, but with the failsafe boot archive.

By default it also launches an interactive program that facilitates updating the normal boot archive for instances of the Solaris OS found on the disk. Each service is modeled as an instance of an SMF service, which allows for a single service implementation to be executed multiple times simultaneously, as many are capable of doing.

Services and service instances are named by character strings. The FMRI of the default instance of cron is svc: The service instances known to SMF can be listed with the svcs -a command.

Service implementations are controlled by the SMF service manager, svc. The -l ell option produces long output, like the following: The name line provides a short description. The remaining output is explained later. From the Library of Daniel Johnson 41 2. This time is not necessarily the last time the service instance changed states since SMF allows transitions to the same state.

Details of both are explained in Section 2. SMF dependencies represent dependencies of the service implementation on other services. The service manager uses dependencies to determine when to start, and sometimes when to stop, service instances. Each dependency has a grouping and a set of FMRIs. SMF recognizes four dependency groupings.

Until then, the service will remain in the offline state. The service manager can also stop services according to dependencies. SCF is described in the next section. If the method exits with status 0, the service manager infers that the service has started successfully the daemons were started in the background and are ready to provide service and transitions its state to online.

If the method exits with status 1, the service manager concludes that the service failed and re-executes the method. The service daemon will inherit this unless the author wrote the start method to do otherwise. After starting a service implemented by a daemon, the service manager will monitor its processes.

If all processes exit, then the service manager will infer that the service has failed and will attempt to restart it by re-executing the start method. If this happens more than ten times in ten seconds, then the service manager will give up and transition the service to the maintenance state. Processes are monitored through a process contract with the kernel.

Contracts are a new kernel abstraction documented in contract 4 ; process-type contracts are From the Library of Daniel Johnson 2.

Services treated by the service manager in this way are referred to as contract services. Stop methods exit with status 0 to signal that the service has been stopped successfully, in which case the service manager will transition the service to the disabled state.

However, the facility uses process contracts to ensure that a contract service has been fully stopped. Each time, svc. The processes associated with a contract service can be listed with the svcs -p command. Ensuring this is the case does require programs to be executed e. For such services, svc. After the start method exits with status 0, the service is transitioned to online and any processes it may have started in the background are not monitored.

Solaris 10 includes a single alternative restarter: Before then, inetd reports services delegated to it to be online to signify readiness, even though no daemons may have been started. The restarter for a service is listed by the svcs -l command. Services governed by the models provided directly by the service manager are listed with the special FMRI of svc: When all enabled services are online, svcs -x exits without printing anything.

The svcs -x command may explain precisely why the service was placed in that state. When the problem with a service in the maintenance state is resolved, the svcadm clear command should be executed for the service. Service manifests can also be imported directly into the SCF repository with the svccfg import command. In both cases, only the four most recent backups are retained and older copies are deleted. However, this must not be done while the svc. It can be restored with the svccfg restore command.

They differ in how applications are stopped. Packages This chapter describes packages and package tools and includes step-by-step procedures for installing and removing packages. Sun and its third-party independent software vendors ISVs deliver software as a collection of one or more packages. The following sections describe packages and provide step-by-step procedures for adding and removing packages. Patches are generally delivered as a set of sparse packages.

Sparse packages are a minimalist version of a regular package. The Solaris OS provides a set of utilities that interpret this format and provide the means to install a package, to remove a package, and to verify a package installation. Packages 3. The structure of a package consists of the following: Different installation scripts include: From the Library of Daniel Johnson 49 3.

See Table 3. For more information about these tools, see System Administration Guide: For the guide and man pages, see http: Table 3. The installer must be available either locally or remotely. Also, this GUI can determine what software is already installed on a system. Use the Solaris Product Registry to remove or display information about software products that were originally installed by using the Solaris installation GUI or the Solaris pkgadd command.

Solaris Product Registry prodreg Viewer commandline interface CLI Use the prodreg command to remove or display information about software products that were originally installed by using the Solaris installation GUI or the Solaris pkgadd command. Packages Table 3. A signed package includes a digital signature.

The -g option instructs the pkgtrans command to generate and store a signature in the resulting data stream. The package tools, such as the pkgadd and pkgrm commands, also access or modify installation data.

From the Library of Daniel Johnson 51 3. The pkgadd and pkgrm commands store information about packages that have been installed or removed in a software product database. By updating this database, the pkgadd and pkgrm commands keep a record of all software products installed on the system. Become superuser or assume an equivalent role.

Remove any already installed packages with the same names as the packages you are adding. This step ensures that the system keeps a proper record of software that has been added and removed.

Caution If the pkgid is omitted, the pkgrm command removes all available packages. Install a software package to the system. The syntax for the pkgadd command is as follows: Packages The following list provides explanations of each argument available for pkgadd. Basic Administration, which is available on http: If the package is not there, the package installation fails.

If the pkgadd command encounters a problem during installation of the package, then it displays a message related to the problem, followed by this prompt: Do you want to continue with this installation? Chose one of the following responses: The pkgadd command continues to install the other packages. Verify that the package has been installed successfully.

Otherwise, the pkgchk command reports the error. From the Library of Daniel Johnson 53 3. Example 3. Installation of was successful. If the packages you want to install are available from a remote system, then you can manually mount the directory that contains the packages, which are in package format, and install the packages on the local system.

The following example shows how to install a software package from a remote system. The pkgadd command installs the SUNWpl5u package. Installation of was successful If the automounter is running at your site, then you do not need to manually mount the remote package server.

Note that copying packages to a spool directory is not the same as installing the packages on a system. The packages are then available for use when you install the packages elsewhere with the pkgadd command. Remove any already spooled packages with the same names as the packages you are adding. Caution If the pkgid option is omitted, then the pkgrm command removes all available packages. Copy a software package to a spool directory. The following list provides explanations of each argument used with the pkgadd command.

The device-name can be the path to a device, a directory, or a spool directory. From the Library of Daniel Johnson 55 3. You must specify a spooldir. If omitted, the pkgadd command copies all available packages to the spool directory. Verify that the package has been copied successfully to the spool directory. Otherwise, the pkginfo command returns the system prompt. The following example shows the commands for this scenario. Packages If the automounter is running at your site, then you do not have to manually mount the remote package server.

Caution Do not use the rm command to remove software packages. Doing so will result in inaccuracies in the database that keeps track of all installed packages on the system. Remove an installed package. From the Library of Daniel Johnson 57 3. Caution If the pkgid option is omitted, the pkgrm command removes all available packages.

This example shows how to remove a package. Removing pathnames in class Processing package information. This example shows how to remove a spooled package. For convenience, you can copy frequently installed packages to a spool directory. Patches This chapter describes patches, provides best practices, and includes step-by-step procedures for applying patches. The following sections describe patches and provide step-by-step procedures for applying patches.

Also, a best practices section provides planning information for proactive and reactive patching. A patch consists of the following: For more detailed information, see Section 4. Over time, patches have evolved and now have many other uses. Some features require the installation of new packages, but any change to existing code is always delivered in a patch. Because new functionality such as new features in ZFS and GRUB is delivered entirely by patches, the patches enable businesses to take advantage of the new functionality without having to upgrade to a newer release of the Solaris OS.

Therefore, Sun ships some new functionality in standard patches. From the Library of Daniel Johnson 61 4. A patch ID is an alphanumeric string that consists of a patch base code and a number that represents the patch revision number joined with a hyphen.

Later revisions contain all of the functionality delivered in previous revisions. These strategies are only guidelines because every organization is different in both environment and business objectives.

This section also provides useful information and tips that are appropriate for a given strategy, the tools most appropriate for each strategy, and where to locate the patches or patch clusters to apply.

Your strategy should be reviewed periodically because the environment and business objectives change over time, because new tools and practices evolve, and because operating systems evolve. The four basic strategies outlined in this section are the following: Patches Note Before adding any patches, make sure you apply the latest revision of the patch utilities. The latest patch for the patch utilities must be applied to the live system in all cases. This chapter assumes that the latest patch for the patch utilities has been applied before any other patching is done.

The issue for proactive patching is identifying important patches and applying those patches in a safe and reliable manner. For proactive patching, the system is already functioning normally. Because any change implies risk and risk implies downtime, why patch a system that is functioning normally?

Although a system is functioning normally, an underlying issue could cause a problem. Underlying issues could be the following: Most security issues are latent issues that exist but are not yet causing security breaches. These issues require proactive action to prevent security breaches. Use proactive patching as the strategy of choice, where applicable. Proactive patching is recommended for the following reasons: The patchadd command can be used in situations where Solaris Live Upgrade is not appropriate.

From the Library of Daniel Johnson 63 4. For the registration procedure, see Section 4. Sun also has a range of higher-level patch automation tools. See Section 4. To proactively apply patches, use Solaris Live Upgrade. Solaris Live Upgrade consists of a set of tools that enable you to create an alternate boot environment that is a copy of the current boot environment.

You can then patch the newly created boot environment while the system is running. After the copy is patched, the new boot environment can be booted. These disk slices might be on the same disk or distributed across multiple disks. The active boot environment is the one that is currently booted. Only one active boot environment can be booted.

An inactive boot environment is not currently booted, but can be in a state of waiting for activation on the next reboot. Patching is not done on the currently running boot environment so that the system can continue to be in production until the timing is suitable to boot to the newly patched boot environment.

The patches do not need to be removed by using the patchrm command. In this example, you use the luupgrade command with the -t and -O options.

Example 4. Table 4. Also, if you are using Solaris Volume Manager for mirroring, then you might need to use the patchadd command. You need extra resources to set up a Solaris Volume Manager inactive boot environment. Veritas Storage Foundation root disk If you are using Veritas Storage Foundation to encapsulate the root disk, then you can use Solaris Live Upgrade to create a new boot environment.

From the Library of Daniel Johnson 65 4. If additional patches are to be applied to a Solaris 10 system by using the patchadd command, then the -a and -M options can be useful for identifying any missing requirements and identifying a valid installation order for the patches. While this method of applying patches has the major disadvantage of requiring you to patch the live system, which increases both downtime and risk, you can reduce the risk by using the -a option to inspect the patches before applying them against the actual system.

Note the following limitations to the patchadd -M option: In the following example, the -a option instructs the -M option to perform a dry run, so that no software is installed and no changes are made to the system. The output from the command is verbose but consists of an ordered list of patches that can be installed.

Also, this option outputs headings for the installable patches, which are called Approved patches. The patchadd command can be used in situations where Solaris Live Upgrade is not applicable. The Solaris Zones partitioning technology is used to virtualize operating system services and provide an isolated and secure environment for running applications. A non-global zone is a virtualized operating system environment created within a single instance of the Solaris OS.

When you create a non-global zone, you produce an application execution environment in which processes are isolated from the rest of the system. This isolation prevents processes that are running in one non-global zone from monitoring or affecting processes that are running in other non-global zones.

Even a process running with superuser privileges cannot view or affect activity in other zones. A non-global zone also provides an abstract layer that separates applications from the physical attributes of the system on which they are deployed. Examples of these attributes include physical device paths. For more information about non-global zones, see System Administration Guide: Note the following limitations for Solaris Live Upgrade: From the Library of Daniel Johnson 67 4.

Due to current issues with the patchadd -M option, this option can lead to unrecoverable errors. Apply the list of required patches. If these patches are not installed, then Solaris Live Upgrade fails. Minimum Patch Requirements.

The Solaris 10 Live Upgrade Patch Bundle provides a quick way to install all the required patches to use Solaris Live Upgrade on systems that have non-global zones installed.

The list of required patches for a system with non-global zones is quite large. The patches must be applied to the live running environment.

Patches patches required and use the patchadd command with the -a and -M options to identify any missing requirements. The -a option performs a dry run and no patches are installed. Pay attention to the patchadd -a and -M output. In particular, ensure that all non-global zones have passed the dependency tests.

The -a option can help identify the following issues with non-global zones: Apply patches individually by using the patchadd command. To facilitate applying multiple patches, you can use patchadd -a -M patch-dir to produce an ordered list of patches that can be installed individually.

Due to current issues with patchadd -M option, do not run -M patch-dir without the -a option. The -M option can lead to unrecoverable errors. These patches could be the latest Recommended Patch Cluster or one or more patches that seem to be appropriate. The patches might have changed the system in such a way as to obscure the problem for now and the problem could recur later. From the Library of Daniel Johnson 69 4.

When you are in a reactive patching situation, you must try to minimize risk change at all costs. In proactive patching, you can and should have tested the change you are applying.

Identifying the root cause involves a lot more risk. Furthermore, the changes that you applied might have negative consequences elsewhere on the system, which could lead to more reactive patching. Therefore, if you experience a problem that is affecting the system, then you should spend time investigating the root cause of the problem. To begin, you should do some analysis. Some tools that are useful in starting this analysis might include the following: These logs provide a good foundation to start an analysis of the system.

Patches No standard tool for analyzing a problem can be recommended because each problem involves different choices. Also, a proper recording system that records changes to the system should be considered. Solaris Live Upgrade is covered in more detail in Section 4.

The -a option performs a dry run and does not modify the system. Prior to actually installing the patch or patches, inspect the output from the dry run for issues. These options perform a dry run and produce an ordered list of patches that can be installed. After determining that no issues exist, the patches should be installed individually by using the patchadd command. Or, you can use the patchadd command. Never use the -M option to the patchadd command with non-global zones.

The -t option uses the patchadd -M option in the underlying software.

There are problems with the -M option. In addition to using the core Solaris Live Upgrade and patch utilities to patch a system, Sun also has a range of higher-level patch automation tools.

For more information, see Section 4. For security patching, you are required to be proactive, but a sense of urgency prevails. From the Library of Daniel Johnson 71 4. When you register for Sun alerts, you also receive Security Alerts. In addition, a security Web site contains more information about security and you can report issues there. Log in to the SunSolve Web site at http: Accept the license agreement. Click Subscribe to Sun Alerts.

Choose the newsletters and reports that you want to receive. This report is updated weekly.

If possible, use Solaris Live Upgrade. If Solaris Live Upgrade is not appropriate, then use the patchadd command. Patching during installation ensures that, when the system boots, the system has the latest patches installed. Patching avoids any known issues that are outstanding. In addition, you can create a baseline for all installations. Patching during installation requires that you use the JumpStart installation program.

Patches installation is completely hands off. Solaris 10 Installation Guide: Custom JumpStart and Advanced Installations is available at http: From the Library of Daniel Johnson 73 4.

All packages already on the system are automatically upgraded. The following patch keyword example applies an individual patch. The patch keyword installs the single patch from the network where the Recommended Patch Cluster is located. The retry n keyword is an optional keyword. The n refers to the maximum number of times the installation process attempts to mount the directory.

Patches Individual patches can be downloaded from the Patches and Updates page on the Web site. They do not contain other non-Solaris OS patches that address security, data corruption, or system availability issues. The following support contracts entitle customers to access all patches plus a wide range of additional support services: Solaris Subscriptions — Support contracts for your entire system: Download the patch.

From the Library of Daniel Johnson 75 4. Read the Special Install Instructions for all patches prior to installing them.

Special Install Instructions can be updated after the patch has been released to the SunSolve Web site. If you are using Solaris Live Upgrade from another release, then you might need slightly different procedures.

Solaris Live Upgrade and Upgrade Planning available at http: This guide is available for each Solaris 10 release. Creating a new boot environment by using the lucreate command. Applying patches to the new boot environment by using the luupgrade command. Activating the new boot environment by using the luactivate command. Falling back to the original boot environment if needed by using the luactivate command.

Removing an inactive boot environment by using the ludelete command. You can remove a boot environment after the running boot environment is stable. Patches Figure 4. Therefore, a prerequisite is to have enough disk space for both the original and new boot environments.

You need either an extra disk or one disk large enough to contain both boot environments. Supported releases Sun supports and tests an upgrade from any release to a subsequent release that is no more than two releases ahead. For example, if you are running the Solaris 7 release, then you can upgrade to any Solaris 8 or Solaris 9 release, but not to a Solaris 10 release.

If you are running the Solaris 7 release, then you would need to upgrade to the Solaris 8 release before using Solaris Live Upgrade. Any Solaris release includes all the releases within that release.

You need to upgrade to the latest version of the Solaris Live Upgrade software prior to patching the system, regardless of the version of the Solaris OS running on the system.

Dependency order of patches The patchadd command in the Solaris 10 release correctly orders patches for you, but the Solaris 9 and earlier releases require patches to be in dependency order.

When using the luupgrade command to apply patches, apply the patches in dependency order, regardless of the Solaris release you are using. Sun uses dependency order as part of the standard testing of the luupgrade command and you can be assured that this order was tested. Patch log evaluation Patching can generate a number of errors.

You should examine the patch log to determine whether any patch failures impact you. Sometimes a log indicates that a patch has failed to install, but this is not a problem.

The installation log should be checked to ensure all messages are as expected. Patches Table 4. All Sun patches conform to the requirement that preinstallation and postinstallation scripts never modify the running system when the target is an inactive boot environment. However, Sun cannot guarantee that all third-party patches are equally well behaved. When you intend to patch an inactive boot environment, you might need to verify that a third-party patch does not contain a script that attempts to modify the currently running environment.

When you activate a boot environment by using the luactivate command, the boot environment must meet the conditions described in the Table 4. Use the lustatus command to display information about each boot environment. If BE-name is omitted, lustatus displays the status of all boot environments in the system.

If the boot environment is not the current boot environment, then you cannot mount the partitions of that boot environment by using the luumount or mount commands.

Solaris 10 System Administration Essentials

See the lumount 1M or mount 1M man page at http: The boot environment that you want to activate cannot be involved in a comparison operation. To compare boot environments, you use the lucompare command. The lucompare command generates a comparison of boot environments that includes the contents of non-global zones. By default, all boot environments share the same swap devices. By not specifying swap with the lucreate command with the -m option, your current and new boot environment share the same swap slices.

From the Library of Daniel Johnson 79 4. Activating the boot environment If you have an x86 based system, you can activate a boot environment by using the GRUB menu instead of the luactivate command. Note the following exceptions: These older boot environments do not display in the GRUB menu. You can thereafter switch to this boot environment by selecting the appropriate entry in the GRUB menu.

Ensure that you install all the patches that are relevant to your system before proceeding. From the SunSolve Web site, follow the instructions in info doc to remove and add Solaris Live Upgrade packages. The Web site is located at http: The following summarizes the info doc steps for removing and adding the packages: Remove existing Solaris Live Upgrade packages. Patches Upgrade. If you do not remove the existing packages and install the new packages on your system before using Solaris Live Upgrade, upgrading to the target release fails.

Install the new Solaris Live Upgrade packages. You can install the packages by using the liveupgrade20 command that is on the installation DVD or CD. The liveupgrade20 command requires Java software. If your system does not have Java software installed, then you need to use the pkgadd command to install the packages. See the SunSolve info doc for more information.

Change directories: If you are using the Solaris Software-2 CD, run the installer without changing the path: Verify that the packages have been installed successfully. Obtain the list of patches. Change to the patch directory. Install the patches. Separate multiple patch names with a space. Reboot the system if necessary. Certain patches require a reboot to be effective. Otherwise, Solaris Live Upgrade fails. Create the new boot environment. Patches -n BE-name The name of the boot environment to be created.

BE-name must be unique on the system. In the following example, a new boot environment named solaris2 is created. The time to complete varies depending on the system. Discovering physical storage devices. Discovering logical storage devices. Cross referencing storage devices with boot environment configurations.

Most Popular SOLARIS Study materials

Determining types of file systems supported. Validating file system requests. The device name expands to device path. Preparing logical storage devices. Preparing physical storage devices. Configuring physical storage devices.

Configuring logical storage devices. Analyzing system configuration. No name for current boot environment. Current boot environment is named. Creating initial configuration for primary boot environment.

Tutorial Downloads .com

The device is not a root device for any boot environment. PBE configuration successful: Determining which file systems should be in the new boot environment. Updating boot environment description database on all BEs. Updating system configuration files. Creating configuration for boot environment. Source boot environment is. Creating boot environment.

Creating file systems on boot environment.

Creating file system for on. Mounting file systems for boot environment. Calculating required sizes of file systems for boot environment. Populating file systems on boot environment. Checking selection integrity. Integrity check OK. Populating contents of mount point. Creating shared file system mount points.

Creating compare databases for boot environment. Creating compare database for file system. Updating compare databases on boot environment. Making boot environment bootable. Population of boot environment successful. Creation of boot environment successful. From the Library of Daniel Johnson 83 4.

Optional Verify that the boot environment is bootable. The lustatus command reports if the boot environment creation is complete and if the boot environment is bootable. Apply patches to the boot environment. The patches you apply can come from several sources.

The following example provides steps for installing patches from the SunSolve database. However, the procedure can be used for any patch or patch bundle, such as patches from custom patch bundles, Sun Update Connection enterprise patches, the Enterprise Installation Services CD, or security patches. From the SunSolve Web site, obtain the list of patches at http: Download the patches to that directory.

Apply the patches. The luupgrade command syntax follows: In the following examples, the patches are applied to the solaris2 boot environment. The patches can be stored on a local disk or on a server.

Patches This example shows the installation of patches stored in a directory on the local disk: Sun uses dependency order as part of the standard testing of the luupgrade command, and you can be assured that this order was tested. Activate the new boot environment. See the following documents for more information about activating a boot environment: Subsequent activations can be made by selecting the boot environment from the GRUB menu.

Solaris Live Upgrade and Upgrade Planning. For more information, see Table 4.

From the Library of Daniel Johnson 85 4. Reboot the system. If you use the reboot, halt, or uadmin command, then the system does not switch boot environments. The most recently active boot environment is booted again. The boot environments have switched and the new boot environment is now the active boot environment.

Optional Fall back to a different boot environment. Activate the solaris1 boot environment. The following procedures work if the boot environment is bootable. If the new boot environment is not viable or you want to switch to another boot environment, see Solaris 10 Installation Guide: See Table 4. Sun xVM Ops Center provides patch management to enterprise customers for systems running the Solaris 8, 9, and 10 releases or the Linux operating systems.

Sun xVM Ops Center provides the following tools for managing your systems: Improve security and availability—Make these improvements by keeping your Solaris and Linux systems updated with the latest patches.

Sun develops and tests all dependencies and then publishes updated dependency rules to its clients. From the Library of Daniel Johnson 87 4. A popular third-party tool developed by Martin Paul. PCA generates lists of installed and missing patches for Solaris systems and optionally downloads patches. PCA resolves dependencies between patches and installs them in the correct order. The tool is a good solution for customers interested in an easy-to-use patch automation tool.

To try PCA, run these commands on any Solaris system: This command enables you to analyze and update the Solaris OS with current patches.

You can check which patches or updates are available or you can easily select the patches to install. To display the GUI, run update manager. For both of these tools, support from Sun is the following: For customers without a valid support contract, only security and driver patches are available.

These additional patches include products or patches to address issues that do not meet the criteria for inclusion in the Recommended Patch Cluster. Because many system installations worldwide use the EIS methodology, any inherent problems quickly appear and can be addressed. This set can also be used to patch existing systems to the same patch level. This patch is important because of the scope of change affecting a system. A Kernel patch changes the Solaris kernel and related core Solaris functionality.

A reboot is required to activate the new kernel version. From the Library of Daniel Johnson 89 4. A limited number of patches are designated as a deferred-activation patch. Patches not designated as deferred-activation patches continue to install as before. For example, previously released patches, such as kernel patches SPARC and x86 , do not use the deferred-activation patching utilities to install. Previously, complex patch scripting was required for these kernel patches.

The scripting was required to avoid issues during the patch installation process on an active partition because of inconsistencies between the objects the patch delivers and the running system active partition. When a patch is applied to the running system, the lofs preserves stability during the patching process.

These large kernel patches have always required a reboot, but now the required reboot activates the changes made by the lofs. Information about the issues addressed by Security T-patches and possible workarounds is available through the Free Security Sun Alert data collection. Rejuvenated patch Patches that become overly large or complex sometimes follow a process of rejuvenation. The rejuvenation process provides patches that incrementally install complex new functionality in relative safety.

When a patch becomes a rejuvenated patch, no more revisions of the patch are created. Instead, further changes to the rejuvenated patch are delivered in a series of new patch IDs. These new patches depend upon and require the rejuvenated patch.

If one of the new patches becomes complex over time, then that patch could become a rejuvenated patch. For example, the Kernel patch is rejuvenated when needed. The advantage of this process is that although a customer must install the complex patch once, future patches are much simpler to install. Point patch A custom patch. Point patches are only appropriate for the customers for whom the patches have been delivered. These patches are created on a branch of the Solaris source code base and are not folded back into the main source base.

Access to a point patch is restricted and should only be installed after consultation with Sun support personnel. From the Library of Daniel Johnson 91 4. R-patches are used in circumstances similar to point patches.

Like a point patch, an R-patch is only appropriate for the customer for whom the patches have been delivered.

An IDR is provided in a patch format similar to an R-patch. This patch is a type of IDR. Information about the issues addressed by an ISR and possible workarounds is available through the Free Security Sun Alert data collection. Nonstandard patch A patch that cannot be installed by using the patchadd command. A nonstandard patch is not delivered in package format. He works on design and development of system-level diagnostics using C on Solaris.

Puneet lives in Bangalore with his parents, Mr. Surendra Kumar Jain and Ms. Memo Jain. Narendra Kumar. He has over ten years of experience and has worked in varied areas such as networking, telecom, embedded systems, and Operating Systems.

He has worked for Sun for the last four years. Currently he is responsible for sustaining the sysidtools part of the Solaris Install. He is based in Bangalore and lives with his wife, Rukmini, and daughters, Harshitha and Vijetha. James has a broad range of expertise in UNIX, Java, compilers, networking, security, systems administration, and applications architecture. At present, James is a kernel engineer helping IHVs write device drivers. In his spare time, he likes to blog about how to build cheap Solaris x86 boxes.

He has ten years of experience in Solaris—covering both test and product development—primarily focused on networking components in the Solaris Operating System.

She has over seventeen years of experience working with and writing about the Solaris operating system. Her work is primarily focused on helping system administrators and developers to effectively use Sun technologies to support their endeavors. Vidya Sakar has about ten years of technical and management experience in Solaris Sustaining and Engineering.

He joined the Solaris Engineering group in late , where he currently works in the networking team, and moved to the San Francisco Bay Area in early Lynne Thompson is a Senior Technical Writer who has written about the Solaris operating system for more than fourteen years.

To enhance the understanding of Solaris for system administrators and developers, she has written extensively about Solaris installation, upgrading, and patching, as well as many Solaris features related to installing, such as ZFS, booting, Solaris Zones, and RAID-1 volumes.

Lynne is a contributor to OpenSolaris. She has a Master of Arts in English Writing. From the Library of Daniel Johnson 1 Installing the Solaris 10 Operating System The chapter explores the key methods for installing and updating the Solaris operating system. It takes the reader from simple installation on a single system through the options for installing and upgrading systems in a networked environment where multiple machines can be managed automatically.

The Solaris OS can be installed easily on a single system using a CD or DVD, it can be installed over a network, update installations can be performed while the system is running without interruption, and installation on multiple machines can be performed hands-free with JumpStart. You can even clone a system for installation on other machines using the Solaris Flash archive feature.

Once you have downloaded that image, you can burn an ISO format disk image and then install that image on one or more systems. This method provides a simple GUI installation process, though you can always use the text-based installation interface. It is not necessary to create a DVD, though.

You can install the Solaris OS directly from the image you downloaded. When you get to installing multiple machines, you will want something more versatile than a DVD, which must be carried to each machine.

A network-based installation is obviously a useful alternative. You can use all of the Solaris installation methods to install a system from the network.

You can point each machine at the installation image on the network and install almost as if you had inserted a DVD. However, by installing systems from the network with the Solaris Flash installation feature or with a custom JumpStart installation, you can centralize and automate the installation process in a larger environment.

If your system is not running the Solaris OS, then you must perform an initial installation. If the system is already running the Solaris OS, then you can choose to perform an initial installation.

You can use any of the Solaris installation methods to perform an initial installation. Solaris Live Upgrade creates a copy of the current system. This copy can be upgraded with a standard upgrade. The upgraded Solaris OS can then be switched to become the current system by a simple reboot. If a failure occurs, then you can switch back to the original Solaris OS with a reboot. Solaris Live Upgrade enables you to keep your system running while you upgrade and enables you to switch back and forth between Solaris OS releases.

When you start off small with only a single system to install, the GUI and console mode text installers are the simplest ways to install a single instance of the Solaris OS. The minimum memory requirement for installing Solaris is MB.

The recommended size is MB. If the system has less than MB, then the text installer will be used automatically. Table 1. If you install by using the text boot option and the system has enough memory, you are installing in a windowing environment. If you are installing remotely through a tip line or using the nowin boot option, you are limited to the console-based installation.

Solaris has support for Kerberos authentication and credential support; if you wish to set it up, then you can do that at install as well.

One of the last network services to set up is the naming service to be used for mapping hostnames to Internet Protocol IP addresses. Packaging and package metaclusters also known as Software Groups are a key idea in a Solaris installation. In this day of big disks, it is recommended that you install the Entire Distribution plus OEM support metacluster.See Table 3.

RAID-Z avoids this problem by using dynamic stripe sizes, which means that all block writes are atomic operations. You must enter at least one IP address up to three addresses are allowed and search domains. Note that the read-only options cannot be changed. The Solaris Zones partitioning technology is used to virtualize operating system services and provide an isolated and secure environment for running applications. When you activate a boot environment by using the luactivate command, the boot environment must meet the conditions described in the Table 4.

If the boot environment is not the current boot environment, then you cannot mount the partitions of that boot environment by using the luumount or mount commands.