This chapter includes information about the major changes in the Sun Connection 1.1 software from the previous Sun Update Connection – Enterprise releases (1.0.0 – 1.0.3). For information about new functionality and fixed issues, go to Chapter 3, Issues Fixed and New Functionality.
The following major changes occurred in Sun Connection:
The following have been added to the list of platforms that Sun Connection 1.1 supports:
Solaris 10 (x86 and SPARC) support for the SDS, console, CLI , and API
Fujitsu SPARC (Solaris 8 and 10) – Agents only
IBM Mainframe, including Novell SLES 8.0 (S/390), Novell SLES 9.0 (S/390X), Red Hat AS 3.0 (S/390), and Red Hat AS 4.0 (S/390X) – SDS and agent (the console is not supported at this time)
Limited support is available for Red Hat Linux versions 7.2 through 9.0. Red Hat is no longer supporting these versions and has blocked all component downloads for these releases.
The PowerPC architecture and associated channels are no longer supported.
On Solaris, the installation locations for all Sun Connection components have changed. Solaris components now install under the /opt/SUNWuce directory.
Under Linux, the CLI and console can be started from convenience links in the /usr/bin directory. These links are not available in Solaris. To run these applications in Solaris without using the entire pathname, you must include /opt/SUNWuce/cli/bin and /opt/SUNWuce/console/bin in your path.
If you have Sun Connection agent software installed on a system that is running the Solaris OS for x86 or SPARC® platforms, a Solaris utility patch might be required before you can successfully deploy patches and packages.
Install the latest version of the appropriate OS-specific patches:
Solaris 10 technology – Patches 119254, 122660–07 or higher, and 124630
Solaris 10 x86 Platform – Patches 119255, 122661–07 or higher, and 124631
Solaris 9 SPARC technology – Patch 112951
Solaris 8 SPARC technology – Patch 108987, and 112438 (SPARC technology) or patch ID 112439 (x86 platform)
If you do not already have these patches installed, you should apply the required patches shortly after you install Sun Connection.
Sun Connection 1.1 supports Solaris 10 zones on both the x86 and SPARC platforms. Solaris 10 zones running Linux are not supported in this release.
All of the Sun Connection components for Solaris can be installed in a Solaris zone (either sparse or full, global or non-global). For more information about installing, see Installing the SDS and Agent in Zones.
The agent supports patching of Solaris zones subject to the information provided in Patching in Zones and any other zone patching restrictions. For more information about Solaris 10 zones and patching to zones, go to http://www.sun.com/bigadmin/content/zones/ or see the Solaris 10 System Administration Guide on docs.sun.com.
Beginning with Sun Connection 1.1, if you are using a Solaris OS, the CLI commands are executed from the /opt/SUNWuce/cli/bin/ directory. If you are using a Linux OS, the commands are still executed from the /usr/bin directory.
For Solaris, the uce_cli.sh script is located in the /opt/SUNWuce/cli/bin directory.
For Linux, the uce_cli.sh script is located in the /usr/bin directory.
The directory change impacts the CLI procedures that are used for Solaris software. For details, see Adding Solaris Software With a Script.
The Solaris 10 SDS components and agent are now managed by SMF. Solaris 8 and 9 agents still use the /etc/rc* scripts.
The following list details the Sun Connection components and their corresponding SMF service names:
Agent – application/SUNWuce/agent
SDS engine – application/SUNWuce/engine
SDS database – application/SUNWuce/db
SDS server – application/SUNWuce/server
SDS proxy – application/SUNWuce/proxy-server
To make it easier to determine the events leading up to an error condition, the debug and error logs have been combined into one file - generally called error.log. This file is located in the component's logs directory (for example: the agent log is located in /opt/SUNWuce/agent/logs/error.log).
In addition, the format of the log file itself has been standardized. Entries in the log file have the following format:
pid:YYYY-MM-dd_hh:mm:ss level [ module-or-logger-name: source-file: #line-no ] error-code message
Rrepresent the date and time at which the message was sent to the logger for reporting.
The symbolic logging level, in decreasing level of severity. The levels are SEVERE, ERROR, WARNING, INFO, DEBUG, FINE, and DETAILED.
The numeric code of the error message that is being reported. When debug information is being reported, the error-code might be zero.
The name of the file from which the logger was called. When legacy code in the application calls the logging mechanism, the source-file name might be the string source_unavailable.
The line number in the source file at which the logger was called to report the message. If the source-file name is not available, this might be zero.
You might see messages with the level set to ERROR, but which actually contain debugging information or messages which are not errors, such as:
10918:2007-01-16_09:49:18 ERROR [ default_logger: source_unavailable: #0 ] 118100736 Info: Enabling Authentication mechanism (User=<>, Pass<**>)
This is usually the result of legacy code in the applications. In the example above, other indications that the legacy code called the logging mechanism are the source-file name and line number. Instead of recording the name of the source file in which the logger was called, you see source_unavailable, and the line number is zero.