Today we continue on disk, volume and partition management, to prepare your system for our first course project. We also practice using sudo and creating new users and groups.
Modify the sudo configuration file to include an entry for your account and to permit it to run the collection of storage commands (there is an alias for them already defined). Verify that it works by executing sudo /sbin/fdisk -l /dev/sda to see the partitions defined on your hard drive.
Now expand the list of commands to include lvs, pvs, and pvresize so that we can use them as well. (We may need to add other commands later.)
Sometimes it is useful to be able to create partitions directly, skipping LVM volumes entirely. Our first goal in this lab will be to shrink the physical volume so that you could create new partitions on your drive. Unfortunately, the pvresize command that existed in LVM1 is not yet implemented in the version of LVM2 that we have on FC4 (there is a development version of LVM2 that does incorporate a pvresize, but it is not directly compatible with FC4). So we need to do this manually.
As you may recall from your readings about LVM, a physical volume is comprised of physical extents (portions of a physical volume that can be allocated to a particular volume group). As we saw above with pvs, there was lots of space free on our only volume group. Since LVM could use any extent (it is not required to use only the lowest-ordered extents), we must first find out where our logical volumes have been allocated (that is, which physical extents are being used).
We can find out what LVM is doing by telling it to create a backup LVM volume group configuration. Run /usr/sbin/vgcfgbackup and it will create the file /etc/lvm/backup/VolGroup00 with human-readable contents.
Examine this file. What you should see is that all of the physical extents used by your logical volumes are packed together at the beginning of the drive except for your original swap space (not the one you created). This is good, because it means that we can truncate this partition without real harm (it is easy to re-create a swap volume).
If we had physical extents in use that correspond to volumes containing data, we would need to move that data to the earliest available extent. The command to do this is pvmove, but it requires spare unallocated physical extents for temporary use, which we don't have unless we were to add another drive. (Actually it is possible that pvmove can do what we need using the 'anywhere' allocation policy, but I haven't tested that.)
So let's remove the problem volume. First, it is in use, so use swapoff to turn off use of that volume's swap space. Then use lvremove to remove the logical volume from the volume group. (We don't really need more than 2GB swap anyway.) Now re-run vgcfgbackup to update your backup file.
Now we want to see how many extents are currently free. Run pvs -o +dev_size --units s to see how much space is used and free on your volume in units of sectors (512B). Sectors are also the units used in /etc/lvm/backup/VolGroup00 (if you multiply the extent_size by 512, you get the size mentioned in the comments). So, if you divide the number of sectors free by the number of sectors in an extent, you get the number of extents free.
Let's choose to make 10GB available for new partitions (leaving plenty of room for new volumes within the existing volume group). So calculate the number of extents in 10GB, and subtract it from the number of extents in the pe_count line of your physical volume. That is the number of the last extent that you want this physical volume to occupy instead of something that spans a little over 37GB.
Edit this backup configuration file to reflect what you want (that is, change the pe_count line). Now run /usr/sbin/vgcfgrestore to get LVM to change its configuration to match this backup file. Running pvs again will show the change as already in effect.
At this point, LVM is now convinced that it has a little over 27GB in its volume group (within /dev/sda3) but the disk partitioning does not yet reflect it. Run fdisk again to see that the partitions have not changed.
What we need is to resize the /dev/sda3 partition. While the GNU parted program could do this, it will complain that it does not recognize the filesystem on the partition (it does not understand LVS). We can still use parted to accomplish our goal. Run parted on the drive. At the parted prompt, type print to list the partitions that it sees. We are going to replace the existing sda3 partition with a smaller one. Use the rm command to delete the 3rd partition. Then use mkpart (not mkpartfs) to create a new one that leaves 10GB free. Note that mkpartfs would install a filesystem on the new partition (overwriting our existing filesystem!). Check the revised partition table with print, and notice that the new (smaller) partition does not have a filesystem or any flags. The one we removed had the lvm flag. Now use the set command to set the lvm flag. That's it! You can now quit. While parted does not require rebooting after these changes, you might want to do so to verify that everything is still functional.
Create an account for a friend using useradd and passwd. Notice that it automatically created a home directory and a personal group in /etc/group. Look at the password you created in /etc/shadow to see whether it is md5 or not. How can you tell?
Establish an account for me, called prof, with the specific password: $1$CSsB/eja$vzZeRFYIFk3YVTwOjznLy/ so that I can log in with a password that I know. Create a new entry in /etc/group for a new group, and add your personal account and the prof account to it. Verify that your account now is in two groups using the groups command.
Start the firefox browser. From a shell, use ps aux to find the PID for firefox. Now use the kill command to stop the firefox process; what happens when you move the firefox window around or click on its menus? Now send it the continue signal, and notice that it recovers. This is essentially the same situation if you were to press ctrl-z at a shell that is currently running some program (like emacs) which then stops functioning (because it has been suspended).
Log in as root. Use crontab -e to create and edit a crontab file for root. Add a crontab entry that will run the uptime command every minute for today only, and capture the output by appending to a file in /var/log. For example,
Then save and quit your editor. Later in the lab, take a look to see the results in this log file.
Look in /var/log/cron to see what cron has been doing. What scripts are run daily?
In order to sign the lab completion sheet, you will need to:
If you have time, you might start working on homework #3.