What's new in SA 10.50?

Authentication to the SA Core is now done in the SA Client, after the Launcher has downloaded the required files. The SA Client Launcher now accepts only one input from the user: the SA Core hostname/IP address. A new window appears, where you need to enter the SA username and password. For more information, see Server Automation.

Java Web Start has been removed from the SA Client Launcher. The functional changes that resulted are as follows:

• Log files are now located at the path <HPE_Server_Automation_Home>\logs
• The Show Java Console option is no longer available and is assumed checked when connecting to SA releases prior to 10.50
• SA Client application data is reused when connecting to core servers with the same build number

Windows operating systems supported on the SA Client

Following is a list of operating systems supported on the SA Client:

• Windows Server 2008 R2
• Windows 7
• Windows 8
• Windows 8.1
• Windows 10
• Windows Server 2012
• Windows Server 2012, R2

The new Linux Service operating systems provided with SA 10.50 is based on CentOS.

Service OS (SOS) bits are not available for the PPC and IA processor architectures in the current distribution.

In case of an upgrade, the existing RHEL IA and PPC Service OS bits will not be removed. The existing RHEL x86/x64 bits will be renamed, adding 'rpmsave' to the original name. Restore these bits by replacing the linux50/linux60/linux60x64 folder with rhel50rpmsave/rhel60rpmsave/rhel60x64rpmsave, at these paths: /opt/opsware/boot/tftpboot/ and /opt/opsware/boot/kickstart/. If you are performing a new installation, there will be no Linux Service operating systems for these two processor architectures.

SE Linux support in SA

New for SA Web Client

The SA Web Client is now used for downloading the SA Client launcher. The Web Client can be accessed as before, by navigating to a slice IP address or hostname. It features a completely re-designed home page that contains the following:

• a Download Server Automation Launcher button
• information about SA version and build
• a link to the HPE Support site

The functionality that were previously available in SA Web Client can now be accessed from the SA Client as follows:

• Service Levels, found under Administration > System Configuration.
• OS Installation Profiles created through a script on an SA Core. For more information on OS Installation Profiles, see Defining and managing OS installation profiles.

New for audit and compliance

Added CRL (Certificate Revocation List) support for access to SA using SA client with smart card authentication.

SA 10.50 will be localized to Simplified Chinese, Japanese, German, Russian, French, and Spanish.

Updates pertaining specifically to the OO-SA integration (Server Automation operations performed within Operations Orchestration) are delivered via the HPE Live Network.

For changes to the Oracle Database and Model Repository, see Oracle setup for the model repository.

SPARC servers can be provisioned now using OS Build Plans and not just OS Sequences. However, both the methods cannot be used at thOn RHEL 7.2, you must upgrade the system package at least to version 219-19.el7_2.4. Otherwise, the core services will not start automatically upon reboot. See errata for details. same time. The default configuration is the OS Build Plans provisioning mode.

To ease the switch between the modes and dhcpd.conf configuration, use the following script:

/opt/opsware/boot/jumpstart-sparc-ogfs/tools/switch_OSS-OSBP.sh

When run, it will print the current provisioning mode for SPARC servers and request for your confirmation before switching the mode. If you continue, the script will backup the dhcpd.conf file, perform the required changes and restart the dhcpd service.

SA Client Session Inactivity is enabled and set by default to 30 minutes. This will lock the SA Java Client if you are idle for the specified period. You need to re-enter the password to unlock the SA Java Client. This setting will not be enforced when upgrading installations that have any custom settings applied under Administration > Users and Groups > Security Settings > Password Policy Settings.

SA can be installed on servers that are running Red Hat Enterprise Linux 7 (x86_64).

The SA 10.50 Administration Guide provides information on how to achieve failover, server load balancing, and high availability in the SA environment.

The SA Backup and Restore Best Practices white paper provides the best practices you can use to backup and restore SA with minimal data loss in a situation where SA has been adversely affected by data or power

failures.

New version of HPE Live Network Connector

The Live Network Connector (LNc) that is installed on the SA core at: /opt/opsware/hpln/lnc/bin is outdated and can no longer be used to download content.

You need to download the latest version of LNc and install it on the core.

1. From HPELN, download the latest version of the HPE Live Network Connector.
2. Copy the new version to the SA core at /opt/opsware/hpln/lnc and install it: #./install

After installation is successful, LNc should work correctly.

Now you can configure debugging for ptymonitor through the ptymonitor.debug_name parameter in the agent's configuration file, agent.args.

In this release, RC4 has been disabled for SSL encryption.

The new custom attribute hpsa_preserve_solaris_user_home_path allows you to import users using your user-home path in /home/…. In previous SA versions, the import tool added /export to the path. To exclude the /export addition to the path, set the custom attribute to Managed Server.

For agents installed on a non-system drive (a feature available from SA 10.21 for Windows platforms), the agent uninstaller removes symbolic links on the system drive and all agent files, except the target directory.

Selecting PAPXs after Agent installation

Using ADT (Agent Deployment Tool) you can select a maximum of 10 PAPXs to be run sequentially, after the agent is successfully installed. If one of the APX scripts fails, the system stops at that step, and does not run the remaining APXs, and reports the job as FAILED.

This release includes three PAPXs for the following functionality:

• Assign Server to Customer
• Attach Server to Device Group
• Attach Server to Software Policies

Red Hat dynamic patching

SA 10.50 adds support for Red Hat dynamic patching. Dynamic patch policies do not contain a list of policy items like their static counterpart, but apply the required updates to the managed servers based on the vendor recommendations. Dynamic patching offers better performance and scalability over static patching through software policies and it is the recommended way to keep your managed servers up-to-date. For more details, see Patch management for Red Hat Linux Enterprise.

SA SUSE Manager Importer

SA now offers a SUSE Manager Importer tool based on the SA RedHat Importer. The tool is capable of importing packages and errata from the SUSE Manager 2.1 Server and creating SA Software Policies for errata and packages hosted by SUSE Manager. For more information, see White Paper: SUSE Manager SLES Importer and the SA 10.50 Support and Compatibility Matrix.

Red Hat Satellite 6.x support

Modifications have been made to the HPE SA Red Hat Network (RHN) import tool to support content download from Red Hat content delivery network (CDN) using Red Hat subscription management (RHSM). This allows you to download content for Red Hat Enterprise Linux 7 (RHEL). For more information on how to set up and use the HPE SA Red Hat importer tool, see Using the Server Automation Red Hat Importer.

New features

• New Run OS Build Plan UI.

• Support for deploying platforms on UEFI with secure boot enabled on HPE ProLiant.

  • New Linux 7 service OS with network and CD boot support for Legacy BIOS, UEFI, and UEFI with secure boot.

  • New WinPE4 service OS with network and CD boot support for Legacy BIOS, UEFI, and UEFI with secure boot.

• Improved customer assignment:

  • The "Assign Customer" step is now part of the OOTB build plans.

  • The UI is modified to be able to assign the server to a customer.

• New UAPI to enable creating customized pre-unprovisioned servers. For more information, check the ServerService.create (ServerVO vo, ServerHardwareVO hwVO) method.

• Content SDK to help customers with the development and deployment of Build Plans. For more details, see the documentation under /Opsware/Tools/Content SDK/ContentSDK-<version>.zip.

Updates

• ProLiant content upgraded to Insight Control Server Provisioning 7.5.1.

• WinPE 3 and 4-based service OS drivers updated.

New platforms supported by build plans

• Solaris 10 SPARC
• Solaris 11 SPARC
• Windows 10
• SLES 12
• Ubuntu 14.04
• Novel OES 11

For more details on the newly supported platforms, see Addendum Provisioning Feature in the SA 10.50 Support and Compatibility Matrix.

For all platforms, OS sequences are deprecated in SA 10.50 and later. The migration of any existing OS sequences to OS Build Plans for these platforms is strongly recommended.

For more details about the new features, see SA Provisioning.

RPM Rollback

Unit history

Starting with SA 10.50, all changes made to the units in the SA Library can be tracked using the new History element. The logged information includes name, description, platforms, location, install path, scripts, and flags.

Timeout handling for remediation and installation jobs

Server Automation now offers improved timeout handling for remediation and installation jobs. After a timeout occurs and until the job execution stops, the status of the server is changed to Stopping. While in the Stopping state, the agent does not take on any additional jobs and completes any job that is currently in progress. Moreover, if the timeout occurs during an agent reboot, then after restarting, the agent will not resume the job. After the job execution stops, the server will be marked as Timed Out.

This fixes the discrepancy of the core showing the job as Failed because of a timeout, while the agent is performing the job.

Job enhancements

Software remediation jobs now support a secondary expansion mode (“At runtime”) for device groups, software policies, and patch policies. This way, when a remediation job is scheduled to run in the future, the device groups, software policies, or patch policies are expanded when the job is started, compared to previous releases where the expansion was done at the time the job was created.

TLS compliance

According to PCI DSS v3.1 standard, any cryptographic protocol lower than TLSv1.1 is considered weak. Starting with 10.50 release, SA allows protocol selection (possible values: TLSv1, TLSv1.1, TLSv1.2). For more details, see Securing SA internal communications and SA 10.5 upgrade

Python upgraded from Python 2.7.3 to Python 2.7.10.

Adding a new (secondary) core to a mesh is performed in two stages, as before:

1. Defining a new facility and exporting required data (by running the hpsa_add_dc_to_mesh.sh script)
2. Installing the new secondary core (by running the hpsa_install.sh script)

The following changes were done in the process of adding a new core:

• The possibility to define and install the new core without providing credentials to the remote database servers (for the primary or secondary cores).

• The tar.gz file resulting after defining the new facility (that is, running the add_dc_to_mesh script) has been split. The database export and the CDF for the new core are no longer included. This provides the possibility to copy the database export directly to the secondary core database server and the tar.gz file and the CDF to the machine where the secondary core install will be performed.

• Two modes for transferring the files to the secondary core have been defined as follows:

  • Manual: Files are exported but not transferred to the secondary core. SSH credentials for the remote database servers are NOT required.

  • Automatic: Files are transferred to the secondary core. SSH credentials for the Oracle (primary and secondary) servers are required.

• When performing the secondary core installation, no commands will be run on the database server if it is not the SA-supplied one. In such a case, users must ensure that prerequisites are met, as displayed by the on-screen instructions.

  For details, see Install

root user

Local

A root user

regular user

Local

A regular user who has permissions to invoke commands as root with sudo capabilities.

For example: sudo <distro>/ opsware_installer/hpsa_install.sh

root user

Remote

A root user, including root ssh access

regular user

Remote

A regular user with sudo capabilities (including user ssh access)

There are two new optional parameters for the enable_ipv6.sh script:

• -i <IPV6 address>: Use a specified IPV6 address instead of an autodiscovered address based on hostname DNS AAAA resolution.
• -n : Do not start/restart SA components when making configuration file changes.