| < Day Day Up > |
|
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.
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.
|
|
Answers
1. | Lab 1
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. |
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.
|
|
Answers
2. | Lab 2
|
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.
|
|
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. |
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.
|
|
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. |
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.
|
|
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. |
| < Day Day Up > |
|