Lab Questions | Linux Patch Management: Keeping Linux Systems Up To Date

Lab 1

In this lab, you'll deliberately misconfigure your network card, observe the results, and see what you can do to restore the original configuration. I assume that you have a computer on a network, as that is a basic requirement of the Red Hat exams. If you have more than one network card, make sure you select the card that you use to connect to outside networks.

This lab assumes a basic understanding of IPv4 network addresses. It also assumes that you have a DHCP server on your system. (For now, it doesn't matter what operating system has the DHCP server; many home routers serve this purpose.) To prepare this lab, take the following steps:
1. Boot your system into a standard runlevel with networking, 3 or 5.
2. Inspect the current configuration of your network card with the ifconfig command. Inspect the current routing table, as specified by the route -n (or netstat -nr) command. If you have several network devices, find the device associated with your gateway.
3. Select the network device that connects to external networks, such as eth0. Change the IP address to a private IPv4 address on a different network. If you have multiple network cards, make sure the new address does not correspond to any existing network.
4. Confirm the change by running ifconfig again.
5. Try the ping command to the new IP address.
6. Try the ping command to an IP address on an external computer. It doesn't matter if the external computer is on a local network or the Internet. What message do you see?
7. Run the ping command to a host name of an external computer. It doesn't matter if the external computer is on a local network or the Internet. What message do you see?
8. Run the route -n command again. Is there a default route?
9. Assuming the network device you've changed is eth0, run the dhclient eth0 command. What do you see? Run the ifconfig command again. Has the IP address changed?
10. Search through active processes for the dhclient command. What did you find?
11. Kill any active dhclient command process.
12. Apply the dhclient command to the target network device.
13. Redo step 2. What happened to the routing table? What about your network interface?

Answers

This set of "answers" explain what you might expect during each step.
1. The standard runlevel for console logins is 3; the standard runlevel for GUI logins is 5. To boot into the runlevel of your choice, press a key when you see "Booting Red Hat Enterprise Linux 5 …": press P and enter the GRUB password if required, and press A to modify the kernel arguments. (This works only on a non-Xen kernel option.) You can then specify the boot runlevel by adding it to the end of the kernel command line.
2. If you have several network devices, you can focus by specifying a device with a command such as ifconfig eth0. The route -n command should collate connected networks with the appropriate network device (netstat -nr works just like route -n).
3. Make sure the IP address you select is on a different network. It's best if you use private IP addresses. Some address ranges are listed in Chapter 1.
4. When you run ifconfig again, you'll see the change you made.
5. When you try the ping command to the new IP address, it should work.
6. When you try the ping command to an IP address on an external computer, you'll see an error such as:
```
 connect: Network is unreachable 
```
7. When you run the ping command to a host name of an external computer, you'll see a message similar to:
```
 ping: unknown host www.yahoo.com 
```
8. When you run the route -n command again, you'll see that the default router is no longer listed there.
9. When you try the dhclient eth0 command, you may not see a response. And the IP address won't have changed.
10. To search through active processes for the dhclient command, run ps aux | grep dhclient. It should identify the process identifier for dhclient.
11. To kill an active dhclient command process with a PID of 111, use the kill 111 command.
12. Now you should be able to apply the dhclient command to the target network device, and you'll see messages as it finds your DHCP server.
13. Finally, you'll find an appropriate IP address for your network interface and the original routing table.

Lab 2

In this lab, you'll want to use the Red Hat Printer Configuration utility to connect a printer to your Linux system. The printer can be local or remotely connected through your LAN. As you'll want to create a printer class, you'll need more than one printer. (Hint: You can configure the same printer as many times as necessary, as long as you use different names.)

If you have only one physical printer, you can set up multiple print queues with different printer names. CUPS sees each print queue as if it were a separate printer.

Once you've created multiple printers, return to the Printer Configuration tool. Run the system-config-printer command in a GUI. Navigate to http://localhost:631. Click Add Class. Follow the prompts to create a printer class with the printers that you've configured.

Once you've created a new printer class, inspect the result in the /etc/cups/classes.conf configuration file. Check the contents of your /etc/printcap and /etc/printers.conf files. What are the names of the printers that you see? Do you see any surprises in the list?

If you have a Microsoft Windows computer on your network, activate the Samba service if required. Check the printer names as shown in the browse list. Do you see any surprises on this list? (For more information on Samba, see Chapter 10.)

Answers

Starting the Printer Configuration utility is easy. One way in the GUI is to press ALT-F2 and then type system-config-printer in the text box that appears. Then you can click the New Printer button to start a configuration wizard. If you like, you can create different print queues for the same printer. Just repeat the same process, using a different printer name.

When you've created two or more printers, click New Class. This starts a similar configuration wizard, where you can collect preconfigured printers of your choice in a print class. As with new printers, a print class requires a name, description, and location.

Click Forward; select more than one computer as members of the printer class. Click Forward; once your new printer class is confirmed, click Apply.

You should now see the printer class and member printers in the /etc/cups/classes.conf file. You'll find a list of printers in /etc/printcap; you'll find the names of any configured printers and printer classes in this file. You should also see the list of printers in /etc/printcap in any Microsoft Windows Network Neighborhoods or My Network Places that is connected to the same network. This assumes that you've activated a Samba server on the local print server computer, of course.

Lab 3

As the root user, create jobs that change the login message for users at the text console. To do so, you'll want to change the content of /etc/motd. Make sure that people who log in at different times get appropriate messages:

If users log in between 7 A.M. and 1 P.M., create the login message "Coffee time!"
If users log in between 1 P.M. and 6 P.M., create the login message "Want some ice cream?"
If users log in between 6 P.M. and 7 A.M., create the login message "Shouldn't you be doing something else?"

Answers

To modify the login messages as noted, take the following steps:

Log in as the root user.
Run the crontab -e command.
Add appropriate environment variables, at least the following:
```
 SHELL=/bin/bash 
```

Add the following commands to the file to overwrite /etc/motd at the appropriate times:

 00 7   * * * /bin/echo 'Coffee time!' > /etc/motd 00 13  * * * /bin/echo 'Want some ice cream?' > /etc/motd 00 18  * * * /bin/echo 'Shouldn't you be doing something else?' > /etc/motd

Save the file. As long as the cron daemon is active (which it is by default), the next user who logs into the console should see the message upon a successful login. If you want to test the result immediately, the date command can help. For example, the following command

    # date 06120659

sets a date of June 12, at 6:59 A.M., just before the cron daemon should execute the first command in the list. (Of course, you'll want to substitute today's date.)

Lab 4

In this lab, you'll find the value of several different log files. In preparation, use the wrong password to log into a regular account. Then take the following steps:

Navigate to /var/log as the root user.
Explore the contents of the anaconda.* log files.
Run the utmpdump btmp command. Do you see the login attempt? Can you tell if it succeeded?
Review the contents of the cron log file. Scroll through it. If your computer has been on for a while, most of what you see will be based on the run-parts /etc/cron.hourly command. Alternatively, if you reboot on occasion, you'll see messages associated with the anacron service.
Review the contents of the dmesg log file. Compare the beginning of it with the start of the anaconda.syslog file. Which one includes the currently booted kernel?
Navigate toward the bottom of the dmesg file. Can you identify the amount of swap space? What about one or more partitions with the default EXT3 filesystem?
Review the maillog log file. Do you see any messages associated with mail messages? If there are a lot of messages associated with the root account, run the mail command (to exit from the mail prompt [&], press CTRL-D).
Review the secure log file. Navigate to the bottom of the file. Do you see a message associated with the failed login?
Finally, review the Xorg.0.log file. Do you see any messages related to the mouse (or other pointing device) near the end of the file? How does that work when you didn't configure a pointing device during the installation process?

Answers

There are no secret solutions in this lab; the intent is to get you to review the contents of key log files to see what should be there.

When you review the anaconda.* files in /var/log and compare them to other files, you may gain some insight on how to diagnose installation problems. In future chapters, you'll examine some of the log files associated with specific services; many are located in subdirectories such as /var/log/samba/ and /var/log/httpd/.

The failed login should be readily apparent in the /var/log/secure file. You may be able to get hints in the output to the utmpdump btmp command.

When you review the /var/log/cron file, you'll see when standard cron jobs were run. Most of the file should be filled (by default) by the standard hourly job, run-parts /etc/cron.hourly, from the /etc/crontab configuration file. If you've rebooted, you may see the anacron service, and you should be able to search for the job of the same name.

While /var/log/dmesg includes the currently booted kernel, it may be the same kernel as the one associated with /var/log/anaconda.syslog, if you haven't upgraded kernels. At the end of /var/log/dmesg, you can find the filesystems mounted to the EXT3 format, as well as currently mounted swap partitions. For example, the following lists swap partitions that happen to be on two different hard drives:

    EXT3 FS on sda9, internal journal    EXT3-fs: mounted filesystem with ordered data mode.    Adding 979956k swap on /dev/sda3. \    Priority:-1 extents:1 across:979956k    Adding 2031608k swap on /dev/VolGroup00/LogVol01. \     Priority:-2 extents:1 across: 2031608k

As you've hopefully discovered, the /var/log/maillog file does not include any information on mail clients, but only servers.

Red Hat used to include a mouse configuration tool. The automatic configuration for pointing devices is now sufficiently reliable; input device information is automatically added to the xorg.conf configuration file and included in the X Window as shown with <default pointer> messages in the /var/log/Xorg.0.log file.

The three directives typically found in the /etc/sysconfig/network file are NETWORKING, NETWORKING_IPV6, and HOSTNAME. If you allow a DHCP server to assign host names, the HOSTNAME directive isn't required.
The command that assigns an IP address of 192.168.99.44 to an eth1 network card is
```
 # ifconfig eth1 192.168.99.44 
```
The command that returns the current routing table is
```
 # route -n 
```
The netstat -nr command works as well.
The command that deactivates the eth0 network device is
```
 # ifconfig eth0 down 
```
Alternatives are available, such as ifdown eth0.