On my home workstation, I used LVM for the one 160GB hard drive. When I first built the box (in May of 2004), I installed Fedora Core 2 for x86_64; it's a dual AMD Opteron 242 (1.6GHz). I created four partitions:

1. 100MB /boot/
2. 2GB swap (there's 1GB RAM, but I can expand to 8GB)
3. remainder (~96GB) LVM
4. 60GB Windows XP Professional

For a couple of weeks, I have been unable to install any updates to FC5. When I run yum update, I get a series of error messages telling me that yum needs additional disk space on the root partition in order to install packages. Strangely enough, almost none of those packages have files that end up in the root partition.

The root filesystem was a 512MB ext3 LVM logical volume. Sure, I could make it bigger, but I shouldn't have to. In fact, I should be able to have it be only about 256MB and still have a completely usable system. I have /home/, /tmp/, /usr/, /var/ and even /opt/ all split off onto their own LVs, so there's not that much stuff left on the root volume. In fact, running du -sx / shows that there is just barely 200MB of data present. However, running df / shows that it is 99% full (about 508MB used). Clearly, ext3 is not an efficient choice for a root partition when the bulky filesystems are split out like this.

So, I decided to "convert" to another filesystem type. I chose to use XFS for the root volume. Converting the root partition can be a little bit tricky, as the initrd needs to have the right drivers to work with it. Here's my step-by-step (assuming that the volume group is named system):

1. Create a new volume and format it with the new filesystem type (the size could be smaller, if desired):

   # lvcreate -L 512MB -n newroot system
   # mkfs.xfs /dev/system/newroot
   

2. Mount the new root volume and remount the current root volume read-only:

   # mkdir /mnt/temp
   # mount /dev/system/newroot /mnt/temp/
   # mount -o remount,ro /
   

3. Copy the contents of just the root volume to the new root volume (the -x switch is very important):

   # cp -ax /* /mnt/temp/
   

4. Unmount the new root volume:

   # umount /mnt/temp/
   

5. Run uname -r and record the value. This will be needed later when running mkinitrd.
6. Reboot the system into a rescue environment. In order to be able to boot with the new root partition, it is necessary to recreate the initrd. You could hand edit the existing one(s) to fix things up, but this will be quite a bit easier. Use a CD or a network bootable rescue environment for your distro (FC5 in my case).
7. If you let the setup for the rescue environment mount your partitions/volumes, that's fine, just make sure to unmount everything so you can switch root partitions. If you don't let it mount up the parts, that's fine too; just use the LVM commands for your rescue environment to activate LVM.
8. Rename the old root volume out of the way and rename the new one into place (this only works while the volumes are not mounted):

   # lvrename system root oldroot
   # lvrename system newroot root
   

9. Mount the (new) root volume and at least /boot/ and /usr/ on top of that:

# mkdir /mnt/system/
# mount /dev/system/root /mnt/system/
# mount /dev/sda1 /mnt/system/boot/
# mount /dev/system/usr /mnt/system/usr/

10. It's time to recreate the initrd. This is easiest when done chroot'ed into the system environment found on your hard drive (assuming your new root volume was mounted at /mnt/system/):

    # chroot /mnt/system/
    

11. Run mkinitrd. Depending on which distribution is installed, this could require quite a different set of switches than what I'm showing you here. In my case, it was Fedora, so I used the mkinitrd command found in the /sbin/new-kernel-pkg script, which is run as part of the post-install scripts from every Red Hat kernel RPM (just open up /sbin/new-kernel-pkg and find the right command to run, replacing "something" with the correct kernel version string recorded earlier from the uname -r command):

    # /sbin/mkinitrd --allow-missing -f /boot/initrd-2.6.something 2.6.something
    

12. Leave the chroot environment and unmount everything (yes, if you just cleanly exit the rescue environment, it should cleanly unmount everything, but let's just be sure it happens right, shall we?):

    # exit
    # umount /mnt/system/usr/
    # umount /mnt/system/boot/
    # umount /mnt/system/
    

13. Reboot. The system should come up with your root volume in use with a new filesystem type.

That's it. That wasn't so difficult, was it?

The entire thing could be done from within the rescue environment, including copying the contents of the root volume to the new root volume, if you like.

Today, I decided to figure out how to keep Windows client's clock synchronized with NTP. A quick Google search located an NIST PDF document titled, "Configuring Windows 2000 and Windows XP to use NIST Time Servers." There is also a link in the introductory pages of that document to the freely available download from Microsoft to enable Windows NT systems to be configured as NTP clients.

As it turns out, it's really easy to configure Windows 2000 and Windows XP Professional, as they both have native, out-of-the-box support to run as a NTP clients. So, to boil down the NIST's 12 page document, open a "DOS prompt" command shell as a user with admin rights and run:

> net /setsntp:servername
> net stop w32time
> net start w32time

That's it.

You could also use the Time/Date control panel. When I tried it (first) on one of my boxes, it had the default configuration of using a Microsoft time server already configured. When I changed it in that dialog box to use my time server, it griped that it wouldn't use the time I was providing as the server's stratum was lower than the host's. I wonder what goofy things Microsoft's time server is doing, as my time server is stratum 2. Anyway, I ran those three commands and it successfully switched over to using my NTP server.

You would think that the fact that Windows 2000 and Windows XP have the NTP client built-in would be one of those things that I would have already "just known." Well, I didn't, but now I do.

That was easy.

I last checked about 12 days ago, but there wasn't an RPM for Fedora Core 6 (the current release), available yet.

It was an easy change, but in the course of all of this, I had made a typo that caused me a problem with one of my VLAN connections. When I tried to bring the link down so I could reinitialize it with some fixed configuration, it hung. Running kill -9 didn't work, so I decided to just reboot. It had been several months since my last boot and there was a newer kernel that I wanted to be using, anyway, so it wasn't a big deal.

But then, DHCP (which is on the same box) no longer worked. I double-checked that dhcpd was running, did a little sniffing and discovered that the DHCP segments weren't actually getting past the firewall configuration. This is odd, since a Netfilter firewall configuration that is completely locked down (i.e. a policy of DROP on all built-in chains and no rules) has always still permitted DHCP traffic to get through. However, I decided to add a couple of rules to the firewall, such as:

-A INPUT -p udp --sport 68 --dport 67 -m state --state new -j ACCEPT

With those new DHCP rules loaded up, it started working again. It would appear that the latest kernel for Red Hat Enterprise Linux 4 and CentOS 4 (which that server runs), has made a change in Netfilter so that it now affects DHCP renewals.

Perhaps a little explanation of DHCP is order, here (skip down a little if you already know this part, in order to get the rest of the story).

OK. So, this initial DHCP setup works fine, even under the newer kernel. The DHCP server's firewall was allowing this in. What happened was that my notebook had reached the end of the lease time for the DHCP lease that I had, but I didn't have any rules to allow DHCP on UDP on IP, which is what happens when your DHCP client is trying to renew the lease for the IP addresses you are already using. What I experienced was that my notebook suddenly had no working network configuration, but if I stopped the DHCP client and had it start again from scratch, it worked.

The fix for all of that was to add rules in the firewall that allowed DHCP much like I allow web browsing, email or World of Warcraft to go through.

"OK, Lamont; I'm following you so far, but what does that have to do with VoIP? Remember, you mentioned that in the title to this article?" "Why, yes; I remember and we're now going to connect that dot."

Back to our regularly scheduled programming.

So, in changing my firewall configuration, I did not add any rules to allow DHCP renewals from the outside interface of my firewall. That one is connected to my DSL router, which has a 4-port switch built in. My Vonage VoIP box is also connected to the DSL router's built-in switch. Previously, it was being configured by my DHCP server, but no more. In the early evening yesterday, I noticed that my phones were getting no dial-tone. As I was working on some other things, I only gave it a cursory look.

This morning was when it finally dawned on me as to what I had done that had killed the Vonage box; I had taken away it's IP configuration. Another notebook that I plugged into the Vonage box's 4-port switch in order to configure it was also unable to do DNS lookups.

Well, after getting home this evening (Dax and I went to the Utah Asterisk User Group meeting this evening), I spent a few minutes configuring static routes on my firewall, the DSL router and the Vonage device, plus setting up static networking and turning off NAT on the Vonage box, everything is working again. Perhaps you'll think I have too many subnets here at home (what? you don't use 4 subnets for 2 people with 8 computers? :) hehe), but I like it. Oh, and in case you're wondering, the only SNAT I'm doing is on the DSL router, so I'm really using routed subnets with all these devices with built-in 4-port switches.

To make a long story short (too late!), I learned that the newest RHEL4/C4 kernels have a change to Netfilter that affects DHCP, and I refined the configuration of my networks. Hopefully, you won't end up pulling the trigger while this particular gun is pointed at your foot. :) Good luck!

Account Balance Update

Dear LAMONT R PETERSON,

Tier Level: {% if ( = " " ) %}Dividend Miles{% endif %} {% if ( = "S" ) %}Silver Preferred{% endif %} {% if ( = "G" ) %}Gold Preferred{% endif %} {% if ( = "P" ) %}Platinum Preferred{% endif %} {% if ( = "C" ) %}Chairman's Preferred{% endif %}
Dividend Miles #: 1234567890

Welcome to the new Dividend Miles:

You now have access to over 842 worldwide destinations at your fingertips and mileage-earning opportunities with over 100 partners such as hotels, rental car and financial service companies, just to name a few.

. . . snip . . .

Apparently, the marketing department gets more proofreading resources than the programmers.

In the .repo file for the mplug Yum repository, there are two lines about GPG; gpgcheck=1 turns on the feature that GPG signatures must be present and valid for packages downloaded from that repo or yum will not install them. gpgkey=http://macromedia.mplug.org/FEDORA-GPG-KEY provides the location where the GPG key file can be found. Simply download the key and run rpm --import FEDORA-GPG-KEY (as root, of course) to install the key into RPM.

There is older documentation on the Internet that will tell you to run gpg --import keyfile either prior to or in stead of rpm --import keyfile. That's for way older versions of RPM and no longer applies; it is only necessary (and desireable) to install the key into RPM.

I also talked a little about the future of Flash Player on Linux. The main thing is that Flash 8 will probably never come to Linux, but 8.5 would. Today, I came across this post by Emmy Huang which talks about Flash Player 9 for Linux. There should be a Linux beta late this year for public testing with the final release sometime in early 2007, according to Huang.

Also, there is a new Penguin.SWF blog at Adobe, run my "Mike M." Go there for all the latest on Flash for Linux.

So, I wiped all of the hard drives for the data VG. I am rebuilding everything from my backups. Ha, I'm sure I got some of you. You thought that perhaps I was going through all those gyrations trying to save my data because I didn't have any backups. Well, I think I'm a little smarter than that :) .

Seriously, though, I had backed up all the stuff that would be difficult to replace/reconstruct as well as all the irreplaceable data. I had things like several Linux distributions' files and .iso images, to make it easy to burn discs and to do network installs (either whole installs or just to have the packages handy). There were mirrors of updates and other software. All of that is easy to replace, though, so I didn't bother backing it up.

The next thing I would like to do for my file server is to pick up another 320GB drive so that I can pair it with the one I have now and migrate everything into an LVM on RAID1 set. Later, I'll add more 320GB drives and convert the RAID1 to RAID5 or RAID6. In the meantime, the 45GB drive is now sitting in the target pile, waiting for the next target shooting outing and the 120GB drive is going to be an online backup store in the file server. That leaves me with only 299GB of storage on my file server.

How will I ever get by? :)

Sometimes, when I'm first introducing students to LVM, they ask me something like, "Why would I ever want to do this? Add an extra layer of complexity and overhead, just to get some fancy looking partitions? No thanks; I'll stick to plain partitions."

First of all, LVM is very efficient, introducing almost zero overhead for most normal operations. Yes, there is a little, but it can be difficult to meassue, let alone notice. Second, there are many irritating storage management tasks that are downright child's play to accomplish with LVM in place but quite difficult with just plain partitions.

This is the case with my home file server, so I shut it down to add the new drive (read my recent posts to learn about that adventure). But while I'm moving the data, the entire system is running and available as normal. I can read and write data all over my LVM LVs without worry.

Here's the sequence of events:

1. Insert new drive into the system; If you couldn't hot-swap, boot it back up


2. Get to a root shell and create an LVM partition on the new drive (that's partition type 0x8E)


3. Run pvcreate /dev/sdb1 (change /dev/sdb1 to the correct device, of course)


4. Add the new storage to the VG of your choice (they can only be in one VG) by running vgextend vg0 /dev/sdb1 (change vg0 to an appropriate value)


5. Enjoy your expanded storage!

OK. In my case, I want to move everything from all old drives to the one new one, so I'll use a special form of the pvmove command. If I wasn't going to be removing all of the existing devices and was keeping more than just the one drive, I would not specify the second parameter to pvmove. Here is the output from my running of them: :

# time pvmove /dev/hde2 /dev/sda1
  /dev/hde2: Moved: 0.3%
  /dev/hde2: Moved: 0.7%
  /dev/hde2: Moved: 1.0%
  /dev/hde2: Moved: 1.4%
  /dev/hde2: Moved: 1.7%
  /dev/hde2: Moved: 2.1%
. . . snip . . .
real    72m23.484s
user    0m4.812s
sys     0m4.116s
# time pvmove /dev/hdg1 /dev/sda1
. . . snip . . .
  /dev/hdg1: Moved: 44.2%
  /dev/hdg1: Moved: 44.6%
  /dev/hdg1: Moved: 45.0%
  /dev/hdg1: read failed after 0 of 1024 at 4096: Input/output error
  /dev/hdg1: read failed after 0 of 2048 at 0: Input/output error
  Failed to read existing physical volume '/dev/hdg1'
  Physical volume /dev/hdg1 not found
  ABORTING: Can't reread PV /dev/hdg1
  ABORTING: Can't reread VG for /dev/hdg1

real    31m23.484s

user    0m2.072s

sys     0m1.772s

I'll talk about the errors in a minute.

As you can see, it can take a while to move that much data, so running them in a screen session is recommended.

With the two parameter form of pvmove, I'm telling LVM to migrate data off of the old drives only moving it to the new one. Again, except in these kinds of very narrow circumstances, it's better to only tell it the device to move off of and let LVM decide where to move the data to (it'll make things much more efficient that way).

OK, so there were some errors running pvmove and it bailed out. Let's see what wer're dealing with:

# pvdisplay /dev/hdc1
  /dev/hdc1: read failed after 0 of 2048 at 0: Input/output error
  No physical volume label read from /dev/hdc1
  Failed to read physical volume "/dev/hdc1"

Uh, oh. Looks like I'm going to have a little difficulty getting this one fixed. I ran a few other commands looking at data LVs that are already mounted and it seems that the corrupted portion of the disk is not affecting any existing data. I did have a /dev/data/up2date LV which I deleted during the installation of SUSE Linux 10.1 (I won't need that Red Hat specific item). Prior to the installation, it was not mountable and fsck couldn't recover it because of drive problems. This was one of the reasons that I decided to get the new drive in the first place.

Hopefully, I'll find a way to verify whether or not there is any other data on that drive that I need to worry about. Bat as it's getting late, I think I'm about to head off to bed.

Just to finish things off, run vgreduce /dev/hde2 (in my case). At this point, I can remove the 120GB drive and once I fix up and finish migrating from the 45GB drive, I'll be done. In my case, that means another powering down (so I'll wait till I can pull them both), but it is a home file server, so I don't mind.

It's very nice to have access to all of my data while I'm upgrading my storage system. There isn't even a performance penalty for other I/O, as the LVM code will submit the pvmove I/O operations as low priority to the kernel's I/O scheduler.

The old drives are 45GB & 120GB in size, which works out to approximately 41GB and 111GB formatted capacity, for just over 152GB storage. The new drive is a 320GB model, which works out to just over 299GB formatted capcity.

Since the old drives are nearly full, I'm going to be moving a lot of data. As I'm using LVM, I can migrate the data to the new drive with ease, while I have everything online and in use, but I'll cover that later. But before I move the data over, I would like to know if the new drive is good. Although this technique won't tell you for sure (as in life, sometimes there is no certainty), but it's a good indication that things are OK and it gives the new drive a little bit of a workout.

I simply used the badblocks command to test the entire drive, like so:

I ran that after connecting remotely to the server from work via SSH. I used screen so that I could disconnect from the session, come home and reconnect later. When I did, I saw that the entire drive was checked in under 96 minutes. Not bad.

Of course, it's always a good sign when there are no error messages from STDERR, but I'll have to check the sda.badblocks created by my command:

# ls -l sda.badblocks
-rw-r--r-- 1 root root 0 Jul 17 16:38 sda.badblocks

As you can see, the file is empty. So, it looks like my new drive is just fine. That means I'm ready to copy all of my data over to it, but you'll have to read my next post to learn how I'm doing that without interfering with normal operations.

The new card is built using a Silicon Integrated Systems Corp. (SiS) chip. This controller needs the "sis-sil" driver. My dual Opteron box still has Fedora Core 4 on it, which apparently either doesn't have the driver with it, or didn't try loading it. I discovered this while trying to test the card and the new Western Digital WD3200J hard drive I bought the card for in my dual Opteron workstation. The drive showed up if I connected it to the on-board SATA controller, but not on the PCI card. But, lspci did show and identify the PCI SATA controller.

I decided to try it again in the file server box, so I put the whole thing back together and fired it up, entering a rescue mode using a RHEL 4 ES DVD that was lying close by. Nothing from lspci, so I decided to button up the box (I had it sitting on the back of my desk while working on it) and replace it in the server stack so that I could at least use the storage I had.

Boy, was I in for a pleasant surprise.

A few moments later, I had the server snugly back it's shelf (I'm not rack mounting, yet :( ) with the LVM cables plugged back in. I powered on the monitor and switched the LVM to the file server while pressing it's power button. I needed to select the second kernel to boot (I still haven't fixed the "newest" one), so I sat and watched. That's when it happened.

All of a sudden, there it was, on the screen ... the PCI STAT controller card's BIOS showing it had found the one drive plugged in and that there were no RAID arrays configured (it has some kind of "on-board RAID0/RAID1 capability, which I'm sure is actually FRAID). "It's ... working!?" Wow, cool. I hit <CTRL>+<ALT>+<DELETE> on the keyboard. "Let's see if it does that again. It did.

It's always nice when hardware starts working, but sometimes, it can be a little frustrating not knowing for certain why it suddenly started working. Oh, well, it's running! I'm not complaining one little bit.

The only thing I could think of was that after having initialized the card for it's first time in the dual Opteron box and replacing it in the file server system, it was still in the same slot, so the BIOS didn't try to "re scan" the PCI bus fully as it saw the same device list and, therefore, skipped the card when I had tried the rescue environment and the lspci command didn't show it listed. But when I added the SCSI controller back in (there are no drives on it, but I sometimes hook up external devices), the BIOS did rescan everything and decided it knew what to do with the SATA controller. Well, that's the only theory I have at this point.

So, I rebooted with a SUSE Linux 10.1 CD. When I reached the partitioning, it saw all 4 drives. Yipee! So, I configured the partitioning, reformatting all the partitions that had RHEL 3 on the system LVM VG and creating the mount points for all the data VG's LVs. In fact, I started writing this post before it started installing files and it's already finished, rebooted and been sitting there for at least 5 or 10 minutes until now, when I checked on it. I finished up the installation (there's going to be some more housecleaning and services configuration to do, of course) and then returned to finishing this post.

Unfortunately, there have been a few bumps and bruises on the way to getting the new drive working in my server. To help you understand some of the issues, here are the specs on that box:

1. 700MHz AMD Duron processor
2. Syntax SV266AD motherboard
3. 1GB RAM, 1 DIMM from Crucial
4. 4GB Quantum Fireball hard drive (used for OS with separate LVM VG)
5. 45GB hard drive (Western Digital WD450AA)
6. 120GB hard drive (Western Digital WD1200BB

In case you were wondering, it was only about $2 more to get a 1GB DIMM than a 256MB DIMM when I bought it and the 45GB & 120GB drives provide the shared storage under LVM.

Not a bad system, but not terribly modern either. For example, my problems begin with the fact that SATA is a newer technology than the Duron boards or, for that matter, RHEL 3 (because it sports the 2.4 version of the kernel).

Anyway, when I went to install the new SATA hard drive that I had picked up, I decided that I should rearrange the other drives so that when I pull the 120GB & 45GB drives from the box, that there will still be really good airflow around the new drive. As I shuffled the 4 hard drives around in the 6 drive hanging cage (this case has room for another 5 5-1/4 inch and 1 3.5 inch drives), I realized that I was just going to have to do it again, so I arranged things such that I should be able to get the most air over the 4 drives. I'll just move the new one when I pull the old drives out.

But when I hooked everything back up, the system (by which I mean the BIOS) could not see the new SATA controller. To make matters worse, it could no longer see the 4GB system drive either. At that point, however, I had to leave for a few business trips and didn't get around to working on the box again until this past weekend. It turns out that I merely had to reverse the IDE ribbon cable going to the 4GB drive and all is well, with it.

Then, when I booted the system up with the 4GB drive back in view, I got a kernel panic. Looks like the latest kernel which I have installed for RHEL4 (2.4.22-37.0.1) can't find the root partition at all. That was quickly fixed by editing /boot/grub/menu.lst in a rescue environment; it turned out that there was no value for the root= parameter on the kernel line. After rebooting I get a little different kernel panic. It seems there is misconfiguration in this kernel' initrd so that it can't do the pivot_root(8) properly (seems like the old_dir it's trying to use doesn't exist. So, I boot into the next previous (2.4.22-37) kernel, which also fails since it can't find anything in the /etc/fstab file.

OK, another trip into the rescue environment and, sure enough, there are zero bytes of content in the /etc/fstab file (/me shakes head). so, I reconstruct the basic lines needed to get the OS up and running, reboot again, and viola; I finally have a running system. I still had to add a few more lines to /etc/fstab before everything was ready for normal operation, but that only took about 3 minutes.

Still, the BIOS doesn't see the new SATA controller. Perhaps a BIOS update will get things going. I'm thinking that perhaps the BIOS just doesn't have the first clue what kind of card it is, so it doesn't initialize it into the PCI bus. To test this theory, I booted from a handy SUSE Linux 10.1 CD and checked some things out in the installer's partitioning tools and with the command line. No dice, there just is no /dev/sda device appearing at all.

All right, then, let's update the BIOS. Of course, it's a DOS program, so I decided to burn a CD as I don't even have a floppy drive installed on this box and didn't really want to dig one out. My first attempt at creating a bootable CD from a DOS floppy I have used for about a decade failed to boot. I did a little digging to find out what I needed to do to properly create a bootable CD with mkisofs. I came up with this command line:

mkisofs -r -b workdos95.img -c boot.cat -o SV266AD.iso SV266AD-BIOS/

The trick is that the workdos95.img file (created by running dd if=/dev/fd0 of=workdos95.img bs=512 with the working boot floppy in the drive) has to be placed in the SV266AD-BIOS (in my case, since that's what I named it on my hard drive while I was building the CD) directory. That isn't exactly clear from the mkisofs(8) man page.

Burning the resulting ISO9660 image to a blank CD-R produced a working, bootable DOS CD. The oakcdrom.sys DOS driver even works with my Pioneer slot loading DVD drive. I was able to change to the G:\ drive (the CD) and run the BIOS update utility. Sadly, rebooting showed that the newest BIOS still didn't bring up the PCI SATA controller. Nuts.

To satisfy those scratching their heads over the workdos95.img file, WorkDOS is a name I have used for utility boot disks that I have built. They are simply a DOS boot floppy with almost all of the main C:\DOS\ files, a couple of other tools and some CD-ROM & NIC drivers included on a 1.44MB floppy. They have been quite useful over the years, though I haven't used one in a long time.

The next test is to pull out the card and drive, plug them into my dual Opteron box (which has 4 SATA ports on board) and make sure the drive is good and see if the card is visible. I'm working on that now.

Perhaps I have a bad card. Maybe this BIOS will never be able to see it. Either way, the next iteration of my home file server will make use of a way cool SATA controller; the 3ware 9590SE-16ML. Oh, yeah :) !

As my good friend Doran Barton pointed out in a comment on my previous post, there are RPMs available to provide the Flash plugin. At the time I wrote that post, I had tried using that RPM for the current release of Fedora Core which I had recently installed, but it didn't work for me. Additionally, other instructions & HOWTOs that I had found on the Internet didn't work for all of my browsers. As I do some web stuff, I like to keep several working browsers around for testing.

When Fedora Core 4 came out (in May of 2005), I continued to use the instructions I had written to make Flash available in all of my browsers. A couple of months later, I found that the mplug yum repo (which Doran had suggested using) now worked for me and that it installs the Flash plugin such that it works with all the browsers I have installed.

When I upgraded to FC5, I found that the same RPM works there, too. You can download the .repo file, which should be placed into your /etc/yum.repos.d/ directory, then run yum install flash-plugin as root.

I did run into a website recently that required Flash 8, which is not available for Linux. It's doubtful that the complications in porting Flash Player 8 to Linux will be overcome, however, it looks like Flash Player 8.5 will be made available for Linux.

So, I would highly recommend using the mplug Macromedia yum repository. But if it doesn't work for you, refer back to my instructions for manually setting up Flash for all of your browsers.

If you experience any troubles with the Flash plugin in your browsers, check out the FAQ at mplug, which has some good tips for dealing with common issues. For those of you using FC5, there is a note in the FAQ about font issues that could apply to your situation. There are also notes regarding installing the flash plugin with other distributions.

When ifup finds the HWADDR variable in an ifcfg-foo file, it uses the value to verify that it is configuring the correct interface. If it doesn't match, it bails out. Because of this, I have often told students that if they expect to be swapping NICs or if they run into a problem where ifup refuses to configure the interface, to try removing (or commenting out) the HWADDR line entirely. I have even gotten into the habit of just removing it on my own personal servers, workstations & notebooks.

However, not having HWADDR in my /etc/sysconfig/network-scripts/ifcfg-ethX files on my notebook actually caused me a little bit of trouble, today.

Looking at the changelog for the latest updated version of the initscripts package (which /etc/rc.sysinit is part of), shows:

* Fri Jul 07 2006 Bill Nottingham <HIDDEN EMAIL> 8.31.5-1
- backport cups startup fix (#189168)

* Fri Jun 30 2006 Bill Nottingham <HIDDEN EMAIL> 8.31.4-1
- backport bridge fixes (#187100)
- ignore alias devices in rename_device (#186355)

* Fri Mar 17 2006 Bill Nottingham <HIDDEN EMAIL> 8.31.2-1
- add udev helper to rename network devices on device creation

So, I checked out https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=186355. Although the issues that bug's reporter (and others) were having was related to the use of Virtual Interfaces, it touched on things that could help explain the error I was seeing. A little more digging around on Bugzilla didn't produce any useful results right away, however, and as I'm teaching Guru Labs' GL510 Network Security course (which is rather in-depth), I didn't have time to do any more digging right then. So, I sent a quick little email to Bill Nottingham at Red Hat, asking if he's been seeing this problem. This was his response:

Lamont R. Peterson said:
> A couple of weeks ago, my notebook's two interfaces (eth0 3C920, eth1 IPW2915)
> came up swapped (wireless eth0 wired eth1).  It only happened the once, until
> today, to me.  One of my co-workers saw it several times last week.  A couple
> of other people I know have seen this happen once in the last month or so,
> like I did.
>
> Looking at the changelog for initscripts, I see that /etc/rc.sysinit has seen
> some changes regarding udev and device renaming for NICs.

Yep. Stock answer is to make sure you have HWADDR= correct in all your
ifcfg-XXXX files, and upgrade to the current FC5 update (8.31.5) initscripts.

Basically, udev can load/initialize interfaces in random order, so we
need code to try and get them back in the order they're configured.

Bill

So, I've added the HWADDR lines back in on my notebook. Unfortunately, it'll be hard to test if that fixes such an intermittent issue, but, I think that this is the "right" fix for my notebook.

I'm also amending my advice to students in the future. Thanks to udev and the way things now work, it doesn't matter very much what alias lines you have in your /etc/modprobe.conf file; udev will start things up however seems fit.

Working for Guru Labs, I travel many tens of thousands of miles per year. I go through airports and fly all over North America. In all this traveling, I have never had to deal with the loss or theft of a notebook computer. Hopefully, my luck will hold for many years (decades?) to come.

Of course, I'm not going to just say, "Well, I'll never have to worry about that!," and call it "security". I have data on my notebook that I would not want to lose. If my notebook was lost or stolen, I have all that data on other system and could reconstruct it (well, almost all that data).

However, some of it should never be allowed to fall into the "wrong" hands, either. Encryption is a good answer to this problem.

A better approach is to have the filesystem encrypt individual files, transparently. A user would "mark" those files that should be encrypted and the filesystem would provide transparent access. This approach would be ideal for many reasons, including the fact that only the important data is being encrypted, therefore minimizing the load on the system required to deal with encryption. Unfortunately, this approach also requires filesystem support, which is not very common. Also, other tools like standard file open/save dialog boxes would have to be altered to support this capability so users could (un)mark files for encryption.

The approach I have taken is to create a special, encrypted partition and place a filesystem on top of that. The Linux kernel has supported encrypted filesystems through a mechanism called cryptoloop for many years now. However, cryptoloop is deprecated and will be removed at some future point (of course, we've know this for quite some time and cryptoloop is still around, so it may or may not be a while before it is removed). The replacement is called dm-crypt, which is a devmapper module.

Before I get into how to add support for boot-time cryptoloop mounting to Fedora Core, it is important to note that there are some weaknesses in cryptoloop. These weaknesses are not in the encryption algorithms used. As far as I am aware, they have not lead to any exploits which could compromise the encrypted data. However, one should not trust classified data to cryptoloop.

First, you will need to create a cryptoloop encrypted filesystem. This is done using the losetup command (see losetup(8) for full details). Before losetup can be used to create an encrypted filesystem, you will need to load a couple of kernel modules:

# modprobe cryptoloop
# modprobe aes

After these modules are loaded, use losetup to create an encrypted partition (note, in this example, I am using an LVM logical volume; you can use any block device you like):

# losetup -e aes /dev/loop0 /dev/vg0/secure
Password: Enter a passphrase here

Of course, I do not want you to tell me what passphrase you use. More importantly, it is recommended that your passphrase be at least 20 characters long. Cryptographically strong passwords are always a good idea.

Now you have a loopback device (/dev/loop0, in this example) that is encrypted on disk. The cryptoloop driver presents a standard block device on the loopX device node. This device can be formated and mounted just like any other block device:

# mkreiserfs /dev/loop0
mkreiserfs 3.6.13 (2003 www.namesys.com)
. . . snip . . .
ATTENTION: YOU SHOULD REBOOT AFTER FDISK!
        ALL DATA WILL BE LOST ON '/dev/loop0'!
Continue (y/n):y
Initializing journal - 0%....20%....40%....60%....80%....100%
Syncing..ok
ReiserFS is successfully created on /dev/loop0.

The encrypted filesystem is ready to use. Simply mount and use the new filesystem (create the mountpoint with the mkdir command first, as needed):

# mkdir /secure
# mount /dev/loop0 /secure/

After you have copied/moved some data over to your new encrypted filesystem, unmount it and remove the cryptoloop device, thus "locking" the partition:

# umount /secure/
# losetup -d /dev/loop0

Until you run the losetup command, the partition will be available for mounting without having to enter the passphrase.

To mount existing encrypted partitions, simply run losetup to setup the loop device and mount it:

# losetup -e aes /dev/loop0 /dev/vg0/secure
Password: Enter the correct passphrase here
# mount /dev/loop0 /secure/

(NOTE: If the mount command fails, it is usually due to a mistyped passphrase; run losetup -d /dev/loop0 to delete the device and try again, in that case.)

It is not necessary to run these commands when shutting down the system, as the normal system shutdown process will take care of umount'ing the partition and the reboot (or system halt) itself will close the cryptoloop device.

"OK. So now I have this encrypted partition and I know these commands to run to manually mount it, but I want this thing to be taken care of when I boot my notebook." Well, I'm glad you mentioned that; here is how I solved that problem:

First, I edited /etc/rc.sysinit and made this addition (in bold, the rest is for context and the line numbers are for the version of this file on FC4 for x86):

483 # Mount all other filesystems (except for NFS and /proc, which is already
484 # mounted). Contrary to standard usage,
485 # filesystems are NOT unmounted in single user mode.
486 action $"Mounting local filesystems: " mount -a -t nonfs,nfs4,smbfs,ncpfs,cifs,gfs -O no_netdev
487
488 # Mount cryptoloop filesystems
489 if [ -r /etc/cryptotab ]; then
490     action $"Mounting encrypted filesystems: " /sbin/cryptomount
491 fi
492
493 if [ -x /sbin/quotaon ]; then
494     action $"Enabling local filesystem quotas: " /sbin/quotaon -aug
495 fi
496
497 # Check to see if a full relabel is needed

Next, I created the /sbin/cryptomount script, which can be downloaded from the Guru Labs Downloads page. I wrote that script, basing it on the one shipped by SUSE with their distributions (which have supported encrypted filesystems out of the box for years).

The last thing to do is to create the /etc/cryptotab file. In this file, each line describes one encrypted filesystem that should be mounted when the cryptomount command is run. The format of this file is (which is identical to that used by SUSE's built in encrypted filesystem support):

# Loop device   Physical device         Mountpoint      fs-type         Algorithm       fs-options
/dev/loop0      /dev/vg0/secure         /secure         reiserfs        aes             defaults

That's it. With these changes, the system will prompt for the passphrase for each encrypted filesystem described in your /etc/cryptoloop file during bootup.

Note: It looks like at least SUSE Linux 10.1 (and probably OpenSUSE 10.0) have switched to using dm-crypt in a way that is now slightly incompatible with the technique described here. (Ed. They are actually using cryptoloop still, but don't load the aes kernel module which is why the SUSE 10.1 tools can't just setup access to the cryptoloop encrypted filesystem on my notebook, which was created for Fedora using the technique found here.)