X-ray Your Applications and Get Ready for Oracle Solaris 11

November 2011

by Stefan Schneider

How to transition existing Oracle Solaris 10 applications to Oracle Solaris 11 using a standard process and tools from Oracle.

Why Test Your Applications?

The Oracle Solaris Binary Compatibility Guarantee warrants that applications developed for Oracle Solaris 10 will work on Oracle Solaris 11 as long as they rely on public and stable programming APIs.

The ability to execute a well-formed Oracle Solaris 10 application on Oracle Solaris 11 is, however, not sufficient to guarantee a high-quality user experience. Oracle Solaris 11 incorporates 6 years of technology evolution, which might require configuration changes for the following reasons:

• Application frameworks are shipping in newer versions, for example, GNOME.
• Some frameworks have been replaced with other frameworks. For example, lpd was replaced by cups.
• Private and unstable APIs from Oracle Solaris 10 might have been removed in Oracle Solaris 11. For example, applications that statically linked in Oracle Solaris 9 worked by chance in Oracle Solaris 10. They are unlikely to work in Oracle Solaris 11.
• Commands have a different location. For example, /usr/ucb/whoami is now located in /usr/bin/whoami.
• Deprecated, non-ISO-compliant locales have been removed.

None of these changes should affect well-implemented Oracle Solaris 10 applications. Applications that haven't adhered to the Oracle Solaris 10 coding and operation standards might, however, need some configuration changes.

Overview of the Transition Process

Oracle is facilitating the transition to Oracle Solaris 11 with a set of tools and an adoption guide that can be used to plan the transition to Oracle Solaris 11, as shown in Figure 1.

Figure 1. Overview of the Transition Process

To ensure the well-managed transition of an application to Oracle Solaris 11, you should start by consulting the Oracle Solaris 11 ISV Adoption Guide. This guide is a checklist of the common reasons why an Oracle Solaris 10 application that is not properly designed might have problems on Oracle Solaris 11. The guide lists all currently known border cases that might create problems on Oracle Solaris 11.

In addition, the Oracle Solaris 11 End of Features (EOF) Notices page lists the retired software frameworks and legacy hardware that will not be supported on Oracle Solaris 11. This page can be used as an additional checklist to identify potential problems that an Oracle Solaris 10 application might have on Oracle Solaris 11.

Oracle Solaris Preflight Applications Checker

Applications typically consist of many subcomponents and third-party components. You can assess the technical readiness of your applications using the resources mentioned in the previous section. However, assessing the readiness of third-party runtime components might prove to be more difficult.

The Oracle Solaris Preflight Applications Checker enables you to determine the Oracle Solaris 11 readiness of a working Oracle Solaris 10 application by generating HTML reports that can be used as qualified "to do" lists. Having such lists lowers costs, because valuable QA time and root-cause analysis time can be saved by addressing the reported issues instead of relying on initial QA runs to understand the underlying problems.

The Oracle Solaris Preflight Applications Checker comes with three separate components, which are shown in Figure 2:

• Binary Analyzer, which scans application binaries
• Source Code Analyzer, which can scan application sources and scripts
• RunTime Analyzer, which can monitor a running application for any calls or file-access operations that might create problems in Oracle Solaris 11

Figure 2. Components of the Oracle Solaris Preflight Applications Checker

Binary Analyzer

All interfaces in Oracle Solaris are versioned to ensure upward compatibility, and they are labeled as public or private. Public interfaces are those that are intended for use by applications or middleware running on top of Oracle Solaris, while private interfaces are those intended to be used only by other Oracle Solaris interfaces.

Although the most problematic cases of binary incompatibility result from the use of private symbols, other issues can arise from unstable practices. Unstable practices include static linking of an Oracle Solaris shared object to the application at compilation time, since Oracle Solaris interfaces might change over time. As interfaces evolve, the interactions between a shared object that is statically linked and other Oracle Solaris libraries are at risk for binary incompatibility as well. Therefore, in the compatibility check phase, when static linking is noted in the profiles of the objects, the compatibility checking tool reports this condition as dangerous. In addition, heuristics are used for checking partial static linking by looking at particular symbols.

During the initial phase of a binary scan, all bindings and associated symbols that are used by the application are extracted. The compatibility checking tool uses the user-supplied application environment variable LD_LIBRARY_PATH to determine the libraries being used by the application during runtime. This information is then parsed to determine the path names of the objects being examined and the symbol bindings into Oracle Solaris shared libraries. Another utility used during the profiling phase is the elfdump command, which dumps the dynamic linking information that the objects depend on.

Source Code Analyzer

The static source code analysis module can check for compatibility issues in C/C++ source code, K shell, and other shell scripts. This module mainly checks for the use of removed, renamed, modified, or deprecated Oracle Solaris library functions and shell commands.

RunTime Analyzer

The runtime analysis module can run in an existing Oracle Solaris 10 test environment and report potential compatibility issues. This module of the tool uses DTrace to look into process details, and it might invoke other system tools available on Oracle Solaris 10 (as needed).

The tool can be configured to run with different scopes varying from system-wide checks to specific processes only.

The RunTime Analyzer tool can report known issues in the following cases:

• Invocation of deprecated (EOLed) commands
• Invocation of renamed or relocated commands
• Invocation of commands that have deprecated options
• Opening, reading, or writing deprecated, renamed, or relocated files or devices
• Use of outdated and removed versions of utilities or packages, for example, a hard-coded path for using postgreSQL
• Use of removed or replaced device driver interfaces
• Use or invocation of deprecated or "end-of-lifed" (EOLed) functions, APIs, or symbols
• Use or invocation of private interfaces
• Dynamic loading of deprecated or renamed libraries

Summary

Most applications will not cause any issues to be reported by the scanning tools, and they most likely will not face the issues discussed in the "Oracle Solaris 11 ISV Adoption Guide" or the Oracle Solaris 11 EOF page. Therefore, most applications will likely work out of the box on Oracle Solaris 11. However, some applications will report problems because they use outdated and deprecated frameworks and APIs. These applications will need fixes.

The Oracle Oracle Solaris 11 Preflight Applications Checker and the "Oracle Solaris 11 ISV Adoption Guide" enable you to make decisions about the mitigation of reported problems. For example, you might decide to use the Oracle p2v (physical to virtual) or v2v (virtual to virtual) tools to migrate an application from Oracle Solaris 10 into an Oracle Solaris 10 zone, which operates in Oracle Solaris 10 mode on Oracle Solaris 11.

For More Information

Here are some additional resources:

• Download Oracle Solaris 11
• Access Oracle Solaris 11 product documentation
• Access all Oracle Solaris 11 how-to guides
• Learn more with Oracle Solaris 11 training and support