Share This Article
One of the most tedious, painful tasks that IT admins deal with is patching. It’s time consuming and fraught with risk. You have to know that your servers won’t have a conflict and the patch will take properly, on top of knowing what servers need to be patched and how. Plus, you have to have access to all of those servers. Writing a script to update and patch all of your servers is painful if you have a large network. The actual patching command isn’t painful, it’s all of the plumbing that you need around it that is a chore.
JumpCloud® makes quick work of running scheduled patching, ad hoc patching (like Heartbleed), or patching only specific packages. To show you how easy it is, we wanted to go through a few quick examples.
Regularly Scheduled Patching of all Servers
As a first scenario, let’s say that you want to update all of your servers monthly. Let’s pick the 15th of each month at 2am to be your patch schedule. I realize that you might shoot for only weekends, but we’ll just keep it simple for this example. There are only a couple of steps needed with JumpCloud to execute on this task.
- Ensure that the JumpCloud agent is on all of your servers.
- Create a script to update each Linux and Windows server (we’ll use CentOS Linux as an example for Linux)
a. CentOS Linux: yum -y update
b. Windows: wuauclt.exe /detectnow - Set your schedule for the 15th of every month at 2am.
On Windows, your update policy will need to be configured to apply updates immediately.
That’s it, you’re done! This task is now registered in JumpCloud to update all of your servers monthly. It’s lot quicker than writing a script, tracking down every server, and making sure that you have access. On top of that, JumpCloud will automatically log if there are any failures.
In a future post, we’ll dive down into even more granularity where you can decide to patch specific components.
Ad hoc patching
For our second scenario, let’s assume that a zero day vulnerability has just been released and there is a patch to it. In this case, we’ll assume that it is for Apache Web servers. You’ll want to just target the update to those servers. Luckily you have already created a JumpCloud group for all of your Apache servers. In this scenario, you already know that all of your Apache servers have JumpCloud installed on them. Here’s what we need to do:
- If you’re on AWS, you can use the following command to create a snapshot of your EBS volume (assuming it’s not your root volume):
ec2-create-snapshot volume_id -d “Backup prior to Apache update”
- Write script to update Apache Web server vulnerability (again, using CentOS as an example):
yum -y update httpd
- Assign this task to the Apache Web server JumpCloud tag.
- Set this to run at midnight.
All complete. You can check the stdout exit codes in the morning to make sure that everything ran properly.
Patching servers doesn’t need to be painful for admins. With JumpCloud’s infrastructure in place, you can set your regular patching schedule easily or run updates ad hoc in just a few minutes. You’ll automate the process and have full visibility into what executed properly and what didn’t. If you’d like to learn more about our patching capabilities, just drop us a line. We’d be happy to help.
