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

1. 

In this exercise, you are going to experiment with two ways of managing services at different runlevels: the chkconfig command and the system-config-services utility, also known as the Service Configuration utility. The commands in this lab don't start or stop scripts immediately, just the next time you move your Linux system into runlevel 3.

  1. Open the GUI. From a text command line interface, run the system-config-services & command. This allows you to use the same terminal window for other commands. Alternatively, in the GNOME desktop, choose System | Administration | Server Settings | Services.

  2. The Service Configuration utility is a graphical tool for controlling the services that Linux starts and stops at each runlevel.

  3. These next steps assume that the NFS service, as controlled by the /etc/init.d/nfs script, is already running and installed. If not, pick another service to add and remove (it does not matter which as long as you restore the original condition when you're done).

  4. At the command line, run the ls /etc/rc3.d/*nfs command to find the priority number.

  5. Remove the NFS service from runlevel 3 using the Service Configuration utility.

  6. Switch back to the command line window and run the chkconfig --list nfs command to see if it has been deactivated in runlevel 3.

  7. Restore the nfs start script with the following command:

    # chkconfig --level 3 nfs on

  8. Switch back to the console window and run the chkconfig --list nfs command to verify that the NFS service is activated.

  9. Return to the Service Configuration utility, and choose View | Refresh Service List to confirm that nfs is once again active in runlevel 3.

  10. Although the Red Hat Service Configuration utility provides a nice graphical interface, the chkconfig command is faster and more reliable, especially since X (also known imprecisely as the GUI) is not always available in an emergency or through remote login.

Answers

1. 

  1. To open a command line interface in the default Red Hat GNOME desktop, choose Applications | Accessories | Terminal.

  2. In the new terminal, open the Service Configuration utility. Run the applicable graphical tool in the background so you can still use this terminal window with the following command:

    # system-config-services &

  3. Run the ls /etc/rc3.d command. Look for the nfs start script and record the current order number, 60. If you see only a kill script for nfs, it is not active in runlevel 3. If you don't see it at all, you need to install the nfs-utils RPM.

  4. Deactivate the nfs service from runlevel 3. It's easy to do so in the Service Configuration utility. But you need to remember to save your changes by choosing File | Save Changes.

  5. Switch back to the console window and run chkconfig to see if it has been deactivated in runlevel 3. If it has, you should see the following result:

    # chkconfig --list nfs nfs 0:off 1:off 2:off 3:off 4:on 5:on 6:off

  6. Now run the chkconfig command to reactivate the nfs service. Return to the Service Configuration utility. Add the nfs service back to runlevel 3 with the following command:

    # chkconfig --level 3 nfs on

  7. Now run the following chkconfig command to verify that nfs is active again in runlevel 3:

    # chkconfig --list nfs nfs 0:off 1:off 2:off 3:on 4:on 5:on 6:off

    This should show that the nfs service is started in runlevel 3. You practice using the chkconfig command. One way is to redo this lab. Use the service of your choice. Make sure what you see in the GUI Service Configuration utility matches. After each change with the chkconfig command, run the View | Refresh Service List command to make sure the GUI tool reflects your change.

Lab 2

2. 

In this lab, you'll move the GRUB configuration file and examine its effects on the boot process.

  1. Boot into Linux, and print out the contents of the GRUB configuration file.

  2. Move the GRUB configuration file, /boot/grub/grub.conf, to the administrative home directory. One way to do this is with the following command:

    # mv /boot/grub/grub.conf /root

  3. Reboot your system. When you do, you should see the following entry:

    [Minimal BASH-like line editing is supported. For the first word, TAB lists possible command completions. Anywhere else, TAB lists the possible completions of a device/filename.] grub>

  4. Refer to the printout of the GRUB configuration file. Select the stanza that you want to boot. Enter the first command at the GRUB command line. The command should be something like:

    grub> root (hd0,0)

    If successful, you'll see output similar to:

    Filesystem type is ext2fs, partition type 0x83

    If you've configured the ext3 filesystem, this output is still correct.

  5. Enter the kernel command directive. Leave out the second part of the directive that refers to the root directory.

  6. Enter the second part of the directive with the root command reference. What happens?

  7. Try the second GRUB configuration line again, this time entering the whole kernel command directive. If successful, you'll see output similar to:

    [Linux-bzImage, setup=0x1e00, size=0x16eb71]

  8. Enter the final GRUB configuration line associated with the Initial RAM disk. If successful, you'll see output similar to:

    [Linux-initrd, setup=0x10d44000, 0x19b13c bytes]

  9. Now you should be ready to start Linux with the following command at the grub> prompt:

    grub> boot

  10. Don't forget to restore the GRUB configuration file. If you followed the instructions earlier in this lab, you can do so with the following command:

    # mv /root/grub.conf /boot/grub/

Answers

2. 

This lab should be somewhat self-explanatory. It examines what happens when a configuration file related to the boot process is missing. You'll see more examples of this in Chapter 16.

While it's an excellent idea to experiment with other key configuration files, don't do so haphazardly. Remember to back up your configuration. And if you want to rescue your system, you may need to learn how to use linux rescue mode as discussed in Chapter 16.

However, if you want to experiment with other key configuration files, back up /etc/fstab. You can change it and even move it from the /etc/ directory, in the manner described with the GRUB and /etc/inittab configuration files in this chapter. If /etc/fstab is missing, it looks like everything still works. RHEL 5 even boots into the GUI. However, the problems you'll see are subtle. No filesystem is mounted. However, you can still restore the fstab file from backup. You'll learn about mounts and /etc/fstab in more detail in Chapter 4.

Lab 3

3. 

In this lab, you'll see what happens without the init service. As you did in Lab 2, you'll move a key file, in this case, /etc/inittab, to the root user's home directory, and then reboot your system.

  1. Move your /etc/inittab configuration file to the root user home directory. You can do so with a command such as:

    # mv /etc/inittab /root/

  2. Reboot your system. Observe the messages carefully. Note that RHEL 5 is very specific when the /etc/inittab file is not where expected.

    INIT: No inittab file found Enter runlevel:

  3. At the prompt, enter runlevel 5. See what happens. You'll see messages similar to:

    INIT: Entering runlevel: 5 INIT: no more processes left in this runlevel

  4. Because the system stops at this point, you'll have to cycle power on your system. Try any of the other standard runlevels. You'll see the same results even in runlevels 0 and 6. Remember to cycle power after entering each standard runlevel.

  5. Try the emergency runlevel; enter the emergency command at the Enter runlevel: prompt. See what happens.

  6. Finally, try the single runlevel with the s command at the Enter runlevel: prompt. What do you see?

  7. At the prompt, you'll be in the top level root directory. Try restoring the /etc/inittab file from the root user's home directory. The easiest way is with the following command:

    # mv /root/inittab /etc/

    But this command doesn't work. You'll see a message like:

    mv: cannot move '/root/inittab' to '/etc/inittab': Read-only file system

  8. Now you'll have to remount the top-level root directory, using a command you'll learn more about in Chapter 4. But first, before you know what you're remounting, you need to confirm the partition where the root directory is mounted, from the contents of /etc/fstab.

    In my particular configuration, a cat /etc/fstab confirms the root directory mounted on a logical volume, /dev/VolGroup00/LogVol00.

    Based on that data, I can remount with the following command:

    # mount -o remount /dev/VolGroup00/LogVol00 /

    Substitute accordingly, based on the output from your /etc/fstab configuration file.

  9. Now try restoring the inittab file again:

    # mv /root/inittab /etc/

    You should now be successful. You can now run the reboot command to restart your system.

Answers

3. 

One of the required skills in the Red Hat Exam Prep guide is booting into different runlevels. This lab sets up a scenario in which you need to learn how to boot into a specialized runlevel, s, also known as single-user mode. If you want to learn more, try the init=/bin/sh runlevel, and see what you need to do to restore the /etc/inittab file.

Related

Категории