Lab Questions

---

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 to manage services at different runlevels: the chkconfig command and the redhat-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 redhat-config-services & command. This allows you to use the same terminal window for other commands. Alternatively, click Main Menu | System Settings | 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 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 it is back.

9. Return to the Service Configuration utility, and click View | Refresh Service List to confirm that nfs is back on 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 is not always available in an emergency or through remote login.

Answers

1. 

Lab 1

1. To open a command line interface in the Red Hat GUI, right-click on the desktop. In the pop-up menu that appears, click New 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:

   # redhat-config-services &

3. Run the ls /etc/rc3.d command. Look for the nfs start script and record the current order number. 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 level 3. It's easy to do so in the Service Configuration utility. But you have to remember to save your changes with the File | Save Changes command.

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 autofs   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 in 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 autofs   0:off   1:off   2:off   3:on   4:on   5:on   6:off 

This should show that the nfs 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 what you see. 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. 

While the Red Hat User Manager provides a convenient interface to add new users, it's important for the exam to know the basic command line tools. Specifically, you can use the useradd, usermod, and userdel commands to add, modify, and delete user accounts.

1. Use the man pages for useradd (or just type useradd with no arguments for a simple help summary) to find the switches you need to add the following account with each of these attributes:

   login: brianr name: brian rite UID: 5010 GID: nobody shell: /bin/bash 

2. Change the passwd for brianr to RvRg49().

3. Open a different virtual terminal. Log in as brianr. What files are present in this new account? Exit from this login.

4. Remove the brianr account using the userdel command. Is the brianr home directory gone? What option would have done this for you?

Answers

2. 

Lab 2

1. To add the account, enter:

   # useradd brianr -u 5010 -g nobody -c 'brian rite' -s /bin/bash

2. Change the password:

   # passwd brianr

3. Open a new virtual console. For example, to open the second virtual console, press ALT-F1. If you're in the GUI, also press the CTRL key.

4. Log into the new account.

5. What files are there? Include all the hidden files to see the skeleton files copied over from the /etc/skel directory.

   $ ls -a

6. Remove the brianr account using the userdel command. Is the brianr home directory gone? What option would have done this for you?

   # userdel brianr       # leaves the home directory # userdel -r  brianr   # also removes home directory

7. Rerun these tasks in the Red Hat User Manager.

Lab 3

3. 

In this lab, you'll configure the Automounter on your computer on an NFS connection. You'll need a second computer with Linux or Unix installed, and a shared NFS directory. You can use the shared NFS installation source created in Chapter 2 or any other shared NFS directory described in Chapter 9. A virtual machine such as a VMWare computer qualifies as a second computer.

1. Back up your current /etc/auto.master and /etc/auto.misc configuration files.

2. Open the /etc/auto.master configuration file in the text editor of your choice. Add or activate the command which applies the Automounter to the /misc directory.

3. Open the /etc/auto.misc configuration file. Use the example shown in this file to create an NFS entry, which points to the shared NFS directory on the second computer. For the purpose of this lab, set the name of the directory to test.

4. Restart the autofs server.

5. Try your connection. Run the following command:

   # ls /misc/test

6. You should see the contents of the shared NFS directory. Run the following command. What do you see?

   # ls /misc

7. Wait a while, at least the timeout specified in the /etc/auto.master configuration file.

8. Run the ls /misc command again. What happens?

9. Once you're satisfied with the result, restore the files you backed up in step 1.

Answers

3. 

Lab 3

Configuring the Automounter on a shared NFS directory is easier than it looks. Before you begin, make sure that you can mount the shared NFS directory from the remote computer. If there's a problem, resolve those first before beginning this lab. Refer to Chapter 2 on creating an NFS Installation Server or Chapter 9 on NFS for more information. If there's no problem with a source on an NFS server with an IP address of 192.168.30.4, you should be able to mount it locally. For example, you can mount a shared remote NFS /mnt/inst directory on an existing empty local /mnt/test directory as follows:

# mount -t nfs 192.168.30.4:/mnt/inst /mnt/test 

Configuring the Automounter is easier than it looks. But first, as with any of these experiments, it's important to back up any files that you're about to edit. In this case, those are the configuration files which govern the autofs daemon, /etc/auto.master and /etc/auto.misc.

One of the fortunate things about the RHEL 3 version of these files is that they contain tips and example commands that you can use and learn from as you work with the Automounter. Use them to your advantage. You can activate the standard commented command in the /etc/auto.master file to activate the Automounter on the /misc directory:

/misc    /etc/auto.misc    --timeout=60

This command sets a timeout of 60 seconds, depending on details specified in /etc/auto.misc. Activate this command (remove the #) and save your changes to /etc/auto.master.

Open /etc/auto.misc in your text editor. The example shown is easy to follow:

#linux   -ro,soft,intr    ftp.example.org:/pub/linux

Let's assume you're using your NFS installation server from Chapter 2, and that server is at IP address 192.168.30.4. In that case, you'd add the following command to this file:

test    -ro,soft,intr    192.168.30.4:/mnt/inst

Now you can restart the autofs server; the quickest way is with the following command:

# service autofs restart

Now when you test the result, you should be able to see the contents of your shared NFS directory.

# ls /misc/test

You can test the result in a different way. Before the timeout in /etc/auto.master expires, the following command should reveal the test subdirectory:

# ls /misc test

After the timeout is complete, rerun the ls /misc command again. The test subdirectory should no longer be there, which tells you that the timeout specified in /etc/auto.master has expired. Please, retry this lab with other shared NFS directories. Remember to restore the original /etc/auto.master and /etc/auto.misc files when you're done.

Lab 4

4. 

In this lab, you'll observe what happens when you avoid mounting the /boot filesystem. This of course assumes that you have a computer configured with /boot mounted on a separate partition.

1. Back up your /etc/fstab configuration file to something you can easily remember, such as /etc/bak.fstab.

2. Run the df command and make a note of the mounted filesystems, especially the partition associated with /boot.

3. Open /etc/fstab in the text editor of your choice. You should have a line associated with the /boot directory. If you do not, stop, as you cannot continue with this lab. Trying to continue with this lab under these circumstances will probably render your system unbootable.

4. Comment out the line with the /boot directory. Add a # in front of that line. For example, your /etc/fstab /boot directory line might read something like:

   # LABEL=/boot         /boot          ext3        defaults  1 2

5. Save /etc/fstab and reboot Linux.

6. Observe the results. Does Linux start normally?

7. Look at your boot directory. Are there any files missing? How did Linux boot without benefit of a vmlinuz kernel or a mkinird RAM disk file?

8. Run the df command and make a note of the mounted filesystems.

9. Open /etc/fstab again. Remove the comment field, the #, in front of the /boot directory line. Save /etc/fstab. This should restore your /etc/fstab to the original configuration.

10. Mount the /boot directory with the mount /boot command.

11. Open your GRUB configuration file, /boot/grub/grub.conf in your text editor.

12. Observe the line associated with the root variable. This should correspond to the default partition for the /boot directory. Note that GRUB does not require that a partition is mounted to access a file.

13. Reboot your system. Run the df command and compare the list of mounted filesystems to step 2. If they are the same, stop here. Otherwise, restore your /etc/fstab from the backup file, /etc/bak.fstab.

Answers

4. 

Lab 4

Remember, you should not try this exercise if you don't have a separate line for the /boot filesystem in /etc/fstab. And this assumes that GRUB is your default bootloader.

This should be a self-explanatory exercise. Essentially, you're just making a minor modification to the /etc/fstab file. If you do it correctly, Linux should boot normally, even if it does not mount the /boot filesystem. The key is within the GRUB configuration file, as the root variable in /boot/grub/grub.conf doesn't require a mounted filesystem to read your vmlinuz kernel or your mkinird initial RAM disk files.

Lab 5

5. 

In this lab, you'll install a new package group with the redhat-config-packages command, also known as the Package Management utility. You'll need a remote network source with the Red Hat installation files. It can be the same network source that you used in Chapter 2 to install RHEL 3.

1. In the Red Hat GUI, open a command line interface.

2. Click Main Menu | System Settings | Add/Remove Applications to open the Package Management utility.

3. Try adding the software of your choice. When you're prompted for a CD, click Cancel and exit from the utility.

4. Mount the network installation source that you created in Chapter 2. For the purpose of this lab, create a /mnt/test directory, and then use that as the mount point.

5. Run the following command. If it doesn't start the Package Management utility, there may be a problem with the mount or the network source. See Chapter 2 for more information.

   # redhat-config-packages --tree=/mnt/test

6. Try adding the software of your choice. Now see if you're prompted for a CD.

Answers

5. 

Lab 5

The point of this lab is to see how you can use the Package Management utility with a network installation source. You'll be able to install any additional package groups that you need. That can be much more efficient than using the rpm command to install the dozens of RPMs associated with some package groups.

The steps I've described work only if your connection to the NFS server works, as described in Chapter 2 as well as Lab 3.

---