RHCE_Linux_Study_Guide-4rd Edition

syd168

Lab 1
1.  
You need to test Red Hat Enterprise Linux 3 as a replacement for your current RH 7.2 installed Web server. But you do not want to lose the current 7.2 Web setup just yet. You just want to test RHEL 3 using the Web pages and CGI scripts to see if they will work. What can you do? (Note: Fresh installations from Red Hat Linux to RHEL 3 are recommended.)
  


Answers

1.
Scenario 1: Buy a new disk and add it to the system. Then do a custom install to create a new installation of RHEL 3 to partitions on the new disk, adding an entry to /etc/grub.conf to provide a boot option to both versions of Linux.

Scenario 2: No space on server. Hmm … you've got to get creative and either find a test computer you can do the test install on or back up everything on the main server after taking it off line. Perform a new installation of RHEL 3. Copy your httpd.conf configuration file and see how it works. If it fails, you restore everything back to the way it was. Note: Test your backups first before overwriting an existing operating system.



Lab 2
2.  
You want to test the linux rescue option from a boot disk or Installation CD. To make this work, you'll need access to installation media locally (from a CD-ROM or hard disk) or over a network (from an NFS, FTP, or HTTP server). If required, create a boot disk from the bootdisk.img file described earlier in this chapter.

Insert the appropriate installation media (boot floppy or CD) into the drive.

Reboot your computer. If necessary, adjust the boot order in your computer's BIOS menu to boot from the appropriate media.

When you see the first RHEL installation screen, type linux rescue and then press ENTER.

Go through the text mode prompts for language and keyboard.

If you booted from the first installation CD, the following screen allows you to start networking on this system. While it can be helpful, it's not required here. Select No and press ENTER to continue.

If you've started with a boot floppy, the next screen is entitled Rescue Method. Select the system (CD, hard disk, NFS, FTP, HTTP) with your installation media. (If you've started with the first RHEL installation CD, skip to step 7.)

Enter the data required to point the RHEL installation program at your installation media. The details vary with the method. For more information, refer to the appropriate sections earlier in this chapter.

You should now see a text mode Rescue screen. Select Continue and press ENTER to continue.

If successful, you'll see a message that 'Your system has been mounted under /mnt/sysimage.' Click OK to continue.

Run several commands to see what the rescue disk has done to your system: df, ls -l /, ls -l /mnt/sysimage. Observe the results.

Run the vi /etc/inittab command. This is a critical file. Observe the results. Why do you think the /etc/inittab file is empty?

Run the chroot /mnt/sysimage command. Run the commands shown in steps 9 and 10. What happened?

If you're feeling adventurous, repeat this process. At step 7, select Skip instead of Continue. What is the difference? Could you mount the partition with the root directory on the /mnt/sysimage directory? Remember, you can find partitions with the fdisk command and create directories with the mkdir command. (You might have to be adventurous during the Red Hat Troubleshooting and System Maintenance exams.)
  


Answers

2.
This is a useful exercise in using the Linux rescue system. If the problem is relatively minor, the steps shown will create a RAM disk with some essential tools on the root (/) filesystem. You can use these tools to repair damaged filesystems or partitions on your hard disk. The man pages don't work right away, because what is normally your root (/) directory is actually mounted on /mnt/sysimage.

The chroot /mnt/sysimage command makes the /mnt/sysimage directory into your root (/) directory. Everything (such as man pages) should work normally now.

The other option, to skip the mount process during linux rescue setup, does not mount any of your partitions. You can now mount them individually. If you create a /mnt/sysimage directory, you can even mount them in the same way as you saw during the first part of this exercise. Since your partitions are not mounted, you can fix damaged filesystems with commands such as fsck.



Lab 3
3.  
You want to practice network installations. To do so, set up an FTP installation server on a different Linux computer using the instructions described earlier in this chapter. These instructions also work if you want to create an FTP installation server on Red Hat Linux 9.

If you don't have another Linux computer, you can set up an FTP server on Microsoft Windows 2000/XP Professional/2003 for this purpose.

For the purpose of this exercise, assume that you've been asked to install a Web server, a DNS server, an FTP server, and a mail server during the RHEL 3 installation process.
  


Answers

3.
As described earlier in this chapter, the standard Red Hat FTP server is vsFTP; the default location for download files is the /var/ftp/pub directory. You'll want to specify a subdirectory to copy the files from the /RedHat directory from the installation CDs.

As this is a book on RHEL, I do not describe the steps needed to create an alternate FTP server on a Microsoft Windows computer.

To install a Web server, a DNS server, an FTP server, and a mail server during the RHEL 3 installation process, you need to select the DNS Name Server, Web Server, FTP Server, and Mail Server package groups.



Lab 4
4.  
You want to practice network installations. To do so, set up an HTTP installation server on a Linux computer using the instructions described earlier in this chapter. These instructions also work if you want to create an HTTP installation server on Red Hat Linux 8 and 9.

If you don't have another Linux computer, you can set up an HTTP server on Microsoft Windows 2000/XP Professional/2003 for this purpose.

For the purpose of this exercise, assume that you've been asked to install a Samba server, a print server, and will need to recompile the kernel.
  


Answers

4.
As described earlier in this chapter, the standard Red Hat HTTP server is Apache. The default location for download files is the /var/www/html directory. You'll want to specify a subdirectory to copy the files from the /RedHat directory from the installation CDs.

As this is a book on RHEL, I do not describe the steps needed to create an alternate HTTP server on a Microsoft Windows computer.

To install a Samba server, a print server, and the packages associated with recompiling the kernel during the RHEL 3 installation process, you need to select the Windows File Server, Printing Support, and Kernel Development package groups.

syd168

Lab 1
1.  
You just got hold of ten new PCs for the Human Resources department from a name brand PC manufacturer and you want to install Red Hat Enterprise Linux on each computer. You want to install Linux on all of them with an optimized set of packages, and you want to do it quickly.

Each of these computers has a standard 3Com network card that you know Linux has support for because you ordered the computers that way. They also each have one big 10GB disk that already contains Windows 98. You do not have time to install Red Hat Enterprise Linux 3 Workstation on each computer manually. What should you do?

Assume you need to configure each computer with static IP addresses.
  


Answers

1.
The solution is simple. The details are long. Each of the following steps are high level; for the nitty- gritty details of what you need to do, refer back to discussions in this chapter (as well as Chapter 2). If you're using these instructions to restore a RHEL 3 installation from Part 1, minimize the changes that you need to make to this file.

Set up the RHEL 3 Workstation installation files on a network source.

Install RHEL 3 Workstation over the network on one computer.

Edit the /root/anaconda-ks.cfg file as needed.

Windows 98 partitions. (This assumes you've backed up any needed data files first.)

Activate the command lines related to creating partitions. They are commented out by default in the anaconda-ks.cfg file.

In the Kickstart configuration file, make sure that the line after the install command points through the network to the source for the RHEL 3 Workstation installation files. If you're connecting through NFS, this starts with the nfs command; if you're connecting through FTP or HTTP, this starts with the url command.

Use this Kickstart file as a configuration file template for installing Linux on each of your computers.

Create a different file for each computer; you'll need to set a different IP address on the same subnet for each file.

Set up a different installation floppy for each computer. Each installation floppy will include the customized Kickstart file. You'll probably also need one or more driver floppies. Alternatively, you can set this up based on the boot.iso file. All of these disks can be created from images on your first RHEL 3 installation CD. This process is described in Chapter 2.

You can then set up a network installation on each computer. You'll probably also need the RHEL 3 network driver floppy described in Chapter 2. You can use the same driver floppy on each computer.

Now insert the appropriate installation floppy in each of your workstations. When prompted, add the driver floppy to load the appropriate network drivers.

Your installation should now proceed automatically on each workstation.

Save any installation boot and driver disks or CDs that you created in this lab for Part 2.



Lab 2
2.  
This lab requires that you have one of the network installation servers described in Chapter 2 and a test computer where you're willing to reinstall RHEL 3. This exercise erases any operating system that you currently have on a computer! Do not run this lab unless you can afford to lose all files and are willing to reinstall RHEL 3 on this computer. You're going to move one of the critical files out of the installation source directory.

You could perform this lab on a new VMWare machine. Alternatively, you could run this on a computer with a standard configuration, where you can set up an automated reinstallation with a Kickstart configuration file. You've probably just seen this process in the answer to Lab 1.

Log into the remote network server with your RHEL 3 installation files.

Look at your comps.xml configuration file. It's stored in the RedHat/base/ subdirectory of the installation source. Open it in a text editor or a text reader such as the less command.

Browse through the list of packages in XML format. Pay attention to the packages in the Base and Core package groups.

Pick a RPM package from one of these groups. If you can't think of one, I've selected the filesystem-2.2.1-3.i386.rpm file.

Move that file to the home directory to some other directory on that network installation server. Make sure to use the mv command; the cp command leaves a copy on the installation source.

If you have valuable data on this computer, STOP HERE! The following steps will delete the information at least on the Linux partitions on your computer-and possibly on the entire computer.

Return to your test computer, and proceed through the RHEL 3 installation process.

At some point, the RHEL 3 installation process will miss the RPM that you moved and stop with a message to that effect.

Press CTRL-ALT-F2. You should see a bash prompt. Look in the /mnt/sysimage directory. What is the directory tree in this directory?

Navigate to the /mnt/sysimage/root directory. Look at the files in this directory. Which file tells you about the RPMs that have been installed?

Run the chroot /mnt/sysimage command. If it doesn't work, your installation stopped before RHEL 3 had a chance to install the bash shell. With the RPM cited, this is the case.

Press CTRL-ALT-F3. Take a look at the messages. You should see the partitions you specified, mounted in some way. Where are they mounted?

Press CTRL-ALT-F4. Take a look at the messages. You should see various kernel messages. What types of messages do you see?

Press CTRL-ALT-F5. Take a look at the messages. You should see various partition messages. What commands do you see in this screen?

On the network server, restore the RPM that you moved.

Depending on whether you're installing in text or graphical mode, return to your installation screen with the CTRL-ALT-F1 or CTRL-ALT-F7 command.

Proceed with the installation of RHEL 3.
  


Answers

2.
This lab should be fairly self-explanatory. It provides a specific problem that stops the installation of RHEL 3. It gives you an opportunity to examine the other consoles available during the installation process. Remember, you should not run this lab on any computer where you have valuable data. I've added some commentary which may clarify the steps you need to take in this lab.

The comps.xml file is located in the installation source. If you're using the same NFS installation source that I described in Chapter 2, it's on the /mnt/inst directory. Thus, the comps.xml file is located in the /mnt/inst/RedHat/base directory. If you already have an installed copy of RHEL 3 on an Intel-compatible 32-bit CPU computer, you can find another copy of this file in the /usr/share/comps/i386 directory.

The format of the comps.xml file might be confusing to anyone not familiar with the XML language. However, it's not as complex as it seems. For example, you can find the filesystem RPM in this file in the following format:

<packagereq type="mandatory">filesystem</packagereq>
When you browse higher on this file, you'll see that the filesystem RPM is part of the Core package group.

Once the installation stops at the problem you created, you can browse through the different consoles. The second console includes the bash prompt, even though bash commands aren't installed yet. You should also recognize the standard root directory (/) tree in the /mnt/sysimage directory.

In the third virtual console, you'll see messages that partitions such as /tmp/hda1 or /tmp/sda1 are mounted. For example, a partition mounted on the root directory is mounted on the /mnt/sysimage directory during the installation process. The partitions that you've created through Disk Druid are mounted on a temporary basis until installation is complete.

The kernel messages that you see in the fourth virtual console show hardware and filesystem messages. The fifth virtual console lists the messages you see when the filesystem is formatted.



Lab 3
3.  
What would you do differently from Lab 2, assuming that you have configured a DHCP server for your network?
  


Answers

3.
The basic steps are the same. However, if the ten computers are connected to a network with a DHCP server, your task is easier. Modify the aforementioned Kickstart template file. Assuming it's the first Ethernet adapter on each computer, the key command will be network --device eth0 --bootproto dhcp.

Since you're getting network information from a DHCP server, you can use the same installation floppy for each of the workstations. You'll still need the driver floppy. Now insert the appropriate installation floppy in each of your workstations. When prompted, add the driver floppy to load the appropriate network drivers. You should be on your way!

Alternatively, you can create a customized boot CD based on the boot.iso file on the first RHEL 3 installation CD. Add the ks.cfg file when you burn your CD from boot.iso.



Lab 4
4.  
You want to set up a server for these new PCs. You want to configure that computer with the Red Hat Enterprise Linux 3 Server operating system. That server includes five separate SCSI physical hard drives of 10GB each. You'll install RHEL 3 on the first hard drive. How would you configure a RAID 5 array on the remaining hard drives? Assume you'll need 5GB from each of the 10GB hard drives.
  


Answers

4.
Now you're configuring a RAID 5 array for your workstations on a RHEL 3 server. With the given configuration, RHEL 3 will be installed on the first hard disk. The remaining four hard disks are available for other purposes. You'll use 5GB of each of those SCSI hard disks to create RAID 5 arrays. It's easiest to do so during the installation process. However, you can still do so after RHEL 3 is installed.

As they are SCSI hard disks, Linux represents them as /dev/sdb, /dev/sdc, /dev/sdd/, and /dev/sde. You can divide the 5GB on each of these hard disks into near equal parts (RAID does not require identical components in its arrays.). If you created 5GB partitions on each hard disk, you could set up a RAID 5 array with the first 3 partitions: /dev/sdb1, /dev/sdc1, and /dev/sdd1. You could then set up the partition on the final drive, /dev/sde1, as a spare. (While you could set up all four partitions as a RAID 5 array, it's useful to have a spare. If one drive fails, the RAID 5 software automatically begins rebuilding data on the spare drive.)

You can create a RAID array after RHEL 3 is installed, using the following basic steps. For detailed steps, refer back to the chapter.

Use the fdisk utility to create and size partitions from available space on the SCSI hard disks.

With the t switch, set these partitions as usable by RAID by setting them to the Linux RAID autodetect filesystem.

Format each partition, set up the array in /etc/raidtab, and use the mkraid -R command to create the RAID device.

Format the RAID device to the Linux ext3 filesystem.

Save any data from the directory that you want to mount on the RAID array.

Mount the directory of your choice to that filesystem, and finally, implement the change in /etc/fstab.



Lab 5
5.  
On that server, you want to configure LVM in the remaining space. How would you set up the Physical Volumes (PVs)? How do you create a Volume Group (VG) from the PVs? Once you've created a VG, how would you set up a Logical Volume? Where would you mount a directory such as /home/flexuser?
  


Answers

5.
You can create LVM groups after RHEL 3 is installed, using the following basic steps. For detailed steps, refer back to the chapter.

Use fdisk to create partitions from the remaining available space on each of the last four SCSI drives. Make sure to set each partition to the Linux LVM filesystem.

Initialize each of these partitions with the pvcreate command.

Set up all of these partitions together as a Volume Group (VG) with the vgcreate command.

Now set up a Logical Volume from that VG with the lvcreate command. You can set it to a fixed number of Physical Extents or a fixed amount of space.

Take the directory of your choice. Back up any data currently on that directory.

Mount the directory on the LV. Copy the data from backup.

Finally, set up the mount in the /etc/fstab configuration file.

syd168

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.

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.

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

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).

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

Remove the nfs service from runlevel 3 using the Service Configuration utility.

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

Restore the nfs start script with the following command:

# chkconfig --level 3 nfs on
Switch back to the console window and run the chkconfig --list nfs command to verify that it is back.

Return to the Service Configuration utility, and click View | Refresh Service List to confirm that nfs is back on in runlevel 3.

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

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.

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 &
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.

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.

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   0ff   1ff   2ff   3ff   4n   5n   6ff
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
Now run the following chkconfig command to verify that nfs is active again in runlevel 3:

# chkconfig --list nfs
autofs   0ff   1ff   2ff   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.

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

Change the passwd for brianr to RvRg49().

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

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

To add the account, enter:

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

# passwd brianr
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.

Log into the new account.

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

$ ls -a
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
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.

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

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.

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.

Restart the autofs server.

Try your connection. Run the following command:

# ls /misc/test
You should see the contents of the shared NFS directory. Run the following command. What do you see?

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

Run the ls /misc command again. What happens?

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.

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

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

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.

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
Save /etc/fstab and reboot Linux.

Observe the results. Does Linux start normally?

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?

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

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.

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

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

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.

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.

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

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

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

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.

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
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.

syd168

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
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

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
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

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
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

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:

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
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.

syd168

Lab 1
1.  
You want to upgrade the video card in your Linux system. Your old video card is slow and doesn't have enough display memory to provide you with the resolution and color depth you require. You have obtained a new ATI 32MB Radeon card (I'm using this product for example purposes only). What steps might you follow to replace your old card with your new card?
  


Answers

1.
Lab 1

Before you stop Linux on your computer, you should configure it so it no longer attempts to start the X Server when Linux boots. This is controlled by the initdefault line in the /etc/inittab file. Edit this file and change the second field from 5 (Multi-User With X Support) to 3 (Multi-User With No X Support). You could use vi, pico, or any other suitable text editor to do this job.

Perform an orderly shutdown on your system at a safe time. Use the shutdown -h now command.

Now that the system is off, replace your video card.

Start your computer and boot into RHEL 3. During the boot process, the Red Hat kudzu command automatically probes for new hardware. If this probe finds your new video card, you can configure it when prompted.

If kudzu fails to find your new hardware, you should log in as root and run the Red Hat Display Settings tool.

The Red Hat Display Settings tool should correctly identify your new hardware. You should select the correct amount of display memory (32MB) and the graphics resolutions and color depths you desire. If it does not, you can configure it manually using the available settings.

Test the result. Run the startx or init 5 command to start the Linux GUI.



Lab 2
2.  
You want to see what happens when there are problems starting the Linux GUI. With RHEL 3, the XFree86 Version 4.x server is configured by default. The configuration of the X Server is stored in the /etc/X11/XF86Config configuration file. Before Linux starts the X Server, it reads this file. To do so, you'll want to back up your current /etc/X11/XF86Config file, delete it, and then reboot your computer into runlevel 5. You can restore it after the lab is complete.
  


Answers

2.
Lab 2

Back up /etc/X11/XF86Config to a safe location such as your home directory.

As the root user, delete or rename the /etc/X11/XF86Config file.

Open /etc/inittab in your favorite text editor. Look at the line with initdefault. Change the number right before this variable from a 3 to a 5 if required.

When you reboot your computer, observe what happens when Linux tries to find the default login display manager.

Restore your original settings.

If you are interested in more experiments, try deactivating the X Font Server. Run the chkconfig xfs off command. Change your initdefault in /etc/inittab from 3 to 5 again. Restart your computer and observe what happens.



Lab 3
3.  
For this lab, you'll need two Linux computers connected over a network. You'll need a shared NFS directory from the local computer. You can use the same directory that you may have used in Chapter 2 to share the RHEL 3 installation files. Start a Secure Shell connection between the two computers. Start the GUI on the local computer, and use the Secure Shell to log in remotely to the other computer. Finally, set and export an appropriate DISPLAY variable. You can then see what happens when you start X Clients from the remote computer.

Once you do, run the Red Hat root password program from the remote computer. Make changes to the password. When you log out and try to log back into the remote computer, you should be able to confirm that the root password on the remote computer has changed.
  


Answers

3.
Lab 3

For this lab, you'll need two Linux computers connected over a network. You'll need a shared NFS directory from the local computer. You can use the same directory that you may have used in Chapter 2 to share the RHEL 3 installation files. You'll start a Secure Shell connection between the two computers. You'll start the GUI on the local computer, and use the Secure Shell to log in remotely to the other computer. Finally, you'll set and export an appropriate DISPLAY variable. You can then see what happens when you start X Clients from the remote computer.

Once you do, run the Red Hat GUI firewall program from the remote computer. Make changes to the firewall, and see what happens. Finally,

On the local computer, start the GUI. If you're currently at the text interface, you can do so with the startx command.

Open a command line interface. Assuming you're using the default GNOME desktop, right-click on the desktop and click New Terminal in the pop-up menu that appears.

In the new terminal, confirm any currently exported directories with the showmount -e command. Based on /etc/exports, select a directory that is set as writable. Use the techniques described in Chapter 9 if required to make it so. You'll be connecting back to one of these directories from your remote computer.

Authorize access from the remote computer. For example, if you're connecting to a computer named desktop2, run the following command (you can substitute the IP address):

# xhost +desktop2
Connect to the remote computer using the Secure Shell. Assuming the remote computer is named desktop2, run the following command:

# ssh root@desktop2
(If you have a problem making the connection, you may need to go to the remote computer and activate the Secure Shell service with the service sshd start command. You can also substitute the IP address for the computer name.)

Enter the root password on the remote computer when prompted.

Set and export the DISPLAY variable on the remote computer. Make sure it points to the local computer. If the local computer is named desktop1, you would use the following command:

# export DISPLAY=desktop1:0.0
Now try running the redhat-config-rootpassword command. If successful, you'll be changing the root password on the remote computer.

Log out of the remote computer. Log back in using the ssh command from step 5. Did the root password change?

Restore the original root password on the remote computer. Reset the display variable on the remote computer with the following command:

# export DISPLAY=localhost:0.0



Lab 4
4.  
In this lab, you'll set up a GUI workstation. It'll start with the xdm login manager, and automatically start GNOME, open the Mozilla Web browser, and start a gnome-terminal session when you boot this Linux computer.
  


Answers

4.
Lab 4

Since you're setting up this workstation for a user, you'll want it to start automatically in the GUI. To do so, open the /etc/inittab file in a text editor, and make sure the initdefault variable is set to runlevel 5 as follows:

id:5:initdefault
Make sure you don't have other settings defined in the local home directory, in the ~/.xinitrc file.

As you want to start with the xdm login manager, you'll want to set it as the preferred login manager in the /etc/X11/prefdm file. You can do it by setting the preferred variable as shown:

preferred=xdm
Make sure that GNOME is the default desktop. If you see an .Xclients-default file, it should contain the following line:

exec gnome-session
If you don't see this line, or the file does not exist, you can set it up and make GNOME the default desktop with the following command:

# switchdesk gnome
Now reboot your computer. From the command line, you can just run the reboot command. Alternatively, if you're already in GNOME, click Main Menu | Log Out and select the Reboot option.

If you've taken the steps described, you should now see the xdm login manager. Log in through that interface.

Now in GNOME, click Main Menu | Preferences | More Preferences | Sessions. This opens the Sessions utility.

Click the Startup Programs tab. Click Add. This opens the Add A New Session window.

Enter the gnome-terminal command and click OK.

Repeat step 9.

Enter the mozilla command in Add A New Session window and click OK.

Click Close in the Session window.

Log out of GNOME, and log back in.

You should now see the GNOME desktop with the gnome-terminal command line interface and Mozilla Web browser.

syd168

Lab 1
1.  
In this first lab, you'll install and configure Apache to start and run automatically the next time you boot your computer. You'll also configure the default Mozilla Web browser home page as the default home page for the local computer.
  


Answers

1.
First, make sure the Apache Web server is installed. If an rpm -q httpd command tells you that it is missing, you haven't installed the Web Server package group. The most efficient way to do so is with the Red Hat Package Management utility, only accessible through the Linux GUI.

To configure Apache to start, you'll want to run the apachectl start command. To make sure it starts the next time you boot your computer, you'll want to run the chkconfig --level 35 httpd on command.

Once Apache is installed, you should be able to access it by opening a browser and navigating to http://localhost. You can see in the default Apache configuration file that the DocumentRoot is located in /var/www/html. The default Mozilla home page is located at /usr/share/doc/HTML/index.html. You can copy that index.html file to the /var/www/html directory, and test the result by navigating once again to http://localhost. If you did not copy the other files associated with the default Mozilla home page, you'll be missing some icons.



Lab 2
2.  
In this second lab, you'll configure two Web sites on the local Apache server. Call them big.example.big and small.example.small. Don't forget to create the directories that you need, as well as set up these Web sites on your DNS server or /etc/hosts file. Make sure your Web sites are accessible to users from remote computers on your network. Add an appropriate index.html file to the DocumentRoot for each Web site. Simple Web pages, such as a single line of text, are acceptable.
  


Answers

2.
This lab requires that you create two virtual hosts in the main Apache configuration file, /etc/httpd/conf/httpd.conf. To do so, you should do the following:

Set the NameVirtualHost directive to the IP address and port (80) serving your intended network audience.

Add a VirtualHost container with the same IP address.

Assign the ServerAdmin to the e-mail address of this Web site's administrator.

Configure a unique DocumentRoot directory.

Set the first ServerName to big.example.big.

Add ErrorLog and CustomLog directives, and set them to unique filenames in the /etc/httpd/logs directory. With the default ServerRoot, you can use a relative logs directory, such as:

ErrorLog logs/big.example.big-error_log
Make sure to close the VirtualHost container.

Repeat the process for the second Web site, making sure to set the second ServerName to small.example.small.

Close and save the httpd.conf file with your changes.

Create any new directories that you configured with the DocumentRoot directives.

Create index.html text files in each directory defined by your new DocumentRoot directives. Don't worry about HTML code; a text file is fine for the purpose of this lab.

Make sure these domain names are configured in your DNS server or in /etc/hosts. For example, you could add the following lines to /etc/hosts:

192.168.30.2 big.example.big
192.168.30.2 small.example.small
Disable any firewall on your computer. Alternatively, you can use the Security Level Configuration tool (redhat-config-securitylevel) utility to allow HTTP data through your firewall; see Chapter 10 for more information on this process.

Finally, make sure to run the apachectl restart command to reread the httpd.conf configuration file, so Apache reads your changes.

Now you can test the result in the browser of your choice. If it works, the big.example.big and small.example.small domain names should direct you to the index.html files that you created for each Web site.



Lab 3
3.  
Continuing on with Apache, now configure secure versions for each of your two Web sites. Make sure that there are appropriate directories available for each secure Web site.
  


Answers

3.
The basics of this lab are straightforward. You'll need to repeat the same basic steps as you performed in Part 2; you're just editing the /etc/httpd/conf.d/ssl.conf configuration file. However, there are a few things to be concerned about:

Make sure that the top VirtualHost directive points to the IP address that you're using for your Web server.

Set up the DocumentRoot in a directory different from a regular Web server.

Configure the ErrorLog and CustomLog separately; it can help to associate it with the name of the secure Web site.

Continuing on with Apache, now configure secure versions for each of your two Web sites. Make sure that there are appropriate directories available for each secure Web site.



Lab 4
4.  
Set up a Squid proxy server on your computer. Set up access to your LAN on the 10.11.12.0/255.255.255.0 network. Assign appropriate values to acl, http_access, and visible_hostname. Set up the cache directories for Squid. Make sure it starts now and automatically the next time you reboot your computer.
  


Answers

4.
First, Squid is automatically installed when you install the Web server package group. To configure a Squid proxy server for your network, you'll need to configure /etc/squid/squid.conf. Assume the name of your computer is myproxy, and you're arbitrarily assigning mylan as the name for your LAN. If your network IP address is not 10.11.12.0, substitute accordingly. In this file, you'll need to add the following lines:

visible_hostname=myproxy
acl mylan src 10.11.12.0/255.255.255.0
http_access allow mylan
Next, you'll need to set up the Squid directories with the following command:

# squid -z
Finally, to configure Squid to start, you'll want to run the service squid start command. To make sure it starts the next time you boot your computer, you'll want to run the chkconfig --level 35 squid on command.

But you'll also need to activate proxy server access in client applications such as Web browsers. Remember that you can do so by pointing your browsers to port 3128.



Lab 5
5.  
Configure an FTP server for your computer. Make sure to allow only anonymous access. Don't allow anonymous users to upload to your server. Enable messages when users access your /var/ftp and /var/ftp/pub directories. Add an appropriate one-line message to each directory. Test the result, preferably from a remote computer. Make sure to start the vsFTP server now, and see that it starts automatically the next time you reboot your computer.
  


Answers

5.
The vsFTP server is part of a one-RPM package group. So if you have not installed this server during the installation process, the quickest thing to do is to connect to your installation source (CD or network), and install it from that location. For example, if the source is mounted on /mnt/source, you'd install it with the following command:

# rpm --Uvh /mnt/source/RedHat/RPMS/vsftpd-1.2.0-4.i386.rpm
This also installs configuration files in the /etc and /etc/vsftpd directories. The main configuration file is /etc/vsftpd/vsftpd.conf. Based on the RHEL 3 default version of this file, you can make the following changes. To allow only anonymous access, comment out the following line:

local_enable=yes
Anonymous users are already prevented from uploading files to your server. You could enable it by activating the anon_upload_enable=yes command. By default, messages are already enabled for directory access on an FTP server, courtesy of the following command:

dirmessage_enable=yes
Actually configuring a message is a matter of creating a text file, and saving it as .message in the desired directories, /var/ftp, and /var/ftp/pub. You could add a simple line such as 'root directory for the FTP server' or 'main download directory.'

Finally, to configure the Red Hat FTP server to start, you'll want to run the service vsftpd start command. To make sure it starts the next time you boot your computer, you'll want to run the chkconfig --level 35 vsftpd on command.



Lab 6
6.  
Set up a sendmail mail server for your network. First, make sure to disable local-only access in the /etc/mail/sendmail.mc file. Add your network to the /etc/mail/access file. Test the result, preferably from a remote computer on your network. Configure Mozilla to read your e-mail. You can set it up to read e-mail without downloading it from the server (even if it's a POP3 server). Make sure to start the sendmail server now, and see that it starts automatically the next time you reboot your computer.
  


Answers

6.
The sendmail mail server is part of the Mail Server package group. It is automatically installed when you install RHEL 3. You could install related packages using the Package Management utility, or you could install the sendmail-cf RPM package.

To disable local-only access in the /etc/mail/sendmail.mc file, comment out the following line. Unlike most Linux configuration files, you'll want to add a dnl at the start of this line:

DAEMON_OPTIONS(`Port=smtp,Addr=127.0.0.1, Name=MTA')dnl
The dnl at the end of the line does not affect the command to its left. Next, you'll want to enable support through /etc/mail/access. If you want to support your LAN with this server, and its network address is 10.11.12.0, you'd add the following command line to /etc/mail/access:

10.11.12             RELAY
You can test the result from the e-mail client of your choice. It's easiest to use a client such as Mozilla. Netscape users should find this browser to be familiar; it uses the Netscape code, which has been released under an open source-style license. If you're not familiar with Mozilla, you can open it by clicking on the globe icon adjacent to the Main Menu icon in the lower-left corner of the desktop. Once Mozilla is open, click Window | Mail & Newsgroups to open the Mozilla mail management utility. If this is the first time you've opened the Mozilla mail management utility, the Account Wizard prompts you to add the information associated with your e-mail account. Otherwise, click the Add Account button.

You'll need to know the name of your incoming mail server, whether it conforms to the POP3 or IMAP4 protocols, and the name (and password) of your account. You presumably already know the name of the outgoing mail server, the name of the computer with the sendmail server that you just configured.

syd168

Lab 1
1.  
In this first lab, you'll install and configure Apache to start and run automatically the next time you boot your computer. You'll also configure the default Mozilla Web browser home page as the default home page for the local computer.
  


Answers

1.
First, make sure the Apache Web server is installed. If an rpm -q httpd command tells you that it is missing, you haven't installed the Web Server package group. The most efficient way to do so is with the Red Hat Package Management utility, only accessible through the Linux GUI.

To configure Apache to start, you'll want to run the apachectl start command. To make sure it starts the next time you boot your computer, you'll want to run the chkconfig --level 35 httpd on command.

Once Apache is installed, you should be able to access it by opening a browser and navigating to http://localhost. You can see in the default Apache configuration file that the DocumentRoot is located in /var/www/html. The default Mozilla home page is located at /usr/share/doc/HTML/index.html. You can copy that index.html file to the /var/www/html directory, and test the result by navigating once again to http://localhost. If you did not copy the other files associated with the default Mozilla home page, you'll be missing some icons.



Lab 2
2.  
In this second lab, you'll configure two Web sites on the local Apache server. Call them big.example.big and small.example.small. Don't forget to create the directories that you need, as well as set up these Web sites on your DNS server or /etc/hosts file. Make sure your Web sites are accessible to users from remote computers on your network. Add an appropriate index.html file to the DocumentRoot for each Web site. Simple Web pages, such as a single line of text, are acceptable.
  


Answers

2.
This lab requires that you create two virtual hosts in the main Apache configuration file, /etc/httpd/conf/httpd.conf. To do so, you should do the following:

Set the NameVirtualHost directive to the IP address and port (80) serving your intended network audience.

Add a VirtualHost container with the same IP address.

Assign the ServerAdmin to the e-mail address of this Web site's administrator.

Configure a unique DocumentRoot directory.

Set the first ServerName to big.example.big.

Add ErrorLog and CustomLog directives, and set them to unique filenames in the /etc/httpd/logs directory. With the default ServerRoot, you can use a relative logs directory, such as:

ErrorLog logs/big.example.big-error_log
Make sure to close the VirtualHost container.

Repeat the process for the second Web site, making sure to set the second ServerName to small.example.small.

Close and save the httpd.conf file with your changes.

Create any new directories that you configured with the DocumentRoot directives.

Create index.html text files in each directory defined by your new DocumentRoot directives. Don't worry about HTML code; a text file is fine for the purpose of this lab.

Make sure these domain names are configured in your DNS server or in /etc/hosts. For example, you could add the following lines to /etc/hosts:

192.168.30.2 big.example.big
192.168.30.2 small.example.small
Disable any firewall on your computer. Alternatively, you can use the Security Level Configuration tool (redhat-config-securitylevel) utility to allow HTTP data through your firewall; see Chapter 10 for more information on this process.

Finally, make sure to run the apachectl restart command to reread the httpd.conf configuration file, so Apache reads your changes.

Now you can test the result in the browser of your choice. If it works, the big.example.big and small.example.small domain names should direct you to the index.html files that you created for each Web site.



Lab 3
3.  
Continuing on with Apache, now configure secure versions for each of your two Web sites. Make sure that there are appropriate directories available for each secure Web site.
  


Answers

3.
The basics of this lab are straightforward. You'll need to repeat the same basic steps as you performed in Part 2; you're just editing the /etc/httpd/conf.d/ssl.conf configuration file. However, there are a few things to be concerned about:

Make sure that the top VirtualHost directive points to the IP address that you're using for your Web server.

Set up the DocumentRoot in a directory different from a regular Web server.

Configure the ErrorLog and CustomLog separately; it can help to associate it with the name of the secure Web site.

Continuing on with Apache, now configure secure versions for each of your two Web sites. Make sure that there are appropriate directories available for each secure Web site.



Lab 4
4.  
Set up a Squid proxy server on your computer. Set up access to your LAN on the 10.11.12.0/255.255.255.0 network. Assign appropriate values to acl, http_access, and visible_hostname. Set up the cache directories for Squid. Make sure it starts now and automatically the next time you reboot your computer.
  


Answers

4.
First, Squid is automatically installed when you install the Web server package group. To configure a Squid proxy server for your network, you'll need to configure /etc/squid/squid.conf. Assume the name of your computer is myproxy, and you're arbitrarily assigning mylan as the name for your LAN. If your network IP address is not 10.11.12.0, substitute accordingly. In this file, you'll need to add the following lines:

visible_hostname=myproxy
acl mylan src 10.11.12.0/255.255.255.0
http_access allow mylan
Next, you'll need to set up the Squid directories with the following command:

# squid -z
Finally, to configure Squid to start, you'll want to run the service squid start command. To make sure it starts the next time you boot your computer, you'll want to run the chkconfig --level 35 squid on command.

But you'll also need to activate proxy server access in client applications such as Web browsers. Remember that you can do so by pointing your browsers to port 3128.



Lab 5
5.  
Configure an FTP server for your computer. Make sure to allow only anonymous access. Don't allow anonymous users to upload to your server. Enable messages when users access your /var/ftp and /var/ftp/pub directories. Add an appropriate one-line message to each directory. Test the result, preferably from a remote computer. Make sure to start the vsFTP server now, and see that it starts automatically the next time you reboot your computer.
  


Answers

5.
The vsFTP server is part of a one-RPM package group. So if you have not installed this server during the installation process, the quickest thing to do is to connect to your installation source (CD or network), and install it from that location. For example, if the source is mounted on /mnt/source, you'd install it with the following command:

# rpm --Uvh /mnt/source/RedHat/RPMS/vsftpd-1.2.0-4.i386.rpm
This also installs configuration files in the /etc and /etc/vsftpd directories. The main configuration file is /etc/vsftpd/vsftpd.conf. Based on the RHEL 3 default version of this file, you can make the following changes. To allow only anonymous access, comment out the following line:

local_enable=yes
Anonymous users are already prevented from uploading files to your server. You could enable it by activating the anon_upload_enable=yes command. By default, messages are already enabled for directory access on an FTP server, courtesy of the following command:

dirmessage_enable=yes
Actually configuring a message is a matter of creating a text file, and saving it as .message in the desired directories, /var/ftp, and /var/ftp/pub. You could add a simple line such as 'root directory for the FTP server' or 'main download directory.'

Finally, to configure the Red Hat FTP server to start, you'll want to run the service vsftpd start command. To make sure it starts the next time you boot your computer, you'll want to run the chkconfig --level 35 vsftpd on command.



Lab 6
6.  
Set up a sendmail mail server for your network. First, make sure to disable local-only access in the /etc/mail/sendmail.mc file. Add your network to the /etc/mail/access file. Test the result, preferably from a remote computer on your network. Configure Mozilla to read your e-mail. You can set it up to read e-mail without downloading it from the server (even if it's a POP3 server). Make sure to start the sendmail server now, and see that it starts automatically the next time you reboot your computer.
  


Answers

6.
The sendmail mail server is part of the Mail Server package group. It is automatically installed when you install RHEL 3. You could install related packages using the Package Management utility, or you could install the sendmail-cf RPM package.

To disable local-only access in the /etc/mail/sendmail.mc file, comment out the following line. Unlike most Linux configuration files, you'll want to add a dnl at the start of this line:

DAEMON_OPTIONS(`Port=smtp,Addr=127.0.0.1, Name=MTA')dnl
The dnl at the end of the line does not affect the command to its left. Next, you'll want to enable support through /etc/mail/access. If you want to support your LAN with this server, and its network address is 10.11.12.0, you'd add the following command line to /etc/mail/access:

10.11.12             RELAY
You can test the result from the e-mail client of your choice. It's easiest to use a client such as Mozilla. Netscape users should find this browser to be familiar; it uses the Netscape code, which has been released under an open source-style license. If you're not familiar with Mozilla, you can open it by clicking on the globe icon adjacent to the Main Menu icon in the lower-left corner of the desktop. Once Mozilla is open, click Window | Mail & Newsgroups to open the Mozilla mail management utility. If this is the first time you've opened the Mozilla mail management utility, the Account Wizard prompts you to add the information associated with your e-mail account. Otherwise, click the Add Account button.

You'll need to know the name of your incoming mail server, whether it conforms to the POP3 or IMAP4 protocols, and the name (and password) of your account. You presumably already know the name of the outgoing mail server, the name of the computer with the sendmail server that you just configured.

syd168

Lab 1
1.  
Your internal network is growing, and you're having trouble keeping up with the different workstations that are being added to your network on a regular basis. You use the good.example.com subdomain for your internal network, and you've named your computers for your departments, such as engr1 through engr10.good.example.com.

Your mail server is named postal, your Web server is named www, your FTP server is named ftp. You want to configure a DNS server on the computer named names. What do you need to do?

While you may not have enough information in this lab to create a complete and working file, you should be able to figure the outline of what you need to do, with the possible exception of specific IP addresses.
  


Answers

1.
While you could subcontract out the task to an ISP, it's easy to create a DNS server for your internal network. The basic files are already available on RHEL 3. All you need to do is modify these files and add appropriate zone files to your /var/named directory. As there are problems with the Red Hat DNS Server Configuration tool, I'll describe the basics on how you can set up a DNS server by directly editing the appropriate configuration files. Assume that you're using the 10.11.12.0/255.255.255.0 network addresses for your LAN.

First, you'll need to modify the default /etc/named.conf configuration file. It's best to start by backing up this file. You'll need to add stanzas that refer to a zone and a reverse zone file. The stanzas are straightforward:

zone "good.example.com" IN {
      type master;
      file "good.example.com.zone";
};

zone "12.11.10.in-addr.apra" IN {
     type master;
     file "good.example.com.rr.zone";
     allow-update { none; }
};
Next, you can create the good.example.com.zone and good.example.com.rr.zone files in the /var/named directory. These files will contain a database of local and reverse local computer names and IP addresses for your LAN.

In the good.example.com.zone file, you'll want to create the forward database for your DNS server. It'll contain the records for your domain as well as the administrator e-mail address. There's not enough information in the problem to set up a full file, but the following principles apply.

You need to start the zone file with a general Time To Live (TTL) variable; for example, the following command sets a standard TTL (4 days) for data on this DNS server:

$TTL 4D
You'll need a Start Of Authority (SOA) record with the name of the DNS server and your administrative e-mail address. The format of the e-mail address is a little strange; the following line sets an e-mail address of admin@good.example.com. It also sets a serial number based on the date, a refresh (16 hours) and a retry frequency (4 hours), an expatriation period (2 weeks), as well as a TTL (4 days). Do note the dot at the end of each name:

@   IN   SOA     names.good.example.com. admin.good.example.com. (
                 200402121
                 16H
                 4H
                 2W
                 4D
Now you can specify the computers associated with the DNS and mail servers:

    IN   NS      names.good.example.com.
    IN   MX      10 postal.good.example.com.
Finally, you can specify the different computers on your network. While no specific IP addresses are given, you know that you have computers with the following names that you'll have in the good.example.com.zone file. I've added arbitrary IP addresses on the given IPv4 network. You'll have to find the proper IP addresses for yourself with ifconfig commands on each computer:

engr1    IN   A    10.11.12.1
engr2    IN   A    10.11.12.2
engr3    IN   A    10.11.12.3
engr4    IN   A    10.11.12.4
engr5    IN   A    10.11.12.5
engr6    IN   A    10.11.12.6
engr7    IN   A    10.11.12.7
engr8    IN   A    10.11.12.8
engr9    IN   A    10.11.12.9
engr10   IN   A    10.11.12.10
ftp      IN   A    10.11.12.11
www      IN   A    10.11.12.12
postal   IN   A    10.11.12.13
Finally, to make sure that the DNS server works the next time you boot this Linux computer, you'll want to set it to run at the appropriate runlevels with a command such as the following:

# chkconfig --level 35 named on




Lab 2
2.  
You'll need two Linux computers for this lab: one as an NFS server, a second as an NFS client. Let's call these computers nfssvr.example.com and nfsclient.example.com. On the server, you'll want to share the /home directories, and provide write permissions to the client computer. On the client, you'll want to set up the /home directory from the NFS server to be mounted the next time you boot that client computer.
  


Answers

2.
This lab is the first step towards creating a single /home directory for your network. Once you get it working on a single client/server combination, you can set it up on all clients and servers. You can then use the NIS server described in Chapter 10 for a single Linux/Unix database of usernames and passwords for your network. On the NFS server, you'll want to take the following steps:

Set up some users and special files that you'll remember in some of the user's home directories on the server. The details are not important-just make a note of what you've done.

Share the /home directory in /etc/exports. You'll want to share it with the nfsclient.example.com client. You can do this in this file with the following command:

/home nfsclient(rw,sync)
Export this directory with the following command:

# exportfs -a
Restart the NFS service:

# service NFS stop
# service NFS start
Make sure that the exported /home directory shows in the export list. On the local server, you can do this with the following command:

# showmount -e
If you have problems with any step in this process, make sure you don't have extra spaces in /etc/exports and that the NFS service is actually running with the service nfs status command. You may also want to check your firewall and make sure the appropriate services described in this chapter are running with the rpcinfo -p command.

Remember to make sure that the NFS server starts automatically the next time you boot that computer. One way to do so is with the following command:

# chkconfig --level 35 nfs on
Now on the NFS client, you'll want to take the following steps to connect to the shared /home directory:

First, you'll want to make sure that you can see the shared /home directory. If your DNS server is not working in any of these commands, you can substitute the IP address of the appropriate computer:

# showmount -e nfssvr.example.com
Now you'll want to mount the share that is offered on the local /home directory:

# mount -t nfs nfssvr.example.com:/home /home
Check to see that the mounting has worked. If it did, you'll see the NFS mount in the output to the mount command.

Now look through the mounted /home directory for the special files that you created in step 1. If you find them from the NFS client, you've succeeded in creating and connecting to the /home directory share.

To make the mount permanent, you'll want to add it to your /etc/fstab file. Once you've added a command such as the following to that file, the Linux client automatically mounts the shared /home directory from the NFS server.

nfssvr.example.com:/home    /home    nfs   soft,timeout=100  0  0




Lab 3
3.  
You'll also need two Linux computers for this lab: one as a DHCP server, a second as a DHCP client. Using the DHCP server created earlier in this chapter, set up a static IP address for the computer of your choice. You'll want to assign a specific name for that server, precious.example.com, and a special IP address on the 10.11.12.0 network, 10.11.12.13. Assume that you've already set up the example.com network as well as an appropriately configured DNS server.
  


Answers

3.
Assuming you've read the chapter, you've seen the template in the dhcpd.conf.sample configuration file for a static IP address:

host ns {
     next-server marvin.redhat.com
     hardware ethernet 12:34:56:78:AB:CD;
     fixed-address 207.175.42.254;
  }

As described in the chapter, the next-server command is associated with the boot server for this computer; since there is no boot server mentioned, you won't need this command. To set up the DHCP server, take the following steps:

On the DHCP server computer, open the /etc/dhcpd.conf file. If this file doesn't exist, you haven't yet created a DHCP server on this computer.

Set up a new host in the DHCP configuration file:

host precious {
On the DHCP client, run the ifconfig command to find the hardware address associated with that computer's Ethernet network card. For the purpose of this exercise, assume it's AB:CD:EF:12:34:56; the host command line continues as follows:

     hardware ethernet AB:CD:EF:12:34:56
Finally, you can complete this line by setting up the static IP address that you want to assign to the DHCP client computer:

     fixed-address 10.11.12.13
   }
Save your changes to the /etc/dhcpd.conf configuration file. Restart the DHCP server daemon with the following command:

# service dhcpd restart
Now proceed to the DHCP client, the precious.example.com computer. You can release any current DHCP client with the following command:

# dhclient -r
Finally, you can see if the DHCP client actually takes the static IP address from the DHCP server with the following commands:

# dhclient
# ipconfig




Lab 4
4.  
Your network has more than 500 hosts with users in three major groups wanting to share their files within their groups. There are also 30 Windows XP clients in the publishing department that cannot use the Linux OS for their proprietary software needs. Everything is time-critical, as the outputs are related to stock quotes and therefore need to be synchronized to the same clock. What should you do?
  


Answers

4.
You need to configure a few services on your central host. NIS can be used to manage all the users so that all hosts use the same user IDs. Then configure a central server with Samba and NFS and sufficient disk space for the four groups, restricting each service to members of each group only. Use NTP to synchronize the NFS server to an Internet time server, if available, and then have all the other hosts synchronize their time to the NFS server host on an hourly basis. As NIS is covered in the next chapter, I don't go into additional detail here.

syd168

Lab 1
1.  
You have a growing network of Linux computers, and have to maintain users and passwords on each of these computers on a daily basis. You're having to update administrative files such as /etc/passwd on a number of computers. What can you do to simplify your task?
  


Answers

1.
You can set up an NIS server to maintain a common database of usernames and passwords. This should include at least the basic password database files, such as /etc/passwd, /etc/group, /etc/shadow, and /etc/gshadow, as defined in the /var/yp/Makefile configuration file.

Before you can set up an NIS server, you need to make sure you have the packages that you need, specifically the ypserv and yp-tools RPM packages. You can check and install these packages using the rpm command, as described throughout the book. Once installed, you'll want to start the ypserv service in the /etc/rc.d/init.d directory. You'll also want to use the chkconfig command to make sure this service starts the next time you boot this computer.

You'll need to set up an NIS domain name with the domainname command. You can then configure the NIS master server with the following command:

# /var/lib/yp/ypinit -m
This command assumes the local computer should also be configured as an NIS client on the given network. You're then prompted to enter the hostnames of other computers that you want to add to the NIS domain.

On a larger network, it can be helpful to have a backup for the NIS master server. If the NIS master server hostname is NISmaster, you can set this up with the following command:

# /var/lib/yp/ypinit -s NISmaster
You can then set up clients by configuring the ypbind service on each computer on the NIS domain. Make sure that the ypbind service starts the next time each computer restarts with a command such as:

# chkconfig --level 35 ypbind on




Lab 2
2.  
You want to set up a RHEL 3 computer as a secure Web server. To keep that system secure, you'll want to configure an appropriate firewall, and disable any services that you don't need. What should you do?
  


Answers

2.
If you want to set up a RHEL 3 computer as a secure Web server, it's a straightforward process. You'll want to set up a firewall to block all but the most essential ports. This should include TCP/IP ports 80 and 443, which allow outside computers to access your regular and secure Web services.

The easiest way to set this up is with the text-mode Red Hat Security Level configuration tool, which you can start with the lokkit no change to this in RHEL?or redhat-config-securitylevel-tui commands (lokkit is now a 'front-end' to redhat-config-securitylevel-tui). Once you're in the Red Hat tool, take the following steps:

Enable the firewall. This configures a basic set of firewall rules that prohibits access except for requests that come from inside the firewall.

Click Customize. This opens the Firewall Configuration - Customize window. In the Allow Incoming section, activate the WWW (HTTP) option. This allows outside access to your regular Web site.

In the Other Ports text box, type the following, which opens the ports associated with a standard secure Web service:

443:tcp,443,udp
Click OK. Click OK again to exit from the Firewall Configuration tool.

Enter the following command to check your resulting firewall.

# iptables -L
Once you've configured a Web service as described in Chapter 7, you'll be able to access both the regular and secure Web servers from remote computers.



Lab 3
3.  
You want to make sure even the root user has to enter the root password when opening Red Hat administrative tools. You can do this by modifying the appropriate file in the /etc/pam.d directory. Try this out with the Red Hat Security Configuration tool.
  


Answers

3.
To make lab work, you'll need to modify the Security Level Configuration tool using the redhat-config-securitylevel file in the /etc/pam.d directory. Open this file in the text editor of your choice. The first two commands allow users to start this tool automatically:

auth    sufficient    pam_rootok.so
auth    sufficient    pam_timestamp.so
The first command checks if you're the root user. The second command checks to see if you've opened the given tool recently, based on the conditions of the pam_timestamp module. If you deleted (or commented out) these commands, all users, including the root user, will have to enter the root password when opening this tool. To do so, take the following steps:

Open the Red Hat Security Level Configuration tool in a command line in your GUI. Make sure it opens normally. When it does, close it without making any changes to your current firewall.

Back up the current PAM module for the Security Level Configuration tool to your home directory:

# cp /etc/pam.d/redhat-config-securitylevel ~
Open the file in /etc/pam.d in the text editor of your choice. Comment out the first two commands in this file.

Save the file. If you're not already logged into the GUI as the root user, log out of the GUI. Log back into the GUI as root.

Try opening the Red Hat Security Level Configuration tool. Click Main Menu | System Settings | Security Level. What happens?



Lab 4
4.  
In this lab, you'll see how you can limit access to specific users through the PAM listfile module. In this lab, you'll limit access to the Secure Shell that's covered in Chapter 11. Assume that you have four users on your system: michael, donna, randy, and nancy, and want to limit access to randy and nancy. What do you need to do to make this happen?
  


Answers

4.
To limit access to a PAM configured tool to specific users, you need a bit of help from the PAM listfile.so module, /etc/security/pam_listfile.so. With the following steps, I'm assuming that you need to configure the four specified users; you can configure existing users of your choice.

Create the users michael, donna, randy, and nancy. Set up passwords for these users. There are a number of ways to do so; I believe the simplest is with the following commands. Naturally, you'll need to enter an appropriate password for each user when prompted.

# useradd michael; passwd michael
# useradd donna; passwd donna
# useradd nancy; passwd nancy
# useradd randy; passwd randy
Navigate to the /etc/pam.d directory. Look to see if the sshd file exists; if not, you'll have to install it from the openssh-server RPM. While the technique is described in Chapter 11, it is no different from the technique used to install other services throughout this book. It should already be installed by default on a RHEL 3 server computer.

Open the /etc/pam.d/sshd file in the text editor of your choice. By default, the first two commands should look like:

auth required   pam_stack.so service=system-auth
auth required   pam_nologin.so
After the final auth command, enter the auth command that you need to point to a file with allowed users. (You could certainly use the sense=deny switch and configure a file with disallowed users.)

auth required pam_listfile.so onerr=succeed item=user \
sense=allow file=/etc/special
Since you want users nancy and randy to have access to the Secure Shell service, you'll want to add their usernames to the /etc/special configuration file, one username per line.

Try logging into the Secure Shell service with a prohibited username such as michael:

# ssh michael@localhost
If you haven't logged into the Secure Shell service before from this computer, you'll be prompted to verify the authenticity of the unknown computer. Since it's the local computer, you can assume it's reasonably safe; type yes and press ENTER.

Enter user michael's password. What happens? Can you get access?

Press CTRL-C to exit from the Secure Shell login process. Try again with donna's username and password. What happens? Is this what you expected?

Try again with the allowed users.

What happens if you return to the /etc/pam.d/sshd file and change sense=allow to sense=deny?



Lab 5
5.  
You want to set up Telnet service on your internal LAN, accessible only to one specific IP address. You want to block access from outside the LAN. Assume that your LAN's network address is 192.168.1.0, and the IP address of the computer that should get access is 192.168.1.33. For the purpose of this lab, feel free to substitute the IP address of a second Linux computer on your network. What do you do?
  


Answers

5.
When you set up any xinetd service such as Telnet, there are several steps in the process. You'll need to modify the xinetd Telnet configuration file, and set up filtering in one of three ways: in the /etc/xinetd.d/telnet configuration file, through tcp_wrappers, or the appropriate firewall commands:

First, you want to enable Telnet. Make sure that the krb5-telnet RPM is installed.

Activate Telnet. Use the chkconfig telnet on command to revise the /etc/xinetd.d/telnet configuration script.

Edit the /etc/xinetd.d/telnet configuration file. Add the only_from = 192.168.1.33 line. (If you have another computer on your network with a private IP address, substitute accordingly in all steps in this lab.)

Save the configuration file and reload the xinetd service script with the service xinetd reload command. Try accessing Telnet from the local computer. What happens?

Try accessing Telnet from the computer with the IP address of 192.168.1.33. What happens? Try again from a different computer on your LAN.

Restore the previous /etc/xinetd.d/telnet configuration file. Don't forget to reload the xinetd service script with the service xinetd reload command.

Edit /etc/hosts.deny. Add the telnetd : ALL EXCEPT 192.168.1.33 line.

Try accessing Telnet from the computer with the IP address of 192.168.1.33. What happens? Try again from a different computer on your LAN.

Restore the previous /etc/hosts.deny file.

Save any existing iptables chains. Back up /etc/sysconfig/iptables, if that file currently exists to ~/bak.iptables.

Flush current firewall rules with the iptables -F command.

Block the Telnet port, 23, for all IP addresses except 192.168.1.33 with the iptables -A INPUT -s ! 192.168.1.33 -p tcp --dport 23 -j DROP command.

Try accessing the Telnet server from the computer with the IP address of 192.168.1.33. What happens? Try again from a different computer on your LAN.

Flush current firewall rules with the iptables -F command.

Restore any previous firewall rules with the iptables-restore < ~/bak.iptables command.

Bonus Lab: Repeat these commands for other services and networks.



Lab 6
6.  
You want to set up a secure Web server on your corporate LAN that supports inbound requests from your LAN and the Internet, but you do not want any of these requests from the Internet to get into your intranet. What can you do?
  


Answers

6.
Scenario 1: Cost is not an object. This means you can build a DMZ using two firewalls and a separate Web server, all running Linux. You should have the Web server dedicated only to the Web. You configure two more Linux hosts, each with two network cards, and essentially isolate the intranet behind one firewall. You then put the Web server in the middle, placing the second firewall between the Web server and the Internet. You configure the firewall on the intranet with IP masquerading to ensure anonymity for all your intranet hosts.

Scenario 2: You have one old computer available, and the Web server is a separate computer. Use your one computer as the firewall between you and the Internet and only forward HTTP packets to the Web server IP address directly; use NAT for all intranet requests going out to the Internet for HTTP and FTP. Disallow all other services.

syd168

Lab 1
1.  
In this lab, you'll create a private directory for a group of engineers designing some galleys. You'll want to create a group named galley for the engineers named mike, rick, terri, and maryam. They'll want to share files in the /home/galley directory. What do you need to do?
  


Answers

1.
This is a straightforward process, using the following basic steps:

Create accounts for mike, rick, terri, and maryam if required. You can use the useradd command, edit the /etc/passwd file directly, or work through the Red Hat User Manager.

Set up a group for these users. Configure a group ID outside the range of your regular users with a line such as:

galley::10000:mike,rick,terri,maryam
Create the /home/galley directory. Give it proper ownership and permissions with the following commands:

# mkdir /home/galley
# chown nobody.galley
# chmod 2770 /home/galley



Lab 2
1.  
In this lab, you'll configure the tmpwatch script in /etc/cron.daily to delete files from the /var/log/httpd directory on a periodic basis. You're doing this because the data that comes through your Web server is overwhelming your system. Unless you delete older files from this directory on a periodic basis, the data will crowd out the space needed by your users. Presumably, you're doing this until your new hard disk array is ready in a few weeks.
  


Answers

1.
In this lab, you'll want to set up a command in the tmpwatch script in the /etc/cron.daily directory, which deletes files that haven't been accessed for a certain number of hours. The commands in the default version of this script can help guide you in this process. For example, if you wanted to delete files that haven't been accessed in more than 30 calendar days, you just need to translate this into the equivalent number of hours. Thus, all you need to do is add the following command to the noted script:

/usr/sbin/tmpwatch 720 /var/log/httpd



Lab 3
1.  
For this exercise, use a test computer. Do not use a production computer. Do not use a computer where any data might be important to you. If something goes wrong, and you are unable to restore from a backup, you may need to reinstall Linux. This exercise assumes that you're using the default Red Hat Enterprise Linux boot loader, GRUB.

Navigate to the /boot directory. Change the name of the initrd-versionnumber.img file. Make sure it's something easy to remember such as initrd-versionnumber.bak. Reboot Linux. As GRUB goes through the boot sequence, it will probably stop when it can't find your Initial RAM Disk (initrd) file, similar to what is shown in Figure 11-14.


Figure 11-14: A boot failure
Now that your boot loader isn't working, what do you do? Can you try to start Linux in single-user mode?
  


Answers

1.
As you practice learning about Linux for the RHCE exam, it's important to know how GRUB works. By default, it requires an initial RAM disk file, initrd-versionnumber.img. If GRUB can't find this file, it'll give you the error shown in Figure 11-14. Since your computer does not boot, you'll need to boot with a rescue disk before you can fix the initrd file. Remember to make sure that the filename matches the name shown in /boot/grub/grub.conf exactly.

You can repeat this process with the vmlinuz file or the root directive in grub.conf. Make sure to have backups of key files so you can restore your original configuration. When you repeat this process, what happens after you select a kernel from the GRUB menu? Do you see a different error? Is it associated with a different file?

Understanding these answers can help you learn to use GRUB messages to better diagnose specific problems with Linux.



Lab 4
1.  
Your company bought another competitor on the opposite coast recently, just as the new corporate application was being deployed everywhere, so you sent the app to them, too. They use a Unix host for this application on their network. You need to be able to connect to this host for maintenance purposes on the new system-wide application you deployed. Both networks have Internet access.
  


Answers

1.
If you need access now, and both systems are connected to the Internet, you can set up SSH for secure communications. If the other network does not already have it installed, have them download it from the Internet, install it, and then create an account for you.

The basic steps which are outlined here may vary with the version of Unix used on the other network.

Get the OpenSSH utility source from the Net and put it into a specific directory. Since RPMs are not yet made for Unix, you'll need to unpack a 'tarball.' You can then unpackage the files in the tarball and use the files in the resulting directory to compile and configure a Secure Shell server. Once it is configured, set up private and public keys.

If you don't need immediate access, you could, alternatively, configure a computer with Linux and a Secure Shell server. Send the computer to the administrator of the remote Unix network. Have them add it to their network, and you can check the problem from your site securely. The application is running on the Linux computer that you sent. (Alternatively, you can even set up OpenSSH on Microsoft Windows, as described earlier in this chapter.)



Lab 5
1.  
In this lab, you'll create new PEs, and use them to increase the size of a configured LV. You're doing this for the LV used by the /var directory. Because of the increasing demands of your Web site, you need more room for the /var directory for your Web site data. Assume your /etc/fstab configuration file includes the following line:

/dev/Volume00/LogVol00  /var   ext3   defaults   1 2
You've created PEs from the /dev/sde and /dev/sdf hard drives, and have just added another SCSI hard drive, /dev/sdg. Assume you've backed up the data that you need from the /var directory.
  


Answers

1.
If you've just added the new hard drive, you'll need to set up partitions or use the entire hard drive for PEs. Based on the premises of the lab, you have the entire SCSC /dev/sdg hard drive available, so you can just allocate this entire hard drive as PEs with the following command:

# pvcreate /dev/sdg
The next step is to extend the VG, Volume00, to include the newly configured PEs. You can do so with the following command:

# vgextend Volume00 /dev/sdg
With the additional PEs at your disposal, you can increase the size of the LV allocated to the /var directory. For example, if you wanted to increase the size to 2GB, you could run the following command:

# lvextend -L2G /dev/Volume00/LogVol00