Interim Relief/Diagnostics

1. Introduction

During the life of your Sun™ system, at some time it is possible that you may have an issue that requires investigation and resolution by Engineering. During the course of this, Engineering may decide to issue a custom software update for a number of reasons:

• More diagnostic information is needed to understand the issue.
• A temporary workaround to the issue is developed.
• A prospective fix for the issue is developed.

In the past, an engineer would have the service organization send you a set of new files, commonly called "binaries" (though they might actually be text files like scripts or configuration files). Along with these files, you were typically given instructions on how to install and uninstall them.

Based on customer feedback and our own experience, we realized that there were a number of issues with this process:

• The installation/uninstallation process was typically manual as opposed to scripted. This meant that you would be expected to copy or move the new binaries to their intended system locations. Doing this had a strong possibility for error, especially as the number of files grew.
• You were expected to save copies of all the files you replaced, because it was important to be able to restore them when you needed to uninstall the new binaries. Again, this had a strong possibility for error.
• Because the files were just copied to their intended location, there was almost no way to tell that a system had been modified in this way, unless you had your own change control process, or by running a full scan on the system to see what files were different from what was registered in the system installation database. If this situation was missed, valuable time could be lost investigating another issue that was caused by interactions with the binaries.
• Because binaries represent custom software, it would become more difficult over time to manage the possibility that they would have an incompatibility with other software. As binaries were installed on more systems or as time since they were installed grew, it would become harder to assure that all the prerequisites and prohibitions were precisely followed. Typically, such restrictions would only be part of the documentation sent with the binaries, meaning that they were not automatically enforced.
• When installing other patches or binaries on a system that already had binaries installed, there was no way to avoid silently overwriting them in whole, or worse, in part. This could lead to the original issue reoccurring, severe malfunctions (like being unable to boot the system), or other extremely hard-to-diagnose issues.

Because of the above, Sun has developed a new deliverable to handle the task of providing binaries to you, called the Interim Diagnostics or Relief, nicknamed "IDR". The key requirements for the IDR were:

• Be easy to install and uninstall
• Be traceable in the system software installation database
• Have a short and specific lifecycle
• Handle interdependencies between patches and other IDRs

2. Design

The design of the IDR was based on the same patch architecture that is used by the Solaris™ Operating Environment. By doing so, it uses the same well-known commands that you already use to administer your patches. Furthermore, it allows for IDRs to interoperate fully with patches, particularly the ability to perform dependency checks to force compliance with any restrictions that might be in place.

In addition, IDRs use a feature of the architecture called the "Restricted Patch", or "R-Patch". This is a key component to the dependency checking system. In order to keep other IDRs or patches from overwriting an installed IDR, this mechanism prevents a software package that already been modified by an IDR from being further modified by another IDR or patch, thus preventing the possibility that it might be overwritten.

3. Not a Patch

It is very important to mention that while IDRs use the patch architecture and administration utilities, there are extremely significant differences between an IDR and a patch:

• An IDR is custom software that has been developed specifically for your use.
• An IDR, being custom software, is not qualified for general use. It is intended solely for use by you on the systems that you have identified to your service engineer. It may not install or operate correctly on other system configurations. If you need to install the IDR on other systems in your environment, you need to qualify this with your service engineer first.
• An IDR may contain only diagnostics, and thus may not change the nature of the issue you are experiencing. In particular, some diagnostics are intended to make the issue worse or crash the application or system in order to collect key information that is needed to find the root cause of the issue. The support engineer that you are working with will describe its intent, as well as the README file included with the IDR.
• If the IDR provides relief from an issue, it may be only a workaround. This might include disabling or degrading a feature or capability until a more complete resolution is available. Again, your service engineer and the README will explain this.
• Relief in the form of a prospective fix is not final, and may evolve over time. There is also no commitment that the final resolution will result in an official patch.
• While every effort is made to assure the quality of the IDR, due to the fact that we are trying to provide relief to your issue in a timely manner, the IDR does not undergo the same level of testing as patches do. If are familiar with the current system of using binaries, the quality of the components contained in the IDR will be of similar quality.
• An IDR is intended for temporary use, even if it provides relief for your issue. You need to work with your service engineer to proceed to the next step of resolving your issue, whether that be a T-patch, patch, or workaround.

4. Details

4.1. Naming

An IDR is named similar to a patch, but with the prefix string "IDR" as in "IDR123456-01". This name will be displayed by using the "-p" option with either the showrev(1M) or patchadd(1M) utilities. For example, showrev -p might display:

Patch: IDR114629-01 Obsoletes: Requires: 111225-01, Incompatibles: 111225-02 Packages: SUNWcsu, SUNWxcu4

The revision number given to an IDR will be sequentially increasing, but unlike patches you cannot assume that each revision includes all the changes provided by a previous one. This provides the engineer with the most flexibility to provide changes to you, without needing to constantly change the ID. Because of this fact, you will be required to uninstall a revision of an IDR before you can install another.

4.2. Installation

Installation of an IDR uses the patchadd(1M) utility, and uninstallation uses patchrm(1M). Unlike patches, you cannot specify the -d option during installation to prevent backing up the existing files for eventual restoration.

The following paragraph is extremely important!

It is very important to emphasize that you must not circumvent the facilities used to allow for eventual uninstallation of the IDR. While an IDR prevents you from using the -d option as described previously, you must not use the -B option to place the backup data in a location that is volatile (e.g., /tmp) or remove the backup data after installing the IDR. This will prevent the IDR from being uninstalled, and you would therefore not be able to install any more IDRs or patches that affected the same software packages, due to its use of the R-patch mechanism as described previously.

It is also important to note that this R-patch mechanism could block the installation of seemingly unrelated IDRs or patches, since it is possible that the software had been delivered via a software package shared by both. If this occurs, contact your service engineer for advice on how to proceed.

IDRs will not automate the installation of changes into files that you might edit, such as configuration files. This is one case where the risk of automation is much greater than the risk of performing the change manually. The service engineer and the README will advise you on what manual steps might need to be taken.

4.3. End of Life (EOL)

The EOL of an IDR is defined to be:

• when a T-patch addressing the issue is made available
• when the service case associated with the issue is closed

• The IDR will no longer be distributed or updated.
• Issues with the IDR will require installation of the corresponding T-patch for further investigation

The reason for this is that the T-patch (or patch) is based on the official source base for the product in question. Therefore, it reflects the version of the product on which any further change will be based, and which would eventually be the version you would need to install. Therefore, by working from the latest version, the risk of introducing any defects is reduced..

Whenever the T-patch is made available, we encourage you to schedule your migration from the IDR to it as soon as possible. This helps assure the quality of the final official patch. Furthermore, by moving to the T-patch over the IDR, you remove the restrictions on installing other IDRs or patches due to the R-patch mechanism, thus making it easier to update your system as you see fit.

4.4. Support

To receive an IDR, you will need an open service call. If your issue is one that service and engineering determines requiring an IDR, it will be sent to you through your service engineer. While the method you obtain it may include downloading it from a Sun site, this would be a private download and it would not be publicly available.

It is important to reiterate that an IDR is a support tool, and not a patch.

Currently, not every product has the capability to produce IDRs, though this will be increased over time. Also, IDRs are also only available for the Solaris™ Operating Environment.