Lab Questions | RCHE Red Hat Certified Engineer Linux Study Guide[c] Exam (Rh302)

< Day Day Up >

If you're pressed for time with these labs, I suggest that you run Lab 3 first. As you've read in the chapter, recompiling the kernel takes a long time. If you have a slower computer, some of the commands required to recompile the kernel take a while to complete. You can use this time to log into a different terminal and run the other labs in this chapter.

Lab 1

In this first lab, we'll look at setting up automatic connections to a shared network directory. While this lab uses files described in Chapter 4, it is focused on shell configuration files. For the purpose of this lab, assume your username is vaclav and you're mounting a shared NFS /mnt/inst directory from a remote computer with an IP address of 192.168.30.4. You're going to mount it in vaclav's home directory, in a blank directory named inst.

Select the regular user of your choice. That user should have files such as .bashrc and .bash_logout.
Find a shared directory on a remote computer.
Set up a local directory for that user as a mount point.
Configure commands for that user to mount and umount that remote directory. Make sure those commands run only when that user logs into his or her account.

Answers

This lab has two purposes: it is designed to help you understand mounted network directories and the login process. You can substitute the user, the shared network directory, and directories of your choice. But based on the premises in this lab, I would take the following steps:

Log in as user vaclav. Create the specified directory. For this lab, you would use the mkdir /home/vaclav/inst command.
Test the network connection. Mount the remote NFS directory on the directory that you just created. For this lab, use the following command:
```
# mount -t nfs 192.168.30.4:/mnt/inst /home/vaclav/inst
```
Run the mount command by itself. If you've successfully mounted to the shared directory, you should see it at the end of the list of mounted directories.
Unmount the network connection. For this lab, you would use the following command:
```
# umount /home/vaclav/inst
```
Add the commands specified from steps 2 and 4 to the local .bashrc and .bash_logout configuration files. Remember, since these files start with a dot, they are hidden.
Test the result. Log out and log back in. Check your mounted directories. If the command in .bash_logout does not work, you'll probably see the shared directory mounted multiple times.

Lab 2

In this lab, we will test the quotas created in this chapter. You'll use the basic quota settings described in this chapter, and then copy files to fill up the home directory of a user who has a quota applied. The steps required for this lab are straightforward.

Set up quotas on the local computer. Use the criteria described earlier in this chapter. If you don't have a separate /home directory partition, you can set up quotas on the top-level root directory (/).
Once you've set quotas in your /etc/fstab configuration file, remember to remount the partition where you've created a quota. Alternatively, you could reboot Linux, but that would take time that you may not be able to spare during either of the Red Hat exams.
Set up a quota for the user of your choice. Remember, when you use the edquota command on a specific user, you can edit the quota file directly using vi editor commands. Configure a hard and a soft limit for that user.
Log in as the user with the quota. Copy some large files to the home directory of that user.
Continue the copying process until you see a warning message. When you do, run the quota command. What do you see? Is there anything in the output that gives you warning that you've exceeded the quota?
Copy some additional files until you see a 'Disk quota exceeded' message. Run the quota command again. What do you see?
Delete some files from that user's home directory-at least enough to get the files under the quota limits.

Answers

The purpose of this lab is to get you some more practice with creating quotas for users. It's quite possible that you'll have to configure quotas on the Red Hat exams. While you may not have to test quotas in the way described in this lab, it will help you become familiar with the error messages that you'll see when you exceed a hard and then a soft quota limit.

Lab 3

This lab is more of a detailed kernel-building exercise than a typical lab in this book. The exercise will include concise steps on how to configure, install, and test a new kernel. While the Red Hat Exam Prep guide no longer specifies that you have to know how to recompile the kernel, it is something you will need to do at some point in time as a Linux system administrator. See the Lab Answer section at the end of this chapter for the exercise.

Answers

Before we can build a new kernel, we have to ensure we have all the correct RPM packages. You could do so by checking a list of RPMs as described. Alternatively, you can start the Package Management utility with the redhat-config-packages command. From this GUI utility, make sure you have the Kernel Development package group installed. As with the rest of this chapter and the Red Hat exams, this assumes that you have a PC with a 32-bit Intel type CPU. The procedures for other CPUs vary and are not, as of this writing, covered on the Red Hat exams.

The following list of RPMs are associated with the source code:

kernel-source-* glibc-kernelheaders-* glibc-devel-* cpp-* ncurses-* ncurses-devel-* binutils-* gcc-*

When you install RHEL 3, you've probably already installed most of these packages. Alternatively, it may be faster to install the Kernel Development package group using the Package Management utility. This utility automatically takes care of any dependencies.
Navigate to the /usr/src directory with the cd /usr/src command. Run the ls -l command. You should see a link between the linux-2.4 directory and the location of your source code files. In RHEL, that is by default the /usr/src/linux-2.4.21-4.EL directory.
Navigate to the /usr/src/linux-2.4 directory. You'll be running the remaining kernel configuration commands from this directory.
Set up a unique name for the kernel that you're about to modify. Open the Makefile file in a text editor. Look for the EXTRAVERSION variable. Red Hat adds this variable as a suffix to the recompiled kernel. Modify this variable as desired; save and exit from Makefile.
Jot down the value of the EXTRAVERSION variable here: ______________
Determine the correct CPU on your hardware. Use the command
```
# cat /proc/cpuinfo
```
Jot down the CPU model name here: ________________
Run the ls /usr/src/linux-2.4/configs command. You'll see a list of available default kernel configuration files. Find the file associated with your CPU. If your computer has more than one CPU, use the smp version of the kernel, if available. If your computer has more than 4 GB of RAM, use the hugemem version of the kernel, if available. Save it in the /usr/src/linux-2.4/.config file.
Make sure you're in the /usr/src/linux-2.4 directory. Clean up any stray source code from previous kernel reconfigurations with the following command:
```
# make mrproper 
```
Wait until the messages are complete. Problems are rare at this stage.
Next, it is time to configure your kernel, using one of the three major tools:
- make config A line-by-line tool that gives you a choice with all kernel options
- make menuconfig A text-based menu that allows you to select just the changes you want
- make xconfig A GUI interface that works only in the X Window System
Set the processor type to match your hardware (for example, Pentium, Pentium II, Pentium III, Pentium IV).
Return to the kernel configuration tool of your choice. Turn off all unneeded devices. Some possible unneeded devices are in the following categories:
- ISDN Subsystem
- I2O
- Old CD-ROMs
- Amateur Radio
- Telephony Support
- Symmetric Multiprocessing Support
- MTR Memory Support
Be sure to turn on Kernel Loadable Modules support.
Save your changes and exit.
When you save the new configuration, the kernel configuration tool overwrites your /usr/src/linux-2.4/.config file.
Resolve all kernel dependencies (between sources) with the following command. This will produce a lot of output and may take several minutes.
```
# make dep
```
Prepare the source code directories to create the new kernel with the following command:
```
# make clean
```
Once your dependencies are resolved, it's time to build a new compressed kernel image, with the following command:
```
 # make bzImage
```
This is the actual kernel build, which will take some time. You may take this opportunity to log into another terminal and run one of the other labs.
The easiest way to see if the kernel build worked is to run the following command immediately after the messages from make bzImage command stop:
```
# echo $? 0 
```
If you got a 0, everything worked (success). Any other result indicates a failure during the kernel build process. In that case, go back and reconfigure your kernel to make a configuration that works.
Check for the existence of two new files. Run this command:
```
# ls -l System.map arch/i386/boot/bzImage
```
It should show you two files, a relatively small System.map and a much larger bzImage.
Make the loadable modules that will be used by this kernel:
```
# make modules
```
Install the new custom kernel files into their correct locations and update your boot loader so that it knows about your new kernel. The make install command should perform all of these tasks.
Check to see that the make install command worked. Based on the EXTRAVERSION variable that you set earlier, check your /boot directory. You should see at least a new initrd, System.map, and vmlinuz file in this directory, with this variable as a suffix. Otherwise, you'll need to copy these files yourself. Also, check your boot loader configuration file (/etc/grub.conf for the default GRUB boot loader).
If the make install command didn't put an initial RAM disk (initrd) into the /boot directory, you'll have to create one with the following command (if your version and EXTRAVERSION variables are different, revise this command accordingly):
```
# mkinitrd /boot/initrd-2.4.21-4.ELcustom1 2.4.21-4.ELcustom1
```
Congratulations, you have just installed a custom kernel on your new system. As long as you also have your original kernel in your boot loader menu, test it out!
Run the reboot command. You should see both kernels in the boot loader menu. Try your custom kernel!

Lab 4

In this fourth lab, you'll be updating your kernel from another source. One proviso-this lab will work only if there is a Red Hat RPM kernel file that is a later version from what is already installed on your computer. If you're running RHEL 3, you can still download and use one of the Fedora development kernel RPMs for the purpose of this exercise. (While there are no guarantees, the Fedora development kernel available as of this writing works fine on my RHEL 3 computer. However, there have been reported issues with various video cards and printer configurations.)

Check download.fedora.redhat.com or one of the mirrors listed online at fedora.redhat.com/download/mirrors.html.
Download the new kernel to the /tmp directory.
Back up your current /etc/grub.conf configuration file, as well as the current files in your boot directory, in case something goes wrong.
Use the rpm -ivh kernelfile command to install the new kernel.
Observe the results. Check the files in /boot. Which files look like they're duplicated but with a different version number?
Check your boot loader file. Assuming it's GRUB, open the /etc/grub.conf file in a text editor. Change the default variable in this file to point to the new kernel. If it's LILO, remember to run lilo to record the change in the MBR.
Reboot your computer to test the new kernel.

Answers

4.	Assuming everything works with the updated Red Hat RPM kernel package, you should not have to update anything, especially if your boot loader is GRUB. The steps described in the lab should help you confirm this through the appropriate configuration files on your RHEL 3 computer.

< Day Day Up >