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
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
-
Collect the source files of the application and any new updates.
-
Write the specification file containing packaging scripts run by the RPM engine and a file
list.
-
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.
-
Log in to
the system as a superuser.
-
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.
-
Under the Local category, select Local RPMs or a user-defined
category under it.
-
Right-click the selected category and choose Local, then choose Add.
The
Add Software window opens.
-
Select whether the RPM is accessed from the localhost (console) or from a remote
managed host.
-
Browse to the file if it is on the console; type in the path
name if it is on a remote host.
-
Check Security Fix.
-
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
-
From the Tools menu, choose Preferences.
The Preferences
window opens.
-
Select the Console radio button.
-
In the Category list, choose Jobs.
-
Select the Check security checkbox.
-
Click Submit.
The Preferences Confirmation window
opens.
-
Click Submit.
You do not need to logout to apply this setting.
-
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:
-
Agents and consoles download the rules and components from the knowledge base.
-
After you create a job on the console, the dependency manager picks up the job and
distributes it to the selected agents.
-
Each selected agent runs the dependency resolver that uses the rules
to find the most cost-efficient solution for its own managed host.
-
The agents use certified components to complete the job.
-
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.
|
以 PDF 格式下载本书 (632 KB)