Any system administrator managing a growing number of servers will eventually run into this puzzle at some point. Managing multiple servers and ensuring their stability while keeping them updated can often prove quite the challenge.
Common issues you might face are:
- How do you ensure that the software updates and patches remain correct across various servers in different lifecycle environments?
- How do you ensure that the software installed in a production environment won’t surpass the version running in a test environment?
- How do you enable rollout of new updates and security patches to systems that need to be segmented away from the Internet?
Real scenario
A typical IT environment may consist of perhaps three different lifecycle stages, often labelled as ‘Development’, ‘Testing’ and ‘Production’. The production environment must remain stable so before you update these servers you may decide to install a new version of the package in testing during the first week and production two weeks after.
Great, but what happens if the package maintainer releases a new version of the software during this period? You would run a risk of installing a newer version of that update in production than the one currently running in test.
And what if it is not one update, but 80+ new ones? You want to make sure that you get exactly the same versions as the ones running in test.
Don’t re-invent the wheel
Some system administrators like to re-invent this wheel and they will come up with all sorts of solutions – like automated scripts that will generate lists that need to be crosschecked later.
Even worse, if the system is sensitive to the point of not being allowed access to the Internet, you would have to find a different way to upload those packages to the server. Ideally you shouldn’t have to open up a multitude of service ports between separated networks just to do this.
All of this can quickly become a real hassle, not to mention a security issue.
Our option
We run a lot of different servers with different purposes across varying life-cycle environments. We needed some kind of a systems management platform that would allow us to keep package versions in line while also providing updates to those servers that are walled off from the Internet.
I’m sure there are many strong contenders out there depending on your Linux distro and all.
Being that we mainly run Red Hat Enterprise Linux we decided to go with Red Hat Satellite.
How do we use Red Hat Satellite?
Here are some of the features that I find most useful with their platform.
Life-cycle Environments
Red Hat Satellite allows us to define multiple life-cycle environments and promote new sets of updates to the servers when we choose to.
This is possible because the platform uses something known as a ‘Content Views’. The content views hold information about what versions of software need to be deployed to the servers along with information about which life-cycle environment is supposed to receive it.
We can effectively schedule different sets of software updates at a time of our choosing.
Centralized control of repositories
We are not just limited to Red Hat’s official repositories. Maybe a customer is running 3rd-party applications that are installed from a public repository. We can easily add this external repository to our Red Hat Satellite platform and have the client server get their future updates from within our network. This gives us full control over which packages the server receives, ensuring greater stability across life-cycle environments.
You can even use it to push out your in-house scripts, packages, and software in a controlled setting.
Scalability
The platform provides us with a scalable way to deploy new update servers known as ‘Capsules’ in our network. Capsules are the servers from which the client servers get their updates. All this without the client servers ever having to go online for their updates.
Capsules can be deployed anywhere needed. If our network expands, we can deploy new capsules in different subnets, regions or countries, ensuring faster delivery of packaged content.
Not only does this reduce bandwidth consumption and network congestion. It also provides us with the means of segmenting away any servers that should not be directly connected to the Internet while still allowing them to get the latest security patches.
Subscription overview
Red Hat Satellite also provides a convenient way for us to monitor how many licenses the servers are using. As soon as a server is registered to the Red Hat Satellite platform, it will show up in the web-based dashboard along with information about what products (software) is installed. Subscriptions can be managed in the Red Hat Portal and then uploaded as a manifest to the Red Hat Satellite server which is very convenient.
Finally
Controlling the versions of Linux updates and patches can be very time-consuming when it really should be simple.
Red Hat Satellite offers us a way to keep track of all the software versions that gets installed on the servers. We do not have to worry about which version of python or MySQL runs on what server because we know. The platform enables us to verify that the right servers have received the correct version of updates.
Servers receiving updates never have to leave the internal network and whether you prefer a push or pull method of installing packages, Red Hat Satellite provides both.
In addition to the web-based GUI, the product also features a REST API along with a CLI tool called ‘hammer’. This allows for the automation of many different aspects of the platform which will likely save you even more time.
No need to re-invent the update wheel.
