Search for	Example	Results
A single word	`cat`	Topics that contain the word "cat". You will also find its grammatical variations, such as "cats".
A phrase. You can specify that the search results contain a specific phrase.	`"cat food"` (quotation marks)	Topics that contain the literal phrase "cat food" and all its grammatical variations. Without the quotation marks, the query is equivalent to specifying an OR operator, which finds topics with one of the individual words instead of the phrase.

Search for	Operator	Example
Two or more words in the same topic	`AND` `and` `+` (plus symbol) `&` (ampersand)	`cat AND dog` `"cat food"+milk` `"cat food"&"dog food"`
Either word in a topic	`OR` `or` `\|` (pipe)	`cat OR dog` `cat \| dog`
Topics that do not contain a specific word or phrase	`NOT` `not` `!` (exclamation point)	`NOT cat` `! dog`
Topics that contain one string and do not contain another	`^` (caret)	`cat ^ mouse`
A combination of search types	`( )` parentheses	`cat + (dog \| mouse)` `cat \| dog + (! mouse)`

Server Automation10.60

Administer > SA remote communications administration > SA Core communications infrastructure

SA Core communications infrastructure

SA is a distributed computing environment in which individual components communicate with each other securely over an IP network. To accomplish this, SA uses SSL/TLS and X.509 certificates to secure the communication between these components.

When an SA Core component must communicate with another component, it opens a secure (typically SSL/TLS) communication channel using a well-known port. Each SA Core component has a public-key certificate, which is generated when SA is installed. The component uses this public-key certificate when authenticating itself to another component. Most interprocess communication is strongly authenticated (encrypted using the strongest ciphers available) and integrity checked.

Communication between SA Cores
Advanced communication between agents and SA Core components

Communication between SA Cores

If you are running SA across multiple data centers, SA automatically synchronizes data across all SA-managed data centers. Broadly speaking, SA synchronizes two types of data: the SA model of servers (including all hardware, software, and configuration attribute information) and software packages.

Replicating the SA model: SA uses integrated certified messaging to synchronize the SA model data. SA implements SSL to safeguard the messages flowing across the message bus. These messages describe SQL changes that must be made to the SA database (Model Repository).
Replicating software packages: SA replicates software packages on demand. That is, packages are only copied when needed. For example, when an administrator managing a server in the New Jersey data center directs SA to install a software package that does not exist in New Jersey’s Software Repository, SA requests it from another data center.
The actual file transfer uses the open source utility rsync, and the communication channel is secured using SSH. The process is similar for Satellites and for peer-cached software repositories.

The following figures show a two core installation with a Satellite and how the cores’ components communicate using Gateways.

Primary SA Core

Secondary core and satellite

Advanced communication between agents and SA Core components

SA Agent installed on managed servers also participate in strongly authenticated and encrypted SSL/TLS traffic. In addition, when Agents are directed to perform management tasks on a server, the typical flow of control messages help to ensure that only authorized users are performing those actions. It would be extremely difficult for an intruder to generate a valid command sequence directing an Agent to perform an unauthorized task.

The following sequence describes a typical SA management task: provisioning software on an SA managed server. Other operations on managed servers follow the same general protocol:

The Data Access Engine opens a communication channel through HTTPS with the SA Agent, directing it to perform a management task.
The SA Agent calls back to the Data Access Engine to retrieve specifics about the task to perform. To open a communication channel, the Agent must present its public-key certificate, which the SA Core verifies against an internal database mapping the certificate itself to the machine’s IP and a unique machine identifier that SA generates when the agent is installed. This safeguard prevents users from simply copying the digital certificate and corresponding key to another machine in hopes of masquerading as the original managed server.
After successfully opening the communication channel, the SA Agent receives the exact list of software to be installed and removed (as well as any scripts to execute, the order of software installation, and when to reboot during the provisioning process).
The SA Agent opens a communication channel to the Software Repository (also through HTTPS) and requests a download of the software it needs to install. Before the Software Repository initiates the download, it recomputes an SHA checksum for the package along with a secret key it knows. Only if the SHA checksum matches the checksum generated when the package was uploaded does the SA Agent receive the software it requested, yet another security safeguard.
Asynchronous, agent-initiated calls to the SA Core provide scalable support for progress reporting and long-running operations, as the SA Core need not manage thousands of synchronous agent operations directly. SA supports these asynchronous calls from the Agent to the Core even in network environments where firewalls prevent Agents from initiating TCP connections, since the SA Gateway infrastructure provides bidirectional tunneling over unidirectional connections.

Other technical details of agent/core communications include:

Connections are TLS1.x (based on what the core set up is), mutually authenticated with X.509 certificates (the server checks the client’s certificate, and vice versa).
Private keys for Core and Agent certificates are stored in files that are readable by root only.
All certificates are generated at installation, are owned by the customer, and are not known to HPE.
Depending on your selected certificate mode, SA certificates are signed by SA internal self-signed Certificate Authorities or by your external Certification Authority. To avoid HTTPS security warnings in web browsers, customers may install an externally signed certificate in the SA instance of Apache.

This section provides reference information about the parameters in the Gateway Properties file used by the SA Gateway.

Send Help Center feedback