Preparing for applying updates on Red Hat Linux

Contents
1. Objective
2. Operating System and Software Versions
3. Requirements
four. Difficulty
five. Conventions
6. Introduction
7. Update manner
eight. Disk space
8.1. Yum cache
eight.2. Clearing the cache
8.3. Moving the cache
9. Network errors
10. Yum dry run
eleven. Conclusion
Objective
Our objective is to make certain that updating the running device will run smoothly and without mistakes.
Operating System and Software Versions
Operating machine: Red Hat Enterprise Linux 6+
Requirements
Privileged get entry to to the systems
Difficulty
EASY
Conventions
# - requires given linux instructions to be performed with root privileges both immediately as a root user or by way of use of sudo command
$ - given linux commands to be accomplished as a ordinary non-privileged consumer
Introduction
Keeping the system up to date is an each day challenge for a sysadmin, as well as a computer person. By applying the brand new (strong) available software program on the gadget we are able to take gain of the trendy capabilities, and might be greater included from safety troubles and with any luck suffer less from bugs. To update the gadget you may want configured yum repositories that act because the supply of the up to date software.

If you take a seat subsequent to the device this is running the working device to be updated, you may effortlessly act if something is going wrong at some stage in replace, like checking the output at the terminal, or boot to a live system if the upgraded one does now not go back from reboot - but this isn't continually the case. Think of a datacenter with hundreds or hundreds of (digital) machines, or certainly a bodily PC that you have to improve remotely.

There are simple steps we are able to perform to prepare the device for upgrade, and likely clean any trouble that would endanger a successful replace.


Update system
When appearing an unconditional replace (that means "replace all"), yum will fetch all metadata from the to be had repositories, and calculate all applications to be upgraded against the rpm database that includes all the metadata about packages installed on the device. 

The replace process additionally calculates all dependencies of the upgraded packages, might also update antique programs, and do away with vintage kernel pics in step with its configuration. The number of kernel snap shots to preserve is set within the /etc/yum.Conf configuration file, and is 3 through default:
installonly_limit=3
After all the wanted modifications calculated, yum gives an intensive list of all of the packages to be upgraded, removed, or set up for dependencies, the same way it does when putting in or upgrading specific applications.

In an interactive update session yum will offer a summary of the packages to be changed, as well as calculation on the scale of records need to be downloaded for the upgrade as shown underneath:

Summary of interactive yum update
Summary of interactive yum replace


After inspecting the effects, we can decide if we begin the update, or cancel it. As yum will update everything it could discover updates for, we may need to eliminate unneeded programs in advance. We may notice a bundle marked for replace that we're version-locked with that need to be excluded from the upgrade.

After approval yum will download all new applications, and installation/replace them one at a time. When completed, it'll take a look at the integrity of the established/up to date applications, easy up unneeded files. It also provides remarks in the course of the manner, providing a line of textual content for each step, in addition to an go out code that recommendations if the improve changed into a hit, or if a few hassle arose. It will even cancel the replace procedure if a problem rises that seems vital from the steady system attitude - but there are instances when it's far too late already, so preventing update issues from taking place is a better technique.
Disk area
yum cache
From the technique described above we may want to guess that we need some disk area for the replace manner:
The metadata of all configured repositories want to be saved till the calculation of all applications (and their dependencies) to be updated finishes.
Rpm packages that represent the replace itself want to be stored domestically till hooked up well.
This facts, called yum cache is handiest wished all through the replace, but can soak up large disk space. The default place for this cache is within the /var/cache/yum directory. Needless to mention that if there is not sufficient area to shop all information wanted, the replace system will fail. Some unfinished downloads might be dropped, but now not all space can be freed, which ends up having a system failed the update and feature it's extent containing /var/cache nearly complete. 

Many installations store their /var directory on a quantity dedicated to logging, because the default vicinity for logfiles is /var/log on maximum distros, and most well-behaving applications will stop operating or even crash if they cannot write their logfiles. So filling up the quantity they are writing to is a terrible component. 

The extra applications need to be upgraded, and the extra repositories we have, the extra space the update will occupy brief. To calculate this area from update to update is tough, however can be tested with the dry run solution defined later if we've a check gadget with the exact software content. For a actual time instance, updating from RHEL 7.1 to 7.Five (computing device set up with Gnome) may take up 4 GB of cache area, however set up of some fixes to a device this is most effective one or  months obsolete will take up only some MB.

To take a look at how a great deal space we have, we are able to use the df command:

# df -h /var/
Filesystem              Size  Used Avail Use% Mounted on
/dev/mapper/vg_sys-var  6.0G  1.7G  four.4G  28% /var
In the above example we have four.Four GB of loose area, as a way to be sufficient for the reason that the server become up to date just a few months ago. To loose up space a trivial step would be to clear the yum cache already stored (perhaps at the ultimate update). To test how a lot area the a cache occupies for the time being, we can use du:

# du -mcd 1 /var/cache/yum
1103    /var/cache/yum/x86_64
1103    /var/cache/yum
1103    total
The above numbers are in MB, so the yum cache in this situation takes up about 1 GB of disk space and occupies maximum of the distance on the /var quantity.


Clearing the cache
We can clean the complete cache with the subsequent command:
yum smooth all
But as yum notifies us inside the above command's output on RHEL 7 variations, there may be orphaned facts from eliminated or disabled repositories, so as to maximum in all likelihood occur after minor launch ugrades, wherein case we can correctly clean the records via hand:
rm -rf /var/cache/yum/*
We may get extra area for the update by means of clearing other data saved at the volume, like compressing/deleting antique logfiles, transferring big documents to other volumes, or extending the extent size.
Moving the cache
To paintings on with the opportunities of yum, if we're in reality low on disk area, can not clean whatever in addition, and cannot add more area to the quantity, we will pass the location of the yum cache to every other quantity with greater free area. We can configure the cache location within the yum.Conf configuration document stated above. Consider the default putting:
cachedir=/var/cache/yum/$basearch/$releasever
By converting the course earlier than $basearch the subsequent yum operation will work with the identical listing structure, however on a exclusive course - hopefully with extra loose area for the improve. We also can circulate the cache to any other quantity by using moving the entire listing:
mv /var/cache/yum /extended_data_volume/
And developing a symlink at the original place that factors to the brand new region:
ln -s /extended_data_volume/yum /var/cache/yum
It is wise to realize that the replace will now not fail on a trivial blunders together with low disk area. On a large device sysadmins set up tracking gear like Nagios which can document low disk space on all machines, making this step much much less time eating and blunders prone.
Network mistakes
If there are troubles with connectivity among the repositories and the machine performing the replace, the update may additionally fail. This can best appear on the metadata, or the new rpms down load stage, and will not damage the machine. You can start the update procedure once more when the network problem is solved. 

On the alternative hand, if the replace is initialized from an interactive session, on community outage the relationship may also smash, leaving the updating system with out admin to answer the questions yum may ask. If the package install/replace degree already started, it will keep unattended, and might fail or whole if it would otherwise do. After reconnection the manner can be accompanied in the /var/log/yum.Log.


Yum dry run
Aside insufficient disk area and community problems, the update in lots of cases can fail on unresolved package dependencies. These want to be solved with tools which could calculate and manage package dependencies, however it would be useful to realize there might be problems earlier than the actual update (and consequently not wasting the constantly too short downtime of the machine). To get this valuable statistics we can run the replace method as it might run the real update, however forestall earlier than any real package downloading, installing or updating have taken vicinity.

Around Redhat 6.6 a new choice became added with the intention to motive yum to count on "No" to each question that comes up throughout update - including the approval before the actual package manipulation level, and as a result no actual interplay is needed execute a dry run:
yum update --assumeno
This may be the right device to offer a dry run of the coming update, such as packages to be upgraded, and any errors what may also occur. Consider the subsequent simple bash script:

#!/bin/bash
yum update --assumeno &> $(hostname).Yum.Dryrun.$(date '+%Y-%m-%d').Out
go out $?
The above script may be carried out automatically and will offer a text file of the dry run, as well as an normal go out code indicating any issues. The output does not want to be stored on the local report gadget. The goal of the output redirection can be a network record device, or the report can be published to a few imperative reporting server, can be amassed by means of different scripts or packages. The reviews can be published and dispensed among different IT departments for approval, this manner anybody worried can see precisely what packages could be updated, and to what version.

The dry run can be scheduled to run on a given time frame (perhaps at night time to effect the system's overall performance much less) with cron, or done from a primary supply with a puppet setup. The exit code also can be stored and processed via tracking or facter, to mixture the viable effects of the imminent upgrade before intending.