In mid 2014 Red Hat released the first Satellite 6 version to the market as a beta and followed up quickly with a 2015 GA release of version 6.1, which marked a milestone in the systems management arena. So what is Satellite? What makes 6.1 so different? This is the first part in a focused series of blogs targeted at breaking down the components of Red Hat Satellite to better understand the reasons why and how to transition successfully to the new and improved Satellite.
A brief history of Satellite:
Satellite 5 – Available since 2002 based on 2002 technology – Red Hat’s own upstream management solution called Spacewalk. Not flexible enough to adapt to today’s changed IT landscape
Satellite 6 – Available since 2014 based on 2014 technology. Much more flexibility and extensibility allowing it to adapt to today’s needs So what is Satellite 6? Version 6 is a major shift from version 5, and is completely re-architected and re-designed. Red Hat shifted focus in Satellite 6 to bring together best of breed components from upstream open source solutions.
So what does that give you? Let’s dive into a comparison of the features between Satellite 5 and 6
Architecture and Content / Lifecycle Management
Satellite 6 brings the full feature set into a much simpler and streamlined architecture in which services are federated and distributed into capsules. All management is done from the central Satellite server, allowing for centralized management while being able to place capsules strategically for systems management in hardened data center or cloud environments.
What makes content and lifecycle management so much better in Satellite 6 is its modular design. A big improvement over the content management strategy in previous versions of Satellite is the concept of “Content Views” and “Lifecycle Environments”. These are “snapshots” or point in time views to software repository content without cloning versions of software repeatedly. These Content Views, once published, “lock” in the content as of that date, giving administrators control over which versions are available to managed systems.
Lifecycle environments enable operations teams to “promote” particular content views into various environments in the organization (ie. Development, Q/A, Production, etc). In a few steps administrators can control precisely what software is available to their environments.
Many organizations struggle with keeping a consistent patch and content management strategy. Red Hat has made this much simpler in Satellite 6. Simply publish new content views and promote versions through your environments upon testing completion. As outlined above, newer versions of content have been published to the Dev and QA environments for testing before promotion to systems in the Production environment. Each content view is simply a snapshot, which doesn’t take up additional disk space to hold content (in contrast to version 5 which used channel clones).
Why Satellite 6.1 specifically? What’s new?
- OpenSCAP Integration for centralized security compliance reporting
- Customer Portal ISO downloads for offline sync
- Enhancements to subscription reporting
- Errata management for quickly applying urgent patches
- Capsule enhancements
- Discovery policy engine
- Advanced networking
- Docker image management
Let’s dive a little deeper into 2 specific features that Satellite 6.1 brings to operations teams.
OpenSCAP provides administrators with a toolkit to define a security baseline for their Linux environments, and routinely audit systems for compliance against these baselines. More info is available here. The OpenSCAP integration in Satellite 6.1 brings security and compliance management functionality to any systems managed by Satellite. Administrators can perform all patch/errata, configuration, provisioning, and security compliance management under a single pane of glass. We’ll dive much deeper into this in an upcoming focused blog on the OpenSCAP integration.
Flexible Errata Management
What happens when the next Heartbleed type vulnerability is discovered? How will you apply the right patches to all your systems in an emergency window? Satellite 6.1 brings much more flexible errata management into the fold. This enables sysadmins to manage content availability to their systems through content views and lifecycle environments. When an emergency patch is required, sysadmins can perform a “dot” release application of a content view by quickly adding the appropriate patch to a content view and push this out quickly to any affected systems.
So, in the example above where versions of content views are made available to systems in Lifecycle Environments (Prod = version 1, QA = version 2, and Dev = version 3), an emergency patch requirement doesn’t force admins to expose every other package to the systems. An OpenSSL patch to fix Heartbleed as an example would put content views in place as incremental “dot” releases (Prod = version1.1, QA = version 2.1, and Dev = version 3.1).
Take the First Step
As you can see there is a lot to the newest release of Red Hat Satellite and there is more to come! Satellite 6.2 brings even more features and enhancements to the solution and is now in limited beta.
Where are you in your journey to Satellite 6? Whether you are new to Satellite completely or struggling with transitioning to Satellite 6, Arctiq can help. Arctiq offers:
- Assessment and Audit
- Architecture and Design
- Customized Implementation
- Transition Services
- Next Steps Training – Beyond the Implementation
Want to see the software in action? Schedule a demo with Arctiq and/or join us for one of our upcoming events where we will be providing a live demo of Satellite.