This chapter includes information about issues fixed and new features found in Sun Connection release 1.1 and 1.1.1 software.
This chapter covers the following issues:
The following issues are fixed in the 1.1.1 release:
6551496 – "Continue on failure" feature for UCE 1.1.1. See New Job Preference for more information.
6552012 – Wrong behavior while Installing non relevant patches on the local zones.
6525334 – Create a Policy in GUI to say "Yes" to all Notifications. See New Notification Policy for more information.
6536150 – Solaris Rollback Failures. See Enhanced Patch Removal for more information.
Password appears when using the user name and password arguments in the CLI.
Removing a patch often removes implicitly installed older revisions. It will remove patches back to the last explicitly installed patch. Explicitly installed patches are patches that you physically install. Implicitly installed patches are changes that are included in an earlier patch. For example, if you installed patch –8 and then patch –10 , the latest patch ( –10 ) includes the changes from earlier patches; therefore, patch –10 implicitly obsoletes patch –9.
There is a special case, where the patch to be removed is also obsoleted by another patch family. In this case, the removal of this implicitly installed patch will remove the other explicitly installed patch family. Beginning with Sun Connection 1.1.1, you can limit the removal of the implicitly installed patches only to ones that are not obsoleted by other patch families.
The following is an example of the change in behavior:
Sun Connection version 1.1 and earlier will remove patch -9 and all the other family (obsolete it).
Sun Connection 1.1.1 will not recommend the removal of patch -9. However, if you remove patch -10, and patch -9 was implicitly installed, then patch -9 is uninstalled.
The following new functionality is available in the 1.1.1 release:
Beginning with version 1.1.1, Sun Connection will detect your system's firmware level. The components are visible in the Hardware category.
When you start a Bug Fixes job, Sun Connection will perform a firmware level check and it will recommend the installation of required firmware patches.
The firmware recommendation depends on the knowledge base. The firmware knowledge base is expected by June 15 2007.
Beginning with version 1.1.1, the notification feature is available as a policy. Before 1.1.1 you had to answer each 'Notifications' question interactively, and then save the policy for later reuse. Now you can set up a notification policy.
To use the new notification policy for a job, perform the following steps:
In the Policy Editor, select the Notifications node.
Select a predefined answer (Ask Me, Yes, No) for the Apply Fix action.
Click OK to save the policy change.
If a task requires mandatory notifications and you set the Apply Fix parameter to No, the job will fail.
Sun Connection jobs contain one or more tasks. Each task is made up of actions, such as installing (or uninstalling) a patch, package, configuration file, or script.
In versions before the 1.1.1 release, when an action (such as a patch or package install or uninstall) within a task failed, the entire task failed. Beginning with version 1.1.1, Sun Connection will continue to apply actions within a task, even when one or more actions within a task fails. If, for example, a patchadd fails within a task, the task and job will continue. This new default behavior applies to Solaris OS install or uninstall failures for either patches or packages. The behavior is configurable.
Some Solaris patches and packages should only be installed on the global zone. If you attempt to install Solaris global zone patches or packages on a local zone, the task will be marked as failed. In Sun Connection 1.1, these were logged as successful tasks and the job continued to run. In Sun Connection 1.1.1, the tasks are correctly identified as failures, but you now have the option to continue the job.
To disable the behavior and fail the job when a task fails, perform the following steps:
From the Tools menu, select Preferences, then Host.
Deselect the check box to disable the default behavior.
The following is the default behavior:
Patch policy – Continue task if patch install fails
Packages – Continue task if package install fails
When an agent is running in single user mode, a simple text progress is printed to the sytem's console.
The following command line options are no longer available:
User name, -u, option
Password, -p, option
You can still opt to type your user name and password interactively. If you want to call the CLI without interactive prompts, for example when you use a script, use the new Store Password, -sp, option.
When you use the -sp option, you are prompted for your user name and password. Sun Connection will encrypt the information and save it in your personal .uce.rc file. Once your information is saved, Sun Connection will automatically retrieve the information from your .uce.rc resource file when you run commands from the CLI.
The following issues are fixed in the 1.1 release:
6478116 – The Installation of engine fails on the mainframe sles 8 S390
6476975 – Agent uses too much memory when Idle
6485365 – Problem with the double upgrade : from 1.0 to 1.0.1 then to 1.0.2
6487543 – Wrong value in the osiris_obsolete_incident_table
6484752 – Agent core dumps in the case when there is no uncompress utility on the server and the download fail
6488794 – Seeker failures should be reported and stop the agent
6485389 – Postgresql optimization
6489367 – Problem uploading the package of SUNWucea.i386
6490259 – Upgrade from OnStage to Sun Connection 1.0.3 - fails to upgrade the database
6490125 – Upgrade issue caused by the problem of accessing the database
6487541 – Error message is garbaged in the job log in the case when download fails
6427198 – Temorary files are not removed
6454730 – Upgrade job with broken rules
6454738 – The popup jumps twice instead of once in the hosts window
6454855 – Host groups actions should be disabled for restricted users
6454911 – Add start/stop times to logs and console
6454988 – DBGetJobs: GetJobSummary doesn't return error on non-existing JobId
6454989 – Error messages in the solaris debug log
6455011 – Cache local components
6455028 – Immediate Exit When The Server Is Down
6455065 – Bad command line for: "Is PKG installed ?" check
6455851 – Error message is appearing in the Itanium log (debug log) while running a job
6455902 – Confirmation for a reboot
6455970 – Print Button of Jobs History Report Disabled
6456007 – Error popup jumps more then once
6456059 – Wrong action displayed for all the Notifications in the Jobs report
6456072 – The https_proxy environment overrides director.rc setting
6456096 – Problems installing patches on Solaris10 zone
6456140 – Authentication window
6456164 – Reason of failure in the log is not clear
6456169 – Several bugs will occur when choosing "Day in Week" or "Day in Month" without selecting specific day
6456174 – The debug log file size should be bigger than 2mb
6456178 – Uploaded blobs are not attached after the upgrade from 439 to Sun Update Connection – Enterprise 1.0
6456190 – No agent support for sun4us and sun4v
6460566 – Can't uninstall agent if agent cannot talk to SDS
6465543 – Confusing message while uploading the local package which architecture is wrong
6466870 – Temorary files are not deleted fro the config directory of the Windows console
6468073 – Sun Update Connection – Enterprise 1.0 upload.html never "attached" components
6468075 – VMCloning - "build template list" missing lock mechanism
6468076 – VMCloning - cloning not creating VDISKS
6472999 – Specific reason for failure is not logged when a script fails
6475896 – Ability to bind agent to specific IP address
6480552 – No rules for locals
6480736 – Explorer will not install on Solaris 8 agents
6482852 – Agent installation fails with: ./Install: not found
6486527 – Solaris Hardware Seeker does not collect information properly
6486646 – GetHostInventory is not working for Solaris agents
6488537 – Username/Password stored in config and text files should be encrypted
6491691 – Uploading the local package in the format of tar.gz from the upload .htmp/console problem
6493263 – Small memory leak in agent
6493376 – Installer fails to identify pkg
6493599 – Install -us is broken for Solaris hosts
6493866 – Problem with downloads when the blob is available but the sig is missing
6494336 – Solaris hardware seeker missing sun4us (Fujitsu) and sun4v (coolthreads) arch handling
6494343 – EzInstall fails in proxy environment which filters User-Agent Strings
6496245 – UCE_proxy is broken, does not cache blobs
6496791 – The /etc/init.d/uce agent stop kills agents in local zones
6505376 – Jobs are stuck in the specific cases
6505392 – Incorrect postgresql status report
6505586 – Upgrade problems
6505773 – CLI export Profile creates invalid profile.xml file
6505961 – Sun Update Connection – Enterprise breaks a core component of the Solaris OS (run control) by mounting /opt blindly
6507949 – Clean cache should clean blob and its sig together
6508004 – EzInstaller cannot uninstall old agents.
6482852 – Agent Installation Script Can Fail on All Versions of Solaris
6470383 – "Internal Query Failed" Message When Running Job on New Installation
6456169 – Scheduling Recurring Jobs
6456178 – Missing Solaris Packages After an Upgrade From Sun Aduva OnStage 439 to Sun Update Connection – Enterprise
6456009 – If you are using the Linux knowledge channel, you cannot use Sun Update Connection – Enterprise to set the default kernel
6460566 – Agent uninstall fails if SDS is offline
This section covers the following functionality:
The SDS should only be installed in one zone on a system, either a global or non-global zone. The agent can be installed on any zone. The installer does not have to know on which zone it is installed.
If you are planning to install an agent in a non-global zone, an agent must also be installed in the global zone (CR 6511890)
Before determining where to install the agent, consider the following Solaris zone patching rules:
When an agent is installed in a sparse zone, it is not possible to install packages or patches which require updates to the /usr directory. This is because the /usr directory is designed to be read-only in a sparse zone and is shared with the global zone.
Some patches installed in the global zone will also affect the local zones.
The zones hierarchy displays as a group and members of the group, for example if HostA has two non-global zones, it is displayed as HostA_zone_group [3]. Expand HostA_zone_group [3] to see the two non-global zones. The SDS automatically creates the group HostA_zone_group [3] and populates it with with registered agents from all of the zones on the system.
Before patching Solaris zones, you should be familiar with how zones are designed to work. An update can be installed in a non-global zone without being installed in a global zone, and vice versa. When patching to zones, some patches will not install in non-global zones (sparse or full) and others will. Some patches that are installed in the global zone do not affect non-global zones directly, but others do affect non-global zones. Within the constraint of the update itself. The packaging of the component defines whether it needs to be in the global zone or not. Under zones, there is just one instance of the Solaris OS, which means that usually components belonging to the OS runtime (kernel, services) must be updated in the global zones. The update meta-data, but not the bits, is propagated to the non-global zones.
See CR 6533814.
The directory change impacts the CLI procedures that are used for Solaris software. In this procedure, you will use a script from the Sun Connection CLI application to upload Solaris software. Use this procedure if you are unfamiliar with Solaris commands and having trouble unpacking the PKGs or tarring the directories.
Install the latest Sun Connection CLI.
The script is located at /opt/SUNWuce/cli/bin/uce_cli.sh.
Change to the following directory by typing:
cd /opt/SUNWuce/cli/bin/ |
Type the following command:
uce_cli -upload_files -D OS-version_architecture -T file1[,file2] -u admin
Where the file1 and file2 are absolute pathnames.
Type a password for the Sun Connection admin user.
For the channel, type the number of the distribution-architecture, according to the displayed list of Available Channels, to which the packages you want to upload belong.
At the prompt Would you like all found components to be added under specific category?, type y to put the packages in a user-defined category, and then at the Category name prompt, type the name of the category.
If the category does not yet exist in the Sun Connection components list, it will be created. If you type n, the packages are added under a default category in the components list.
uce_cli.sh will tar the Solaris package directories. Then it uploads the tarballs to the knowledge base. Sun Connection recognizes them as Solaris packages and enables you to deploy them as PKGs.