Lab Questions | Linux Patch Management: Keeping Linux Systems Up To Date

The Red Hat exams are unique based on their reliance on labs and hands-on demonstrations. With these questions, you're practicing the skills you need on both Red Hat exams.

Lab 1

In this lab, you'll examine what happens when you update a kernel RPM by installing it side by side with an existing kernel. If a newer kernel is not available, the kernel-xen package, or even an older kernel, will serve the purpose for this lab. Just remember, if you don't want the kernel that you install during this lab, make sure to remove the package properly from your system.

Make a copy of your existing GRUB configuration file, /boot/grub/grub.conf. Print it out or copy it to your home directory.
Make a copy of the current file list in the /boot directory. One method uses the ls /boot > bootlist command, which writes the file list to the bootlist file.
If a newer kernel is available, and you're connected to the RHN or another appropriate repository, run the following command:
```
 # yum install kernel 
```
Alternatively, if you want to install the Xen-based kernel (which requires access to a Virtualization repository, through the RHN or an appropriate file in the /etc/yum.repos.d/ directory), you can run
```
 # yum install kernel-xen 
```
Another alternative is to download and install the RPM. Just be sure to use the -i switch to install the new kernel; otherwise, the command overwrites the existing kernel. (If you're installing an older kernel, you'll have to add the --force switch.)
Check the results in your GRUB configuration file, /boot/grub/grub.conf. Observe the differences versus the old GRUB configuration file, which you saved in step 1. What is the default kernel? If you happened to install an older kernel, is the default what you expected?
Check the results in your /boot directory. Observe the differences with the original list of files in the /boot directory.

Answers

This lab is somewhat self-explanatory and is intended to help you explore what happens when you properly install a new kernel RPM. As with other Linux distributions, when you install (and do not use upgrade mode) for a new kernel, two areas are affected.

The new kernel is added as a new option in the GRUB configuration menu. Unless you've installed an older kernel, the default boot option does not change. However, when you reboot, you'll be able to select the new kernel from the GRUB menu.

When you review the /boot directory, all of the previously installed boot files should be there. The new kernel RPM should add matching versions of all of the same files-with different revision numbers (unless it's a Xen-based kernel).

To keep this all straight, it helps if you made copies of the original versions of the GRUB configuration file and the file list in the /boot directory.

Lab 2

Generally, the only reason you need to install a kernel source RPM is if you absolutely need to recompile the kernel. Drivers can often be compiled using the kernel-devel package. However, if you need the source code, you may have to download it directly from the repository associated with your distribution. If you're running RHEL 5, that's available through your RHN subscription or ftp .redhat.com. If you're running Fedora Core, you'll need to activate the applicable source repository. If you're running a rebuild, you may need to download the kernel-versionnum.src.rpm directly from the repositories associated with that rebuild.

While "rebuilds" are supposed to use the same source code as Red Hat, there is no guarantee as such. I've run into trouble when mixing the source code released with different rebuild distributions. So it's best if you download the source code from the associated repositories.

Once you download the source RPM, you can install it with the rpm -ivh kernel-versionnum.src.rpm command, but that just starts the process of unpacking the source code. You'll need the rpmbuild command, available from the rpm-build RPM. You can then navigate to the /usr/src/redhat/SPECS directory, and use the rpmbuild -bb command to unpack the source code to different directories in the /usr/src/redhat/BUILD/ directory tree.

But wait, the kernel source code already seems to be in the /usr/src/kernels directory, in a subdirectory named for the kernel version. However, this source code is not complete; it's intended only for building drivers, and if you want to recompile a kernel, you still need to apply the rpmbuild -bb command to the kernel-2.6.spec file in the /usr/src/redhat/SPECS directory.

Answers

This lab can help you prepare for Chapter 8, where you'll recompile the Linux kernel. Red Hat no longer provides a binary RPM for the source code. The process for installing a kernel source code RPM is subtly different from other source code RPMs, as it loads the source code into unique directories.

Lab 3

This lab may not be possible unless updates are available from your repository or the RHN. In this lab, you'll examine what happens when you run an update to upgrade to newer versions of packages available for new features, to address security issues, and more. Before you start, run the following command to clear the cache, so you get the full set of messages:

 # yum clean all

Run the following command to send the messages to a text file:

 # yum update > update.txt

If a lot of updates are available, this process may take some time. If you want to watch, you can run the following command:

 # tail -f update.txt

If you want to download and install the updates, use the -y switch, which answers "yes" to all prompts. The complete command becomes

 # yum update -y > update.txt

After the download and installation is complete, review the update.txt file. Note the first messages, how plug-ins are installed from the /etc/yum/pluginconf.d/ directory. Note how it loads information from the repositories, downloads headers, and resolves dependencies.

Once dependencies are resolved, examine where the downloads come from. Note how some packages are installed and how others are updated.

Answers

This lab is intended to help you examine what the yum update command can do. It's the essential front end to other update tools, namely Pup. As you can see from the update.txt file created in this lab, the messages show you how yum looks for all newer packages from configured repositories or the RHN, downloads their headers, and uses them to check for dependencies that also need to be downloaded and installed.

Lab 4

In this lab, you'll get a chance to use the configuration for your current system to kickstart an installation of a second system. Ideally, you'll have a VMware or Xen virtual machine available for the process, with an identical amount of free space and hardware as the current system. Otherwise, this lab may not work.

Open the anaconda-ks.cfg file in the current installation of RHEL. Remove the comments as appropriate from the directives associated with partitions and filesystems. Configure an installation boot CD or USB key, depending on what you can boot from your system. Copy the revised kickstart file to ks.cfg, and write it to appropriate media, even a floppy drive if available.

Make sure the same source you used for the original installation (network, hard drive, CD/DVD) is still available. Boot the new system to test the installation.

Answers

For a lab like this, it's critical that you have a second system in which you don't mind losing all data. VMware and Xen are excellent options for this purpose. If successful, the kickstart installation you create and run will erase all data on that second system (unless specially configured). If space is limited, you can certainly delete the virtual machine files associated with this second system after installation.