Patches:
In this fast competitive world, everyone is trying to compete with others whether it’s humans or machines. Everyone wants to be fast and one step ahead of others. So, in order to keep pace with the ever-changing technology, you need to keep yourself updated which requires basic training. Also, persevering will make you better day by day.
Patch/Version/Update: Lingo of Patching?
Let’s take an example of your smartphone. Everyone nowadays is using smartphones whether it’s Android or IOS. They release updates yearly which provides new features. Android names their releases after sweets like Pie, Kitkat, etc. This makes quite an interesting tradition whenever a new version comes out.
With each release, the update makes you love your phone and spend some more time with it. But some updates may slow your phone or drain your battery faster. To overcome the drawbacks, android releases monthly patches as a fix which makes it run better. And with each updated patch there exists a version number that identifies it.
Same goes with the other OS’s as well. Whether it’s Windows, Linux, or Mac all require updates. To stay relevant in the market and to compete with each other they update their OS monthly in the form of patches. A patch encapsulates all the securities patches according to the industrial standards, kernel (heart of Linux) patches, minor changes that are done to cover up all the vulnerabilities given by CVEs.
How often Patching has to be done?
Any changes in production or running environment always require testing. In a large enterprise environment, it’s possible for new updates to be available every day, which means constant testing and deployment.
Practice should be to first, deploy and then test in a staging environment. Staging environments should be a replica of production to ensure that it’s a 1:1 match during testing otherwise there could be errors that cause downtime in production. Even though testing is important, a good rule of thumb is to apply patches within 30 days of vendors making them available.
Primary Tools before jumping into it:
Yum: Sounds like encouraging a baby to eat. yummy yummy !!! But, obviously, that is not the case. YUM here stands for Yellowdog Updater, Modified. YUM is the most powerful tool in the Linux world which is used for getting, installing, deleting, querying, and managing Red Hat Enterprise Linux RPM software packages from official Red Hat software repositories, as well as other third-party repositories.
It encapsulates various informational tools. It can list rpm’s both installed and available for installation, extract and publish information from the rpm headers based on keywords or globs, and find packages that provide particular files.
APT (Advanced Package Tool) brother from another mother. It’s the same as yum but used for different OS Ubuntu. It’s a command-line tool to interact with this packaging system. There are already dpkg commands to manage it, but apt is a more user-friendly way to handle packages. You can use it to find and install new packages, upgrade packages, clean your packages, etc.
Homebrew “The missing package manager for macOS” this one is a fruit; no it’s for an Apple OS. Same working updating, installing, deleting, querying, and managing packages but for Apple macOS. All sorts of packages and libraries you can download, it installs software that you can use whenever you want. Most of these commands will install CLI packages that allow you to execute specific tasks for specific technologies within your terminal.
Let’s Begin our Journey :
I have started my Linux journey by studying yum. Believe me, it is not as easy as it sounds. I started my career as a network/Linux administrator where I used to take care of software running production high-end applications which need better and non-vulnerable systems. Generally, we do have CentOS machines as well. As we move ahead, I will also share my ample experience working with production systems in the following posts about patching.
BIG 4s to remember:
- Taking approvals from Applications Owners: Making an update in System running applications always require prior approval from the developers. So they can monitor their applications at their end.
- Basic understanding of Application running on System: Application up and running is our desired goal. So going straight forward without precautions can be disastrous. Therefore, prior basic knowledge is required for the application side as well.
- Downtime if required for systems: Some application requires zero down-time. Hence, they can’t be taken down. This is where we move application traffic to DR while patching.
- Rollback procedure: The patching history is shown in yum history. From there it can be restored to any point. But restoring to any point is not risk-free which is why it is not recommended by Red-hat. Needless to say, it is an option.
And that’s it – Welcome to the world of Patching. Wait for the next blog where we will go through Elasticsearch, Kafka, and Aerospike patching which will help in applying patches without downtime.
Linux Thought of Day: Patching is a weapon for mass Destruction
Blog Pundit: Kapendra Singh and Sanjeev Pandey
Opstree is an End to End DevOps solution provider