Written by Lucian Nicolae Ciufudean, HPSW Automation and Compliance RnD
For many years now, one of the main approaches to managing a datacenter has been to regularly run scripts that bring your servers up-to-date. This is the original approach of Unix sysadmins and it persists with more recent tools like Chef. Original scripts coded in low-level Bash syntax have transitioned to first Perl, then Python scripts and are now being rewritten into user-friendly Domain Specific Languages (DSLs) that are helping to power DevOps.
But a script-oriented approach has a crucial shortcoming. Although regularly running scripts is necessary to keep servers updated, their complexity means that you cannot actually guarantee they’ve done their job—even after you run the scripts, the servers may not be operating in the state you expect or require.
The server states you desire
That’s why sysadmins have now begun using a different technique of datacenter management, appropriately called the Desired State approach. In this method, the desired state for a server is modeled and then the tasks that update a server aim to match this model. What makes this approach so valuable is that once a task is complete, a simple scan operation is all that is needed to check if the server conforms to its desired state.
How to use policies for the Desired State
HP Server Automation supports the first script-oriented approach with its Distributed Script Execution engine, which is able to run Unix shell, Python, Windows BAT, VBScript, and PowerShell scripts on managed devices. And with the recent 10.1 release, it now brings the power of Chef Cookbooks under the same umbrella.
But the real power of Server Automation is demonstrated in how it implements the Desired State model—by using policies. A policy is a collection of Server Automation items, including everything from package items and audit rule items, that are attached to a server or groups of servers. It’s these policies that create a persistent desired state for the targets.
Here is a brief look at how users create Server Automation policies for software stacks, patch bundles and compliance standards.
A. Software policies
Used for deploying software bundles, one of these policies can group packages together, change configuration files as needed, and specify pre- and post-installation scripts. By building multiple software policies on top of one another, you can use Server Automation to deploy entire software stacks. Software policies are also used to deploy many internal Server Automation tools to managed servers.
B. Patch policies
Patch policies are created and maintained within the process of importing vendor patch catalogs, scanning systems for vulnerabilities, importing the needed patch binaries and applying the patches to managed devices.
It’s good to start with a single patch policy per platform, and one that is regularly updated based on discovered vulnerabilities and vendor patch catalogs.
Security controls within HP Server Automation enable a range of patch policies, from ones that support open operation modes that automatically accept vendor recommendations (i.e., “if it's good for the vendor, it’s good for us”), as well as more restrictive modes that limit making patches available for consumption only once they have been reviewed and tested, which effectively allows you to override vendor recommendations.
Administrators who manage servers can use predefined audit policies when auditing servers, allowing for the automated identification of whether an IIS Metabase value exists, for example, or confirming that a specific Linux service is set to always be running. An audit policy is a collection of reusable rules that define the desired state of server configuration based on industry standards and the compliance goals set by your organization.
Automating the datacenter lifecycle
Policies are an integral part of more complex and impactful Server Automation use cases.
For example, OS Build Plans are used to provision operating systems on bare metal servers. These are essentially lists of ordered steps that automate the process of turning a server in a bare metal state into a fully configured and patched system, by using a series of software and patch policies as individual steps within the overall OS Build Plan.
But that’s just one scenario. The ability to attach and remediate policies to Virtual Machines that have been deployed from VM templates significantly cuts down on managing VM templates. In an organization that uses MS Windows machines for three purposes — administrative, accounting, and financial, for example — administrators can maintain a single VM template and deploy the software stacks and security patches through software and patch policies. The advantages grow with an expanded number of combinations between the OS version, software stack version and approved security patches.
Keeping even tens of thousands of servers properly patched and in compliance does not need to overwhelm an IT team. Lifecycle server management can now be efficiently automated, with only modest oversight by a server administrator, allowing organizations to scale to admin ratios of 1:300 to 1:500 servers while still maintaining a secure and reliable environment with IT automation.
Next, join us on the HP Automation and Cloud Management Community. A place where you can share your thoughts and ideas, and see what others are saying about IT automation and cloud management. Your voice deserves to be heard by a community that matters, where practitioners go to be heard.