Kernel, Cron, and User Administration, Part 2 - Lab (Page 15 of 15 ) Lab 1
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
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
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:
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
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.  This is part one from the fifth chapter of Red Hat Certified Engineer Linux Study Guide (Exam RH302), fourth edition, by Michael Jang. (McGraw-Hill/Osborne, 2004, ISBN: 0-07-225365-7). Check it out at your favorite bookstore today. Buy this book now.
|
| DISCLAIMER: The content provided in this article is not warranted or guaranteed by Developer Shed, Inc. The content provided is intended for entertainment and/or educational purposes in order to introduce to the reader key ideas, concepts, and/or product reviews. As such it is incumbent upon the reader to employ real-world tactics for security and implementation of best practices. We are not liable for any negative consequences that may result from implementing any information covered in our articles or tutorials. If this is a hardware review, it is not recommended to open and/or modify your hardware. |
|
/ 7 
