Chapter 7 Optimizing Performance For Linux

This chapter explains the principles of the technology that guides the performance of Sun Update Connection – Enterprise and how to optimize its features.

• Defining Linux Knowledge

• Using Local Updates

• Servers in the Solution

Defining Linux Knowledge

The system dependency server is the heart of Sun Update Connection – Enterprise. It contains the dependency manager and the knowledge base.

Your local knowledge base, pulled from the universal server plus local software and data that you pushed from your hosts (to the local knowledge base, never to the Universal Server on the Internet), contains the following Linux information:

• Linux components – Logical units that are, or can be, part of a system. For example, RPMs, drivers, modules, and symbols.

• Dependency rules – Instructions for successful installation of a component and all of its dependent components.

  The dependency manager, or Engine, manages the agents. The Sun Update Connection – Enterprise agent is installed on every managed host and runs the Dependency Resolver, the application that finds the most cost-effective solution for jobs. In this way, every managed host finds the best solution for its own software configuration. Agents solve jobs with rules and components.

RPM Components

A component is anything that can be downloaded and installed on a system. Most of the certified components on the universal server are RPMs.

Linux is not developed by a single company. Instead, thousands of independent, Open Source developers constantly update and improve the Linux operating system. There are tens of thousands of components available for download and installation.

The RPM Package Manager brings some order to the chaos. The idea of a Linux package provides a standard for independent developers to offer their applications for distribution. The RPM standard describes how to name a package, how to structure its format for consistent management, and the type of data it should or may contain.

A set of components packed with the RPM engine is also called an RPM and is also packed with the following data:

• Date, time, version, release, and environment (such as Intel or zSeries)

• Description of the packed components, including the following: names, size, installation paths, permissions, owners, general security checks, and file contents.

• Reference to other components. For example, what it is similar to, what it is dependent upon, and what it conflicts with.

• a signature to verify authenticity

To Create an RPM

1. Collect the source files of the application and any new updates.

2. Write the specification file containing packaging scripts run by the RPM engine and a file list.

3. Run the RPM Engine with flags to build the package.

   Notice that the RPM procedure is rather loose. The developer can decide which source files to include in the package. Other files, such as libraries and basic operating system components, may be simply pointed to in the reference data as dependent packages. This means that the end user must make sure that all packages that the developer assumed were already installed are, in fact, on the system.

   When the user installs an RPM, the scripts (written by the developer, not created by an automated standard) are run and tell the user the following information:

   • If dependent components need to be installed

   • If there are installed components that conflict with files in the package

   • The version range of dependent components and conflicting components

Dependency Rules

Most Linux components depend upon the prior installation of existing libraries or other packages to operate in known system configurations. These other components are dependent components. For example, kdesdk*.rpm needs gcc-c++ to be installed.

When components need incompatible versions of dependent components, a dependency conflict arises (packages or files that should not exist on the same system as the base component, such as an earlier version). For example, if mysql-devel is installed, MySQL-devel does not work.

Descriptions of dependencies and dependency conflicts are called rules.

To install a component manually, without using Sun Update Connection – Enterprise, you must discover and install the complete dependent component list before you can install or run the original component. When you install a component with Sun Update Connection – Enterprise, dependency issues are taken care of automatically. In addition, the rules of the knowledge base are exact and accurate, while the rules included in an Open Source package may not be.

Standard Dependency Rules

Open Source packaging rules are based on loose standards.

Package developers might write very specific dependency rules, but the rules might be more restrictive than necessary. For example, a specific set of rules might say that you need at least version 1.5 of a software package. You have version 1.3 of the software and upgrade to a version that meets the dependency rules. However,v it could be that earlier versions are not in the rules because the developer did not test those versions.

Other developers might be to general when writing the dependency rules, and you might encounter conflicts even if you follow the rules.For example, a general set of rules may say that you need version 1 to 3 of a software package. Another developer creates v2.9, which causes a conflict with your other installed components

Sun Update Connection – Enterprise Dependency Rules

The dependency rules in the knowledge base are exact, neither too specific nor too general.

For example, the standard rules for SuSE’s dia-0.85-34 package (an application for creating diagrams and flowcharts) say that this package needs libxml of any version. Among the certification tests, the dia package was installed on a system with libxml-1.7.3-3. An installation error resulted. Running more tests, the exact Sun Update Connection – Enterprise rule was created: dia-0.85-34 needs libxml from version 1.8.6-18.

The Certification Lab tests every component and finds its exact installation rules, listing, including the following:

• All dependent components

• All component conflicts

  In addition, if a dependent component has its own dependencies, this is also known. There is no limit to the number of levels that Sun Update Connection – Enterprise takes into account.

  The knowledge base contains the dependency rules, and Sun Update Connection – Enterprise uses it to automate functional installations. Sun Update Connection – Enterprise also finds potential conflicts, warns you of them, and suggests alternatives before you install a component.

Using Local Updates

The knowledge base is updated continuously, providing you with relevant update management from the Linux community and public update releases.

In addition, you may have private components that your own organization has patched and customized. Using Sun Update Connection – Enterprise, you can mark a local component as a security fix for a previous local component and upload the security fix to the local knowledge base.

Marking a local component as a security fix has the following results:

• During the predefined profile Security Check, if a host has the first version installed, it is upgraded to the Security Fix version.

• During a user-defined profile, if the job should install the local package as a dependency, the Security Fix version is given priority over the earlier version. If the job is marked for Use secure components only, only the Security Fix version can be installed. The job fails instead of installing the unsecured version.

  If a later update is created that provides enhancements on the Security Fix package, you may decide that both local packages are Security Fixes, or that only the latest package is the one preferred Fix. From the console , you can select a Local Software component and then change its Security Fix mark.

To Mark a Local RPM as a Fix

Before You Begin

Ensure that the Inventory panel is visible. From the View menu, choose Inventory.

1. Log in to the system as a superuser.

2. From the drop-down list in the tool bar, select a distribution-architecture.

   The Components list changes to show the components relevant to your selection. The NCOs that you add with this procedure are added to the inventory of the displayed distribution.

3. Under the Local category, select Local RPMs or a user-defined category under it.

4. Right-click the selected category and choose Local, then choose Add.

   The Add Software window opens.

5. Select whether the RPM is accessed from the localhost (console) or from a remote managed host.

6. Browse to the file if it is on the console; type in the path name if it is on a remote host.

7. Check Security Fix.

8. Click OK.

   The Add Package window closes. The software is added to the knowledge base as an update to the previous like-named added components.

Secure Components Default Setting

The job option Use secure components only, which makes sure that all dependencies installed for a job do not have later uninstalled updates, makes the job run slower and take up more resources; therefore, it is deselected by default. If you are sure that you want all jobs to run this check before installing anything, you can change the default settings.

To Change Console Preferences for Secure Components

1. From the Tools menu, choose Preferences.

   The Preferences window opens.

2. Select the Console radio button.

3. In the Category list, choose Jobs.

4. Select the Check security checkbox.

5. Click Submit.

   The Preferences Confirmation window opens.

6. Click Submit.

   You do not need to logout to apply this setting.

7. Open the New Job window, Options tab.

   Notice that Use secure components only is selected by default.

Servers in the Solution

When an agent registers with the dependency manager (DM), it downloads the rules and the components from the knowledge base. The system dependency server verifies that the knowledge base is updated from the universal server, and in turn, the DM updates the agents. The DM also updates the console, to give you an easy-to-read hierarchy of available components.

In a simplified explanation, the applications work together as follows:

1. Agents and consoles download the rules and components from the knowledge base.

2. After you create a job on the console, the dependency manager picks up the job and distributes it to the selected agents.

3. Each selected agent runs the dependency resolver that uses the rules to find the most cost-efficient solution for its own managed host.

4. The agents use certified components to complete the job.

5. The job results are sent to the dependency manager, which updates the console and the log database.

Server Security

Sun Update Connection – Enterprise has a variety of security measures integrated into its solution.

Table 7–1 Integrated Server Security

Key Encryption	Communications between the dependency manager and the agents and console are protected by a private/public key encryption algorithm.
Proxy Support	Sun Update Connection – Enterprise supports HTTPS web proxy servers, enabling another level of security to updates from the universal server.
Internet Protection	All Internet communications are protected by SSL and certificate verification. All communications from the agents are proactive; the system dependency server pulls only from the universal server, never pushes data to it.
Component Security	Every component available for download from the universal server is certified. You cannot download Trojan horses or other exploits that are disguised as useful software.