Process for using components
While the TrueSight Server Automation Console offers a flexible user interface that allows multiple approaches to a single problem, TrueSight Server Automation recommends following a standard process for using components.
The process consists of the following phases:
Establishing requirements
During the requirements phase, you must decide which aspects of your data center infrastructure should be implemented as components.
Most commonly, components are used to implement policies and services that affect multiple servers and are prone to misconfiguration. These uses can be categorized into:
- Software models — Defining and maintaining policies about infrastructure services and applications. At the infrastructure level, components are commonly used to manage implementation of application and database servers such as WebLogic and Oracle. At the application level, components can encapsulate complex programs such as web servers, backup agents, monitoring agents, and business service management systems.
- Compliance policies — Defining and maintaining collections of configuration policies, such as required settings for password lengths, password expiration periods, and lockout rules.
Designing components
During the design phase, expert administrators use the Component Templates folder to model the requirements for component templates in a controlled test environment.
Component templates identify the server objects and configuration settings needed to make a component. For example, a component template might specify a collection of files, software, and registry settings needed for an application. Or, a component template might include a collection of configuration settings, such as password lengths and expiration requirements. A component template also includes decisions about how the component should be used and maintained.
When defining component templates, many configurations settings vary between environments. For example, settings may change between servers, networks, or departments. A component template lets you accommodate these differences by using parameters. A parameter can resolve to a different value on each server. For example, the path to a directory can include parameters such as ??TARGET.SYSTEMROOT??/rsc. In this example, ??TARGET.SYSTEMROOT?? can have different values on different target servers, such as /c or /d. Similarly, a path such as /usr/??TARGET.DEPLOYPATH?? could resolve to values like /usr/DEV, /usr/QA, or /usr/PROD. A deploy path like this allows a component to be discovered in different locations on servers used by different departments.
There are several stages to component template design. A wizard helps you initially create a basic component template, as described in Creating-a-component-template. You then refine the template's definition during an editing process, as described in Editing-a-component-template. When editing the template, you can specify any of the following:
- Allowable Operations — Determines whether a component as a whole can be used for browsing, snapshots and audits, discovery, deployments, and compliance. If a component is subject to compliance, you must also determine whether its configuration can be remediated when compliance failures occur.
- Template Parts — Defines the collection of configurations on which you can operate. For example, template parts can be collections of files, properties, and registry values or a group of security settings.
A component template need not include only those parts used by an application. A part can be used for other purposes, such as component discovery and compliance. Some users include a part that should not exist and test for its presence when discovering the component. If the part is present, the component is not discovered.
When defining component template parts you can choose the types of operations that each part is used for, such as compliance, browsing, snapshots, and audits. - Signature — Specifies the set of conditions that a server must satisfy for a component to be created. A signature can be a very simple test, such as verifying the existence of a single server part, or it can be much more sophisticated, specifying multiple mandatory conditions.
Signatures must be based on template parts and properties. You can specify that a part must exist or that it must exist and satisfy a list of additional criteria in the form of part characteristics. When evaluating part characteristics, you can use many types of operators, such as equivalence, inequality, membership in a list, or inclusion in a range of values. Similarly, you can specify that a part cannot exist. You can also specify that either a part does not exist or, if it does, it must satisfy a list of conditions. If you want to add signature conditions in the form of property values, you can create lists of properties and evaluate those properties with an extensive list of operators, much like you can with parts.
After you have defined a signature, you can test some representative servers to determine whether you can successfully associate this component template with servers. After a component template is complete, you can run a Component Discovery Job, which examines a server to determine whether it matches the conditions in the component signature. If it does match, a component is associated with the server. - Browse — Specifies the individual template parts that can be browsed after a component has been associated with a server.
- Snapshot and Audit — Specifies the individual template parts that are used in Snapshot and Audit Jobs after a component has been associated with a server. You can use includes and excludes to refine this list of template parts. For example, you can include only DLLs, or exclude log files. You can also specify options that apply when using these template parts in snapshots and audits, such as whether the snapshots and audits should include MD5 checksums.
- Compliance — Specifies a subset of the component template parts and defines compliance rules that these parts must satisfy. Each compliance rule can include a set of instructions explaining what actions to take if a rule is not satisfied. One possible action is the deployment of a BLPackage to correct the problematic configuration.
After a component template is complete, you can run a Compliance Job to monitor the configuration of component. For each component, the Compliance Job examines the template parts specified in the compliance rules, comparing them to the rules that you have defined. When a component fails to satisfy the compliance rules and remediation is enabled, you can deploy a BLPackage to correct the issue. Remediation can occur automatically, as part of a Compliance Job, or you examine Compliance Job results and manually remediate compliance rule failures. - Local Properties — Specify properties you can assign directly to a component template. Local properties let you discover multiple instances of the same component on the same server. For example, on a single machine you may want to create two versions of the same component --- one for development and one for QA. In such a case, you can use two instances of a local property, with each instance defined to the values you need. A Component Discovery Job automatically discovers a component for each of those local property instances.
One common usage of local properties is to create a Custom Property Class in the Property Dictionary with instances that contain the various possible values of your properties. The local property in the Component Template (or BLPackage) then links to the custom class. In this way you can re-use the same property structure and values across multiple objects. - Local Configuration Objects — Allow you to create configuration objects (that is, configuration files or extended objects) that apply only to this component template. When defining a local configuration object, you can specify a path to that object using local properties as parameters. By setting up properties in this way, you can create one definition of a configuration object that applies to multiple components on the same server.
- Install/Uninstall — Allows you to install and uninstall components by associating Batch Jobs with component templates. The installer Batch Job runs a series of jobs that deploy all parts necessary to create a component. The uninstaller Batch Job can remove component parts and invalidate an existing component.
Discovering components
After you are confident that a component template developed during the design phase satisfies your requirements, you can use it to run a Component Discovery Job.
Instructions for creating a Component Discovery Job are provided in Creating-and-modifying-Component-Discovery-Jobs. This Job compares the signature of a component template with the configuration of a server. If the server configuration satisfies the signature, the Component Discovery Job creates a component by associating the component template with the server. If a component includes multiple instances of a local property, the Component Discovery Job compares the signature to each instance of that local property on each server, creating a separate component every time the test succeeds. In this way you can rapidly create multiple instances of the same component on a single server.
When components are successfully discovered on a server, TrueSight Server Automation creates a representation of that component in the Servers and Component Templates folders. In the Servers folder, the component is associated with the appropriate server when you browse the server. In the Component Templates folder, the component is associated with the appropriate component template. You can also organize and manually display components in the Components folder.
TrueSight Server Automation also provides a mechanism for manually associating a component with a server, as described in Adding-components-to-servers-manually. This procedure allows you to quickly add a single component to a server. Manual creation of components lets you define exceptions to compliance rules. This can be valuable if you know a server cannot satisfy compliance rules but still want to associate a component with it.
Typically, if you are using components to ensure compliance with a policy, you use a Discovery Job to create components. Discovery Jobs let you rapidly create components on many servers, which is typically necessary if you are enforcing a policy such as security requirement. On the other hand, if you are using components to distribute a consistent software model, you can use a Discovery Job to create a component, or you can use the manual process for component discovery if you are only creating a few components based on a component template.You can also choose to perform automatic component discovery later on, during the initial stages of execution of any component-based job (that is, any specific Compliance Job, Snapshot Job, or Audit Job), as an alternative to preparing components in advance using the Component Discovery Job. To enable this option, you use the Run auto-discovery check box in a Compliance Job or Snapshot Job, and you choose a server as master in an Audit Job.
Implementing usage of components
After you have discovered components, you can begin to implement their use.
If you are distributing software based on a software model, you typically package and deploy components based on a component template (see Packaging-and-deploying-a-component).
If you are ensuring compliance with a policy, you typically run a Compliance Job (see Creating-Compliance-Jobs) based on a component template. Then you can view the Compliance Job results (see Compliance-results). If you prefer, you can export the results to view them in another format (see Exporting-compliance-results).
When you set up a Compliance Job, you can enable the automatic remediation of any compliance rule failures. If you enable automatic remediation, the Compliance Job can gather BLPackages containing the settings and server objects needed to ensure compliance and deploy those packages to any servers where components require remediation. You can also deploy packages directly to components, which is particularly useful if you have multiple components on the same server.
Alternatively, after a Compliance Job finishes, you can view the Compliance Job results, where you can see which compliance rules have not been satisfied and can manually choose the situations that require remediation. To handle such items, you can gather BLPackages and deploy them to the servers or components needing remediation (see Manually-remediating-compliance-results).
Some compliance failures may not require remediation, and you can define compliance rules that ignore the failure. In addition, you can create components that do not satisfy compliance rules in the component template but are nonetheless classified as consistent when you run a Compliance Job. You can even define exceptions for a particular server object, as long as the object can be expressed in the form of a path. Exceptions must be set up on a component-by-component basis, by using the same procedure that you follow when manually creating a component (see Adding-components-to-servers-manually) or modifying an existing component (see Modifying-components).
In some situations, you may determine that a compliance rule needs adjustment or that some other aspect of the component template definition needs adjustment. If you modify the definition of the component template, your changes are automatically applied to any existing components.
After you are satisfied that the deployed components are compliant with the component template, you can begin to treat components as you would any other server object — you can browse, snap, audit, and deploy them. You may also want to continue to run Compliance Jobs on the components to ensure that they remain consistent with the component template. To run a Compliance Job, you must first define compliance rules, a task performed when you edit a component template.
You can use snapshots and audits of components for tracking change. For example, you can take snapshots of components on a regular schedule to monitor change on an ongoing basis. You can use those snapshots to identify what changes are occurring in server configurations and when those changes have occurred.
Because you can run Snapshot and Audit Jobs on multiple components simultaneously, you can group components together according to the business service they perform. For example, if you are using an enterprise resource planning (ERP) system that consists of multiple applications, you can encapsulate each application into a component. Then you can use regularly scheduled snapshots to record the configuration of all applications in the ERP. You can use audits to identify and correct discrepancies in those configurations.
For an example that demonstrates how to ensure application compliance using many aspects of component-related functionality, see Using component templates to ensure compliance for multiple instances of an application.
Where to go from here