Lab Questions


Lab 1

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 securely for maintenance purposes on the new system-wide application you deployed. Both networks have Internet access.

What do you do?

image from book

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 the administrator in the remote location download and install it, and then create an account for you.

The basic steps outlined here may vary with the version of Unix used on the other network. If it's Red Hat Enterprise Linux, all you need are the SSH packages described in this chapter, but you may not have that luxury.

Download the source code for OpenSSH and put it into a specific directory. Assuming your version of Unix can't handle RPMs, 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, you have the option to set up private and public keys.

If you don't need immediate access, you could, alternatively, configure a computer with Red Hat Enterprise Linux and a Secure Shell server. Send the computer to the administrator of the remote Unix network. Have the admin add it to his or her 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 set up OpenSSH on Microsoft Windows, as described earlier in this chapter.)

Lab 2

2. 

You'll also need two Linux computers for this lab: one as a DHCP server and 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.

image from book

Answers

2. 

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:

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

  2. Set up a new host in the DHCP configuration file:

        host precious { 

  3. 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, substitute the hardware address of your own card for AB:CD:EF:12:34:56 in the following command line:

             hardware ethernet AB:CD:EF:12:34:56 

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

  5. Save your changes to the /etc/dhcpd.conf configuration file. Restart the DHCP server daemon with the following command:

        # service dhcpd restart 

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

        # dhclient -r 

  7. Finally, you can see whether the DHCP client actually takes the static IP address from the DHCP server with the following commands:

        # dhclient    # ifconfig 

Lab 3

3. 

To do this lab, you'll need the help of a partner. Have him or her set up your system as described in the answer to this lab in the next section. The intent of this lab is to help improve your troubleshooting skills for the Troubleshooting and System Maintenance section of the RHCE exam.

image from book

Answers

3. 

Lab 3: Part 1

You're going to set up this lab for your partner (I've set up these "answers" in a different order, first the setup of the lab, to help discourage "shoulder surfing"), using the following steps:

  1. Make sure your system supports the SSH service, is active, and includes an account for your partner's username and password. If the password is secret, let your partner enter the password.

  2. Take over your partner's RHEL system. Make sure there's a connection between your computers.

  3. Configure the SSH service as described in this chapter. If you have a firewall configured on this system, make sure to open port 22 to allow communication to the local SSH service. You can use the Red Hat Security Level configuration tool described in Chapter 15 to help.

  4. Modify the SSH server configuration file to allow users, not including the regular username for your partner. As described in this chapter, this involves the AllowUsers directive in the /etc/ssh/sshd_config file.

  5. Don't forget to make the sshd service reread the configuration file with a command such as service sshd reload.

  6. Pass your partner's system back to him or her. Instructions for your partner can be found in Part 2 of Lab 3.

Lab 3: Part 2

  1. Take your system back from your partner. Log in as a regular user. Use the ssh command to log into your partner's system under your username. Repeat the process to log back into your own system. What happens?

  2. Return to your own system. Analyze the logs. What do you see? Is there anything special in /var/log/secure?

Lab 4

4. 

This lab includes a matching scenario to Lab 3 for your partner. Refer to the "Lab Answers" section for what you need to configure.

image from book

Answers

4. 

Lab 4: Part 1

  1. Make sure your system supports the SSH service, is active, and includes an account for your partner's username and password. If the password is secret, let your partner enter the password.

  2. Take over your partner's RHEL system. Make sure there's a connection between your computers.

  3. Configure the SSH service as described in this chapter. If you have a firewall configured on this system, make sure to open port 22 to allow communication to the local SSH service. You can use the Red Hat Security Level configuration tool described in Chapter 15 to help.

  4. Modify the SSH server configuration file to prohibit logins by the root user. As described in this chapter, this involves the PermitRootLogin no directive in the /etc/ssh/sshd_config file.

  5. Don't forget to make the sshd service reread the configuration file with a command such as service sshd reload.

  6. Pass your partner's system back to him or her. Instructions for your partner can be found in Part 2 of Lab 4.

Lab 4: Part 2

  1. Take your system back from your partner. Log in as a regular user. Use the ssh command to log into your partner's system as the root user. Repeat the process to log back into your own system. What happens?

  2. Return to your own system. Analyze the logs. What do you see? Is there anything special in /var/log/secure?

Lab 5

5. 

This lab requires two Red Hat-capable systems, or at least a second system that you know how to configure as an NTP client. Configure the RHEL system as an NTP server. Allow access on your local IP address subnet. Make sure the service is started and will start the next time you boot Linux.

image from book

Answers

5. 

Before configuring a system as an NTP server, you have to first configure it as a client. The simplest method for doing so is to use the Date/Time Configuration tool, which can be started in the GUI with the system-config-date command.

Once configured as a client, make sure the NTP service is running and set to start the next time Linux is booted on the local system. The simplest method involves the following commands, which should be familiar if you've configured other services on Red Hat systems:

 # chkconfig ntpd on # service ntpd start 

Open the NTP configuration file, /etc/ntp.conf. Add an appropriate restrict directive to open access to other systems. One example suitable for the 192.168.1.0 network is shown in the comments to the file:

 # restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap 

If your LAN uses a different network address and subnet mask, substitute accordingly. If it's an IPv6 network, the directive is restrict -6. After saving the changes, the following command makes NTP reread the service configuration file:

 # service ntpd reload 

Now you can go to the second system and configure its client to connect to the local NTP server that you just created. If you have the Date/Time Configuration tool on that second server, the simplest method is to start it with the system-config-date command and point to the domain name or IP address of the NTP server you just created.



RHCE Red Hat Certified Engineer Linux Study Guide (Exam RH302)
Linux Patch Management: Keeping Linux Systems Up To Date
ISBN: 0132366754
EAN: 2147483647
Year: 2004
Pages: 227
Authors: Michael Jang

Similar book on Amazon
Linux Quick Fix Notebook
Linux Quick Fix Notebook
Self-Service Linux: Mastering the Art of Problem Determination
Self-Service Linux: Mastering the Art of Problem Determination
RHCSA/RHCE Red Hat Linux Certification Study Guide (Exams EX200 & EX300), 6th Edition (Certification Press)
RHCSA/RHCE Red Hat Linux Certification Study Guide (Exams EX200 & EX300), 6th Edition (Certification Press)
Security Strategies in Linux Platforms and Applications (Information Systems Security & Assurance)
Security Strategies in Linux Platforms and Applications (Information Systems Security & Assurance)

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net