You shouldn't read this discussion until you've had a chance to try out the problems. I describe one possible solution to each problem. The solutions that you come up with can vary. The method you use doesn't matter; the result is what counts. As of this writing, in the Troubleshooting and System Maintenance section, you can't reinstall RHEL on the target computer and you can't go to the Internet for help during the exam.
To pass either exam, you need to solve all five RHCT-level Troubleshooting and System Maintenance problems. In this simulation, you'll need to
Allocate half of the free space on the current drive to a partition dedicated to the /test directory.
Make Linux boot into the GUI.
Address any problems you see the next time you boot Linux.
Configure the GNOME desktop to open a command line window for the selected user when you boot.
Assign a host name of enterprise5 to this system, and configure the network card to connect with DHCP.
Address the problems that you've been given. In most cases, there are other ways to solve these problems. When you boot this system, the first thing you'll see is this:
You may already recognize this as the root prompt associated with runlevel 1. But you need to make Linux boot into the GUI, which means you need to make Linux boot into runlevel 5. And this is controlled in /etc/inittab, with the following directive:
Now you can reboot, or just run init 5 to move to that runlevel. But when you do, you'll see error messages related to the X Window, and are prompted for the root password to try to "fix" the problem. There's a key hint after you enter the password:
Data incomplete in file /etc/X11/xorg.conf Undefined Screen "Screen" referenced by ServerLayout "Default Layout"
This suggests an error in the ServerLayout stanza in /etc/X11/xorg.conf. You could solve the problem here, but you're taken to the Display Settings Configuration tool, which is probably the quickest way to solve the problem. If successful, you'll see the GUI login screen.
When you log in, you'll see the Firefox Web browser. You could remove that from the applications that are automatically opened; all you need to do is make sure that a command line terminal is open. User applications in the GNOME desktop are driven by the GNOME Sessions tool and any existing .xinitrc file in that user's home directory. Add the command line terminal of your choice; the default for GNOME is gnome-session; xterm and konsole, if installed, are acceptable alternatives.
The simplest way to configure a host name and set networking to get address information from a DHCP server is with the GUI Network Configuration tool. You can also do this in /etc/sysconfig/network, /etc/hosts, and associated ifcfg-eth0 scripts.
Finally, to allocate free space to a new partition, you'll need to use the fdisk or parted utilities to create the partition, make sure it's the appropriate Linux file type, format it with a command such as mkfs.ext3, mount it to make sure it works, and add an appropriate directive to /etc/fstab to make sure it's mounted on /test the next time you boot Linux.
You'll see what's wrong when you try to log into RHEL. Be prepared to use the first RHEL installation CD to rescue this system. If you get instructions for a network source for the RHEL installation files, take careful notes. You've been told the following:
You will face a challenge during the boot process.
You'll want to make sure /boot is properly mounted.
You'll need to reduce the space available to the /tmp filesystem on a logical volume.
Make sure the NFS, sendmail, Apache, and vsFTP services are working and available to other systems.
(Yes, I know that's more than five problems.)
When you see your boot loader, probably GRUB, select your current version of RHEL.
Boot your RHEL computer. Watch the start messages carefully. In this case, you'll see the following messages, which could intimidate most Linux administrators:
setuproot: moving /dev failed: No such file or directory setuproot: error mounting /proc: No such file or directory setuproot: error mounting /sys: No such file or directory Kernel panic - not syncing: Attempted to kill init!
Look at these messages carefully. If you're experienced with Linux, you'll recognize that RHEL experienced a kernel panic because it had trouble finding key directories. That suggests problems with the root directive in the GRUB configuration file.
Restart your computer. Insert the first RHEL installation CD, and set your computer to boot from this disk. At the installation prompt, type linux rescue. This assumes you have access to your installation source, just in case you need to reinstall the Linux kernel.
Proceed as if you're installing RHEL. Set up networking when prompted, as you may need access to some of the installation RPMs.
When you see the Rescue screen, click Continue. If it doesn't work, all that means is that Linux is having trouble mounting your system in read-write mode. In that case, you can select one of the other two options.
If successful, you'll see a note that your system has been mounted under /mnt/ sysimage. Click OK, and then run the chroot /mnt/sysimage command at the prompt.
Look for the /boot directory. You won't see anything there, which suggests that it wasn't mounted. So use a command like fdisk -l to review configured partitions, to find a logical candidate for /boot, and mount it. Just as one example, I show the result from my VMware system-your output is likely to be quite different:
Disk /dev/sda: 5368 MB, 5368709120 bytes 255 heads, 63 sectors/track, 652 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/sda1 * 1 14 104391 83 Linux /dev/sda2 2677 652 5132767+ 8e Linux LVM
In this case, as the /boot directory can't be mounted on a logical volume, the only partition that could include the /boot directory files is /dev/sda1. So I follow up with this command (of course, if your system is different, substitute accordingly; if there are multiple possible /boot partitions, some trial and error may be required):
# mount /dev/sda1 /boot
Now you should be able to find the GRUB configuration file. As suggested earlier, there's a problem with the root directive:
If you're as familiar as you should be with the GRUB configuration file, you'll see the error right away. The root directive in this line should point to the device associated with the top-level root directory. You'll find it in /etc/fstab:
/dev/VolGroup00/LogVol00 / ext3 defaults 1 1
This tells me what should be associated with the root directive:
If the root directive in the GRUB configuration file is associated with a partition device, you might see something like LABEL=/ in /etc/fstab. In that case, you'd substitute the following:
Alternatively, if you can't figure out the LABEL (with a command like e2label /dev/hda1), and the top-level root (/) directory is not on a logical volume, a LABEL may not have been assigned; just substitute the appropriate partition name:
Yes, you could also test this from the GRUB command line, as described in Chapter 3. But for this exercise, just reboot and see what happens. In rescue mode, type exit to get out of the chroot command, and then type the exit command again to reboot.
If you reboot, you'll note that the /boot directory still doesn't get mounted. Remember how mounting works-it depends on /etc/fstab. If you're observant, you'll see the directive associated with the /boot directory commented out. When you activate the command, /boot is mounted the next time you start this system. Alternatively, you can mount everything in /etc/fstab with the mount -a command.
At this time, make sure the noted services are active with a command like this:
# /etc/init.d/nfs status
When you see that NFS, vsFTP, Apache, and sendmail are not active, you could activate them and try rebooting. But if you're observant, you'll run a command like this:
# chkconfig --list httpd httpd 0:off 1:off 2:on 3:on 4:on 5:on 6:off
You'll see that it's supposed to be on. This suggests another problem. If you know how the boot process works, you'll trace your way through /etc/inittab, and find the following problem directives:
id:4:initdefault: #l4:4:wait:/etc/rc.d/rc 4
These suggest that this configuration uses a non-standard runlevel, and since the script that starts services is commented out, no services in that runlevel are started. So all you absolutely need to do is change the default runlevel.
Modify /etc/inittab to reflect an appropriate default runlevel, such as 5, and reboot. You'll see the desired services running now.
To make sure the noted services are available, run commands such as this:
# service httpd status
Make sure the noted services are available to others. Make sure SELinux is active, and open up access through a firewall. It's easiest to do both with the Security Level Configuration tool, which now allows you to create access to all the noted services.
If there are SELinux-related problems, they'll be shown with the SELinux troubleshooter, which can be started in the GUI with the sealert -b command. When there are problems, this tool often suggests solutions. If you have access to a remote system, say via SSH, it's best to log into the remote system. Then you can make sure you (and others on the network) have remote access to the noted services.
Finally, to reduce the amount of space available to a volume, you'll first need to back up the information in that volume. The ext2online command has been replaced with resize2fs, which can reduce the size of a volume. Alternatively, you can also back up the information on /tmp, unmount that directory, reduce the number of LV extents on the associated volume, remount /tmp, and restore the information. The key command is lvreduce; for example, the following command reduces the allocation for the noted volume to (approximately) 50MB:
# lvreduce -L 50M /dev/vgrp0/lvol0/