The Art of Tech

March 6, 2007

Root Filesystem Conversion

Ed: This post was originally written on 2006/08/03, but for some reason I missed publishing it. As I believe the information is useful, I'm publishing it now.

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.

Posted by lamontp at 5:23 PM | Comments (0) | TrackBack

Windows NTP Client

I've had a Network Time Protocol (NTP) server running in my home network for many years. The two workstation dual boot Windows and Linux. When running Linux, the ntpd daemon keeps them in sync with my NTP server. When running Windows, I haven't bothered, as there isn't anything running under windows that cares about time at all, and since they run Linux most of the time.

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.

Posted by lamontp at 11:06 AM | Comments (0) | TrackBack

February 9, 2007

Adobe Flashplayer 9 for Linux Installed

About three weeks ago, I ran rug update on my notebook (II'm mainly using openSUSE 10.2) and got the Adobe Flashplayer 9 for Linux update installed.

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.

Posted by lamontp at 10:40 AM | Comments (2) | TrackBack

September 5, 2006

DHCP, VoIP & Updated Kernel

Yesterday, I was working on a new DNS server I was setting up for someone, when I noticed that I hadn't setup rndc on my home DNS server. After fixing that, I added a couple of zones to my home DNS server to have it serve (for now) as the secondary server for some new domains, but the zone transfers weren't working. It was immediately obvious that I needed to alter the firewall configuration to allow the DNS server to initiate zone transfers, so I ended up looking at a couple parts of my firewall configuration.

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

When a device has no Layer 3 configuration, a DHCP client has to form the initial UDP datagram (which carries the DHCP request, itself) directly within a Layer 2 frame (usually Ethernet). This is (obviously, to those of you who know about how the network stack works) odd, as you almost never "skip" any layers when forming a packet to send out.

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!

Posted by lamontp at 10:46 PM | Comments (0) | TrackBack

August 4, 2006

Yum GPG Keys

I forgot to mention the use of GPG keys with yum in my recent post about using the mplug repository to install Adobe Flash Player.

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.

Posted by lamontp at 10:29 AM | Comments (0) | TrackBack

Macromedia Flash 9 for Linux

In a recent post of mine, I talked about using the mplug yum repository to install the Adobe Flash Player web browser plugin (Adobe bought Macromedia in 2005).

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.

Posted by lamontp at 9:45 AM | Comments (0) | TrackBack

July 11, 2006

Macromedia Flash on FC5

Last year, I wrote a post providing instructions on how to manually install the Macromedia Flash plugin for Linux so that it would work with all of your browsers.

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.

Posted by lamontp at 9:25 AM | Comments (0) | TrackBack

July 10, 2006

Swap Happy NICs on FC5

When Red Hat's system-config-network or netconfig tools (on either RHEL or Fedora) create /etc/sysconfig/network-scripts/ifcfg-ethX files, they always add in the HWADDR=00:00:00:00:00:00 line. There have been a couple of times that I have run into trouble because of that line.

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.

Running Fedora Core 5 (FC5), I saw my NICs swap places during bootup. This happened first a few weeks ago, and only happened once, so I figured it was probably a fluke. Then, Clint's new notbook did it several times to him. When it happened to me again this morning, I decided to dig a little deeper.

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.

Posted by lamontp at 3:37 PM | Comments (0) | TrackBack

July 7, 2006

Encrypting Partitions on a Fedora Core Notebook

(Ed. I originally wrote this in August of 2005, but never published it, planning on reworking it to use dm-crypt instead. Unfortunately, with all the traveling and other things keeping me busy here at Guru Labs, I've still not gotten around to it, so, I decided to publish this version as is. I should have the dm-crypt version written as a new Guru Guide, soon.

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.

There are several different ways that one could use encryption to protect files on a system. Individual files could be encrypted and decrypted, as needed. This approach, while relatively simple to implement, is rather tedious for the user and error-prone; important files must be re-encrypted after each use in order to ensure they remain protected.

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

Posted by lamontp at 11:45 AM | Comments (3) | TrackBack

December 23, 2005

`Twas the Night Before Christmas Eve

I have finished delivering my 31^st class for Red Hat. This is something like the 25^th certification exam that I have proctored. At the end of the exam, I have to get the information to Red Hat that they need and someone there will process the data and, eventually, the determination is made as to where there are any new RHCT or RHCE certified individuals.

This week, however, ends on the 23^rd of December. I'm in Anaheim, California (Pacific time) and Red Hat's Headquarters are in Raleigh, North Carolina (Eastern time). I sure hope no one has to stay and wait for my results file to arrive. But, just in case, I decided to try to give them a little extra Holiday cheer by writing this extra little email to send along (it only took me 3 minutes, in case you were curious):

--
Holiday Reveler,

Twas the night before Christmas Eve,
And all through the Raleigh office,
Not a creature was stirring,
Not even for a purpose.

The candidates were drive to their homes with great care,
Visions of Red Hat Certificates in the air.

When out from the notebook of the Instructor there flew,
The files so carefully constructed for you.

And as the Instructor left for his flight,
He was heard to say, "Merry Christmas to all!
"And to all a good night!"
--
If you are Christian: Merry Christmas.

If you are Jewish: Happy Hanukkah.

If you are neither: I'm sorry, but I do not know what the specific well-wish should be for your holiday of choice, so I'll simply wish you Happy Holidays and a Happy New Year.
--
Lamont R. Peterson

Posted by lamontp at 6:13 PM | Comments (0) | TrackBack

June 10, 2005

Linux Device Drivers Really Are Easy to Write

In the process of updating Guru Labs GL250 Enterprise Linux Administration course, I have learned many new and interesting things. This past week, I updated the kernel compilation lab exercises.

We wanted students to learn the different ways they can build and install additional drivers for the kernel. To accomplish this goal, we needed a driver that could be built & installed as well as applied as a patch to the kernel trees for all the distributions that our course supports. This presents many challenges which were most easily solved by writing a new driver from scratch, which I did.

"Come on, Lamont; why couldn't you have just used some existing driver out there?" The first difficulty is finding an available driver that is neither already included with the "vanilla" kernels, but has not been added to the distribution kernels by either Red Hat or SUSE. Another issue is that we have no way of knowing what hardware will be available in classrooms around the world. Guru Labs courses are taught in over 120 countries worldwide; any driver selected for use in the lab demonstration would have to be workable in so many different classrooms on such varied hardware that it really would be impossible to use any hardware driver.

"OK. But why does it have to support hardware that really exists?" The short answer: it doesn't. However, we do want students to be able to see, from the beginning to the end of the process, that they have successfully installed the new driver. The good news here is that we do not need it to support any hardware, at all.

So, I learned how to write a device driver for the 2.6 Linux kernel. The driver supports a character device that can be read from via a device node. When read, it will output one word per line, at random. The words are from the RFC3092 list, plus a couple of others.

In the lab, students will build this driver as an "External Driver" or, in other words, it will be built outside of the kernel source tree without building the entire kernel, as well. They will also apply a patch to a kernel source tree, which they configure in other ways and build, install & test a custom kernel.

If you want to learn how to write device drivers for the 2.6 Linux kernel, I would highly recommend the book "Linux Device Drivers" (3rd Edition, O'Reilly Press). It is also available online at http://lwn.net/Kernel/LDD3/ in PDF format, one file per chapter. This book is very well written, providing excellent sample code showing many good software engineering practices with good explanations of why things should be done this way or that for almost everything covered. I will be buying a copy of this book, soon.

Now that I know how to build drivers for the 2.6 kernel, I have a couple of projects that I will be able to do. Hardware for which no Linux driver has been available will not remain useless for much longer. Wish me luck.
--
Lamont R. Peterson

Posted by lamontp at 12:34 PM | Comments (0) | TrackBack

May 25, 2005

802.11a Configuration Woes ... with Solution

Today, I tried to bring up the 802.11a connection here at Guru Labs. It failed. Although my previous configuration had been working, something had changed and the configuration "trick" I had come up with was not robust enough to deal with it.

After playing around with the configuration, I was able to get it working by commenting out the CHANNEL variable in the /etc/sysconfig/network-scripts/ifcfg-eth1-work file. Then, using iwpriv as I had previously I would bring up the interface, associate with the 802.11a access point (AP) and configure the interface using DHCP.

The search was on for a better way to configure the system to prefer 802.11a over either 'b' or 'g' in the ifcfg-eth1-work file.

The solution was really quite simple; add this line to the appropriate ifcfg-* configuration file(s) in the /etc/sysconfig/network-scripts/ directory:

IWPRIV="set_mode 7"

In the case of my Intel IPW2915 wireless Mini-PCI NIC, this value places the card in "802.11abg" mode, which tries to find an 802.11a connection before trying 802.11g and, finally, 802.11b. Other NICs may not use the same parameters, but whatever it is that needs to be passed to the IWPRIV command can be placed in that variable and it will be used before trying to associate to an AP.

In my case, the access point had been reboot and, apparently, had decided to use a different channel, which is why my first stab at persistently configuring 802.11a support failed.

Thanks go to Dax for pointing out that the ifup-wireless script could utilize the IWPRIV variable in the ifcfg-* files.
__
Lamont R. Peterson

Posted by lamontp at 4:01 PM | Comments (0) | TrackBack

March 17, 2005

Student Writes man Page

One of my students wrote this on a piece of paper and set it on the counter in our break room, here at Guru Labs. He also placed four boxes of the items refernced in this "man page" on the counter.

$ man eatgirlscoutcookies
(1)                          User Commands                    (1)
NAM
     eatgirlscoutcookies - eat them, they're good! Command
                 allowing ingestion of Girl Scout Cookies.

SYNOPSIS
     eatgirlscoutcookies [-qa] [-d ]
     eatgirlscoutcookies [-n] [-t ]
     eatgirlscoutcookies [-fFwk]

DESCRIPTION
     [Two other students from Sweden, who were here last week]
     never had Girl Scout Cookies, so I just had to buy a
     samling of the best for them. Now that they have gone
     back to Sweden, I cannot eat them all by myself, so
     please, enjoy!

     P.S. I got kinda bored last night after reading man
     pages :).

OPTIONS
     -a  Eat them all in one sitting, by yourself
         (not recommended!) Usually accompanied with the
         -q (quiet) option.
     -n  Specifies number of cookies to eat.
     -t  Specifies type of cookie to eat.
     -F  Allows redirection to Family (extended).
     -f  Allows redirection to friends.
     -w  Allows redirection to wife.
     -k  Allows redirection to kids.

BUGS
     There will be none, unless this command is not used for
     an extended period of time.

                          March 17, 2005                      (1)

Posted by lamontp at 4:25 PM | Comments (0) | TrackBack

March 15, 2005

VMware Workstation 5 RC3 on Linux

I have been using VMware Workstation 4.0.5 for a while now on my (old) notebook. I have a small virtual vachine with WindowsXP Pro installed to it. I have used it on those rare occasions when I needed to do something with windows (but not gaming).

After updating the system to a distribution using the 2.6 kernel (the original installation was on 2.4) I found a couple of small problems.

The first, which I do not believe is related to the kernel release, is that I could no longer use the virtual machine in full screen mode. I believe this is due to some small, subtle difference between XFree86 and the xorg X server.

The second problem, was getting the 2.6 kernel modules to build using VMware's vmware-config.pl script. I ended up hacking that script to just continue on when it thought it could not find the kernel headers even though it was looking right at them. It worked fine and built and installed the modules.

After some kernel update or another (I think it included a version bump and not just a release bump) under FC2, I started to experiece two other odd problems with the VMware drivers. The first occured if I did not shut down the VMware services manually before shutting the system down; it would hang waiting for one (did not matter which) of the vmnet interfaces to stop being "in use" which meant an inifite loop. The other was that many times, I would have to rebuild the drivers each time I booted the system. After doing so, VMware ran just find (other than the fullscreen thing.

Since this new notebook was going to dual boot (due to the better video support) I did not bother to bring the WinXP VM over yet, so I did not originally install VMware Workstation 4.0.5 (or 4.5.x). At the end of last week, I decided to get it set up. However, I decided to try out the new VMware Workstation 5 beta (it was at RC2 at the time I pulled it down) and see if it fixed my problems.

Sure enough, I do not have to futz with the drivers anymore and they do not hang the system on shutdown. Woot. I have not actually installed any guest OS's yet (I will copy the VMware 4.0.5 WinXP VM over from the old notebook sometime this week and try out the conversion tools), but I plan to install both RHEL4 & CentOS4 VMs to play around with.

Over the weekend, they released VMware Workstation 5 RC3, which I have downloaded and installed. The first difference I noticed was that the UI had seen some significant redesign in some places.

Installation has been very smooth and easy to accomplish (no more hacking vmware-config.pl). The new "Teams" feature looks very interesting and (probably) will be quite useful to me. The new 64bit support is another item that I plan to test, soon.

Posted by lamontp at 2:56 PM | Comments (0) | TrackBack

March 9, 2005

Rescue Mode, grub-install & udev

Fedora Core 3 is the first release from Red Hat that uses udev for managing the /dev filesystem. This new system offers some great advantages. I will be posting a new GuruGuide soon, introducing the basics of udev configuration.

However, this post is not about udev, per se.

I recently installed WindowsXP Professional on my notebook as part of a dual-boot configuration. There were issues getting Windows to install originally so I ended up installing Linux first, which is not how I usually do things. In this case, I was heading out of town the next day and needed Linux with me on that notebook.

After finally working out the issues with Windows, the only thing I needed to do to complete my dual-boot configuration was to get GRUB reinstalled to the Master Boot Record (MBR) on the hard drive. This way, GRUB comes along first and I can select Linux or Windows from it's menu.

One way to install GRUB to the MBR when the MBR has been clobbered (like happens when installing Windows, though Windows does not use the MBR in order to boot) is to boot using a Linux CD that provides a so-called "rescue" environment (sometimes referred to as a "LiveCD"). From there, you simply mount your hard drives partitions, chroot into the path where you mounted the hard drive and run the grub-install program.

So, I placed the Fedora Core 3 CD1 into the DVD drive on the notebook and booted up. At the CD's "boot:" prompt, I typed:

boot: linux rescue

Once the rescue environment was up and running, I typed:

# chroot /mnt/sysimage
# grub-install /dev/hda

Nothing happened; it just sat there, never reporting any errors. As it was about midnight last night when this happened, I went to bed and took another crack when I arrived at the office the next morning. The same thing, again.

I tried using a RHEL4 CD1 rescue environment, as well as RHEL3 & FC1 (all of which I had handy). Same problem. Then it dawned on me: udev. Device nodes for the hard drive do not exist in the chroot'ed environment. From the chroot'ed environment, I next ran:

# mknod /dev/hda b 3 0
# grub-install /dev/hda

This produced an error message telling me that grub-install could not find /dev/hda1, which it needed in order to finish setting things up. I created the appropriate device node and tried once more:

# mknod /dev/hda1 b 3 1
# grub-install /dev/hda

It worked! It is probably a good idea to delete the device nodes just created, before rebooting:

# rm /dev/hda*

After rebooting, GRUB did it's job and I can now boot to either Linux or Windows whenever I want.

Posted by lamontp at 8:06 PM | Comments (2) | TrackBack

Take That! WinXPpro Installer

I do almost everything in Linux. There are only three reasons that I keep any Microsoft Windows around at all:

1. Testing
2. Microsoft Money (I just do not like the existing offerings available for Linux)
3. Games

There are some games that I can not get to run under Linux that I love to play. The most problematic of these is Homeworld (I have not tried Homeworld2 yet). The easiest to get running under Linux are all of my games from Blizzard Entertainment. In most cases, they actually run better (faster, smother) under Linux (using wine) then they do under Windows!

Last night, I finally got WindowsXP Professional installed.

When I got the new notebook, I tried to install WindowsXP Professional on it first. It came with XP Home Edition, which I categorically refuse to install on anything I own. I had a copy of XP Pro that I was not using on any other system, so I tried that.

Booting from the Windoews XP Professional (with SP1) CD, I saw the "Setup is examining your hardware" message and then just a blank, black screen and nothing ever happened. I gave up and just installed Fedora Core 3 on here, leaving the last 20GB of the hard drive to install Windows on later.

It was a very simple trick to get the installer to run. First, I installed a copy of Windows2000 Professional (that is also not in use on any of my systems at the moment, but is earmarked for one) first. When I logged in for the first time, I immediately inserted my WindowsXP Pro CD and when the autorun window came up, I told it to "Upgrade" my Windows2000 system. 50 minutes later, I was running WindowsXP Professional on the notebook.

There was one small problem getting GRUB fixed up, but I will make a seperate entry about that.

Posted by lamontp at 7:50 PM | Comments (0) | TrackBack

March 1, 2005

Installing the Flash Plugin for All Linux GUI Browsers

It is really easy to get the Macromedia Flash Plugin for Linux installed and working with all of your Linux web browsers. Here are the steps:

[NOTE: file & directory names will change with each version that is released]
[NOTE: paths listed are for Fedora Core; other distros may vary; substitute accordingly]

1. Download the Flash Player/plugin for Linux from Macromedia at http://www.macromedia.com/shockwave/download/download.cgi?P1_Prod_Version=ShockwaveFlash.

2. Extract the contents of the tarball just downloaded:

$ tar -zxf install_flash_player_7_linux.tar.gz

3. Change into the directory created from extracting the tarball contents:

$ cd install_flash_player_7_linux

4. As root, copy the libflashplayer.so file to the /usr/lib/mozilla/plugins/ directory:

# cp libflashplayer.so /usr/lib/mozilla/plugins/

5. Open the Configure Konqueror... dialog at the bottom of Konqueror's Configure menu. Scroll to the bottom of the icon bar on the left side of the configuration dialog, and click on Plugins. Click on the Scan for New Plugins button. Click the Plugins tab and verify that the Flash Player plugin is now on the list.

[ANOTATED SCREENSHOTS PENDING]

Lamont R. Peterson

Posted by lamontp at 10:14 PM | Comments (2) | TrackBack

February 23, 2005

Welcome

Guru Labs has made the decision to deploy blogging software for each of the gurus to use. We selected MovableType from six apart for this purpose, which I have not used before.

At this time, I do not know for sure what kinds of things I will be putting into my blog. I think I will start by trying to figure out a few categories which I feel would describe these items. From there, we will just have to see what develops, I guess.

So far, I am greatly impressed with MovableType. The system runs well and is easy to explore. There is also an online manual that I am going to have to read.

Thank you for taking the time to read this (lame :) ) first enty. I may delete it as I become more comfortable with the process of blogging. Comments are welcome, but will be moderated to prevent spam.

Posted by lamontp at 6:37 PM | Comments (1) | TrackBack