Your Linux Guy .com

I got this question the other day from a Centos administrator: “The certwatch tool has been sending the me an email warning me that I need to renew the SSL Certificate. What do I do?”

The email message read like the following (names have been changed):

################# SSL Certificate Warning ################

Certificate for hostname 'www.yourlinuxguy.com', in file:
/etc/pki/tls/certs/www.yourlinuxguy.com.cert

The certificate needs to be renewed; this can be done
using the 'genkey' program.

Browsers will not be able to correctly connect to this
web site using SSL until the certificate is renewed.

##########################################################
Generated by certwatch(1)

The administrator had searched the Internet, and found mostly impolite messages from youngsters about reading the docs. Accurate, perhaps, but not too helpful.  This person’s server was not using a public Certificate Authority (CA); just a local one on the box itself (as is common practice in development environments).  If you don’t understand all that, it will make more sense as we go on…

First I want to clarify a couple things.  When you run the genkey tool, you are actually doing what the name suggests;  generating a new key pair (public/private), from which the certificate is formulated.  Technically, you are not *renewing* the certificate as the certwatch warning message implies, but that’s okay (it *is* possible in some situations to “renew” a certificate based on an existing key pair, but that’s not important right now). The genkey tool makes it so easy and convenient that it is just easier this way. Remember that a certificate is nothing but a public key that is “stamped” with approval by a CA.  In this case, the CA is you, too.  Not exactly a trusted hierarchy, but there you go…

So to cut to the chase, it’s really easy.  Here’s basically what you need to do:  1.) run the tool, and  2.) validate your SSL settings in your httpd.conf.

Run The Tool

At this point, you may or may not want to make a backup of your cert files…  This is up to you…  You can do that with something like this command (of course, your mileage may vary):

cp -av /etc/pki/tls /etc/pki/tls.bak

If you just run the genkey tool without specifying the certificate lifetime, it defaults to something like 30 days.  Let’s try something a little longer; like 4 years.  Now just specify your hostname on the command line:

genkey --days 1460 www.yourlinuxguy.com

…this will launch an interactive tool to do things like generate the random data, make the key pair, and walk you through specifying the content of the certificate (Country, Location, etc.).  It will place the new stuff in some default location, and at the end of the process, tell you where it all is.  You should take note of the location, but it will likely be what I mentioned above for the backup.

Validate Your SSL Settings

Now, theoretically, you should be able to restart your Apache daemon.  However, you might have used custom names or locations for your certificate files in the past, so you might want to check to be sure they match the SSL settings in your Apache config files.  Of course it’s hard for me to tell you where those settings are, since it’s so easy to customize Apache; but here’s a good way to find the two most important values:

cd /etc/httpd
egrep -R -e "SSLCertificateKeyFile" -e "SSLCertificateFile" *

…and that will likely return results from a file called “ssl.conf” or something like that.  Edit the config file if necessary; just make sure the values match the place that the genkey tool placed the new private key and cert file, and you should be good.

Now, you can restart Apache…

/etc/init.d/httpd restart

…and you’re done!  I hope that helps…

Here’s a fun one for you.  I had a situation recently where the customer had some of his windows PCs properly being populated in his reverse DNS zone (in an AD-controlled environment), and some that were not.  He asked me to quickly scan the network and figure out which were which (before we started to look into the “why” part).  Note that for the examples that follow, the customer’s fictitious network address is good ol’ 192.168.1.0/24, and the commands were tested with the default packages on Opensuse 11.1 and 11.2.

So first, I had to find those that are in the reverse DNS zone… So I simply made sure my PC points to the correct internal DNS server that is authoritative for the forward and reverse DNS zones, and then ran a sweep with some filtering:

nmap -sP 192.168.1.0/24 |grep -v "^Host 192\.168\.1"|grep "^Host"|awk '{ print $2,$3 }'

Then, in order to get the local netbios name for Windows computers that aren’t in reverse dns , I came up with this:

for item in `nmap -sP 192.168.1.0/24|awk '{ print $2 }'|grep "^192\.168\.1"`;do thingy=`nmblookup -A $item|grep "<20>"|awk '{ print $1 }'`;echo $thingy \($item\);done

…of course, non-Windows computers and devices without netbios will simply not respond to the query. It might be neater to dump the output to file and such if you wish, but I didn’t bother. I’m just keeping it simple here.

Note that the above does not take in to account if there are multiple reverse DNS entries per PC. If you need to know that, you could do something like this:

for item in `nmap -sP 192.168.1.0/24 |grep -v "^Host 192\.168\.1" |grep "^Host"|awk '{ print $3 }'|sed s/[\(,\)]//g`; do nslookup $item|grep "name =";echo "";done

…and so on.  You could really go crazy with this sort of thing… It can also be handy if you are in an environment where you don’t have access to the DNS/DHCP administration tools, but want to see what’s out there…. Now wasn’t that fun?

Here’s a quick cheat-sheet on how to do fast backup of your eDirectory tree from an OES Linux server.  While we’re at it, we’ll do a quick restore of an object.

First, let’s back it up!  Let’s grab the whole tree:

ndsbackup cvf /tmp/ndsbackup-treeRoot.bak [Root]

…note that you will be prompted for the admin user credentials, and by specifying the “[Root]” object, it will grab every single object in the tree and put it in the specified file.

Now, let’s get a little fancier:

ndsbackup cvf /tmp/ndsbackup.`date +%Y%m%d%H%M`.bak -a admin.corp [Root]

…here we are adding a date stamp to the output file, and giving it the admin username.  It will still prompt for the admin password, of course.  There are tricks to handle that, too, but this is good enough to get the point across.

If you want to see what’s in your backup file:

ndsbackup tf /tmp/ndsbackup.201003051421.bak

Make sure to copy that backup file off the server somewhere, somehow.  In reality, you might actually be writing the result directly to an nfs or samba share or something anyway, but the point is to get the data off the box for safety.

So let’s imagine a week goes by, and whoops… you deleted someone accidentally.  Don’t worry!  Because all you have to do to restore that user object is to put the file back on the filesystem where you can reach it, and do something like this…

To restore just that user you deleted:

ndsbackup wxvf /tmp/ndsbackup.201003051421.bak -a admin.corp cn=duser.ou=Users.o=corp

Or, plow in the whole container if you accidentally wiped it all out:

ndsbackup wxvf /tmp/ndsbackup.201003051421.bak -a admin.corp ou=Users.o=corp

…If you wish, you can remove the “w” from the above restore examples if you don’t want to be prompted to confirm for each object.  However, I tend to think the “w” is a good idea…

That’s all for now.  Of course, there are tons more options for ndsbackup if you look in the man page, but I’m not going in to that, because after all, this *is* a cheat sheet…

To help someone (like me, for instance) remotely diagnose your Suse system, sometimes you need to send him or her diagnostic info from that system.  Fortunately, Suse has a toolset called “supportutils” to do just that.  This article outlines one of my preferred ways of generating and sending such info.  Note that the examples in this article are targeted toward my existing customers, but you can obviously change the examples to suit.  Or, you can *become* a customer… 

First, su to root, and check to see if the support utilities and sysstat package are installed:

zypper se sysstat supportutils 

…if the result for each has an “i” (for “installed”) at the far left of the package, it is already installed.  Otherwise, if the package(s) are not already installed, run this to install the sysstat package and the support utilities included with your Suse distro:

zypper in sysstat supportutils

Or, if you wish to run the latest version of the supportutils package (see “comment” below about versions), run this to install/upgrade to the latest version at the time of this writing:

rpm -Uvh http://download.opensuse.org/repositories/Novell:/NTS/SLE_10/noarch/supportutils-1.20-1.1.noarch.rpm

(Please see the Supportutils project page at http://en.opensuse.org/Supportutils for the latest info and versions.)

COMMENT:  Unfortunately, I have discovered that the info collection part of some modules seems to be broken on some versions; I’m not sure why.  You’ll know they need to be skipped if you run the tool and it hangs for a long time.  I’ve seen the DNS module hang on most systems with the older package, the SYSFS module hang on Opensuse with the latest version, the NSS modules hang on OES servers, and so forth.  Personally, and take this for what it’s worth, I like the distro-provided supportutils package on OpenSuse, and the latest download-able on available for SLES10 and/or OES servers… all with the caveats, of course…

So, to get around the sticking/hanging problem, we need to modify the configuration file to skip the info collection for those modules that get stuck  (of course, it is also possible that you want to modify the config file to exclude certain things for other reasons, as well).  For this example, I disable the DNS info collection (which has since been repaired in newer versions).  You can do it interactively with vi or gedit like this:

vi /etc/supportconfig.conf

…(or via gui, gedit /etc/supportconfig.conf) and change this line:

OPTION_DNS=1

…to…

OPTION_DNS=0

…or do it non-interactively with this example command set:

mv /etc/supportconfig.conf /etc/supportconfig.conf.bak
sed s/OPTION_DNS\=1/OPTION_DNS\=0/ /etc/supportconfig.conf.bak > /etc/supportconfig.conf

Now back to the program; whether you upgraded, modified the config file, or not….

Next, create the output with this command:

supportconfig

When completed, it gives you a nice info summary.  One of the first lines in the summary is the resulting tar ball file size.  If it is reasonably small, like under 10MB, feel free to send it to me via email it to me this way (if it is larger than 10MB, I can provide an alternate method of delivery):

echo "See attached." | mailx -a /var/log/nts*`date +%y%m%d_%H`*.tbz -s "Support Config file from $HOSTNAME" jpavlov@yourLinuxGuy.com

…Note that the above command will send all of the result files that were generated in the current hour; you can take off the “%H” if the file you wish to send was generated in a different clock hour.

If you’re curious, when I get it, I download from my email and unzip it in a temp directory for review:

cd /tmp/support
tar -jxvf nts_lt1101010_100106_1010.tbz

And that’s it!  I hope it helps.  And, I hope I can help you…

This basic (re-worded) question came in from Jeff: “Why won’t my remote filesystem mount unmount when I try the umount command?”

It’s very true:  If you try to umount (unmount) a filesystem that is currently being accessed, it will not let you do it.  And it will tell you something like, “umount: /media/ncp: device is busy“.  What causes this?  Well, it’s likely to be one of two things:

1. You have (or someone else has) cd‘d onto the remote filesystem and are currently at or below the mount point root
2. You are running an application that has a file open on that mount point

To mitigate item #1 above (if you are the guilty party, not someone else), just cd to the filesystem root (like cd /), or some other place you know is not on the mount point (like cd /tmp).  Then you can run your umount command.

Solving item #2 above is perhaps a tad more tricky.  Of course, if you have a suspicion or direct knowledge of the guilty app, then you can just stop it.  Sometimes doing this:

ps -ef | grep
…or…
ps aux |grep

…will show the process and any files it accessed by the startup command.

Either way, my favorite way to check for both item #1 and #2 above is to use lsof.  This utility will list *every* file that the system has a hold on.  And this is essential because after all, we know that Linux is nothing but a bunch of files, right?

So here’s what I like to do, for example:

lsof| grep "/media"

… this will show you if anyone or anything is currently sitting on the mountpoint (of course, change your mountpoint to suit, be it /media, /mnt, /export, whatever).  If it shows anything, you can see who or what is at fault, and tell them to get off it, or kill them (I mean the app, jeez…).  If you really need to see the headers of the columns, you can do a double-run for cosmetic purposes that will run once for just the header, then again to grab your detail, like this:

lsof |head -1;lsof| grep "/media"

Another way is to use the fuser command, referencing your mount point. Here’s my favorite set of flags in an example:

fuser -uv /media/ncp

I hope that helps!

Recently I came out of the 1990′s, and moved to an IBM laptop that does not have a serial port… Gasp!

Of course, this is not a big deal to alot of people, but I’m a server guy.  I do terminal sessions to Sun/Solaris servers and Cisco routers and such;  I really can’t live without a serial port.  So I basically had 2 options:

1. Go back to my old latop (nope, no way, nahgahdah)
2. Get a USB attached serial port

…so after reading a ton of reviews at NewEgg.com, I finally settled on the CABLES UNLIMITED USB-2920 USB 2.0 to Serial DB9 Adapter.  At the time I bought it, it was on sale and had a shipping special.  But at the time of this writing it is $16.99.  …Still not bad, really.

First, Windows

As it happens, when I first bought it, I connected it to my laptop, and I fired up a Windows XP guest in VMWare Server 2 on my Opensuse 11.2, and “virtually” connected the USB to the XP guest (can’t do *that* in ESX… nyah, nyah).  The driver installation in Windows was a little weird,  since the driver installation was a little language-challenged…  But if you know what you’re doing, you can get it done.  Once it was all set up in Windows, it was easy to use in Hyper Terminal and Putty, and it really worked perfectly.

Then, Linux

A few days later, I needed to do a serial connection again.  This time I didn’t feel like firing up my VM guest, so decided to stop playing around, and configure it natively in Linux for use in minicom.  Here’s where it gets good…  It is sooooo easy to setup in Opensuse, and I hope/assume it is nearly as easy in other distros, though I’ve not tested it.  Here’s basically what I did:

Step 1:  Plug into adapter into USB port

Step 2:  Launch minicom -s (to enter configuration)

Step 3:  Configure the port as /dev/ttyUSB0  (that’s a zero, though it could be a 1 on yours if you have multiple), and save as “dfl” (default)

Step 4:  Enjoy!

I hope this helps…

Believe it or not, there are valid reasons why you might want to disable the firewall service on a Suse Linux Enterprise Server (SLES).  For instance, avoiding NCP time-outs on client connections for an OES/SLES server.  If you just want to know how to disable the firewall in most modern incarnations of SLES, read on…

The examples given here are assuming you are remote to the server.  Of course, you could do all of this locally on the console, or adapt my instructions to the gui “Yast2″, but I’m going non-gui here for simplicity.

First, shell into the box, and su to root.

Method 1:

Launch the Yast non-gui firewall module:
yast firewall

To change to startup setting to “Manually”:
“Alt + m”

Optionally, to stop the service right now if running:
“Alt + t”

To complete the change:
“Alt + n”

To accept and finish:
“Alt + a”

Method 2:

To disable the service at next startup:
chkconfig SuSEfirewall2_setup off

Optionally, to stop the service right now if running:
rcSuSEfirewall2 stop

I hope that helps!  Now, if you want to argue about how one should never disable the firewall, drop me a line…

This article is written in a story-like retrospective fashion.  (Update, 20100128, morning: Now with a happy ending! See below…)  It’s a chain of events that took me from a happy Openfiler user, to and extremely angry Openfiler user, to a cautious Openfiler user.  So let’s begin.  “It was a dark and stormy night…”

It had been almost a year since I patched my Openfiler 2.3 server, and some significant updates had been released in that time.  So after planning an outage window, I set out to apply the queued batch of updates (including mkinitrd and a kernel or two, more on that later).  It seemed such a simple task….

After the patches were applied, the Openfiler server would not boot.  Instead, it spewed out more errors than I could read to the console, ending with a kernel panic.

So I booted to the Openfiler install cdrom, and entered rescue mode with “linux rescue“.  Fortunately, it discovered and mounted all my partitions, and I was able to run with networking in order to reach the package sources or other sources/destinations if I should need them.

I noticed that the errors I had seen on the console pointed me toward missing drivers in the initrd, so I started looking there.  While poking around, I think I noticed that the latest update bundle had re-compiled all my initrd‘s in /boot. I’m not actually 100% sure about that now in hindsight, but it’s not important now.  Anyway, I de-constructed one of the initrd‘s this way to see what was up:

mkdir /tmp/temp
cd /tmp/temp
cp /boot/initrd-2.6.29.6-0.15.smp.gcc3.4.x86_64.img initrd-2.6.29.6-0.15.smp.gcc3.4.x86_64.img.gz
gunzip initrd-2.6.29.6-0.15.smp.gcc3.4.x86_64.img.gz
cpio -i --make-directories < initrd-2.6.29.6-0.15.smp.gcc3.4.x86_64.img
ls -l
ls -l lib/

Hmm.  No drivers there.  Should be a bunch of *.ko files…  Hmm…

I decided to roll back;  so I ran conary to revert to the state before the update  (Run “conary rblist” to figure out the number of the point-in-time to which to roll back, then “conary rollback (number)” to actually do it.  See this wiki page for details).

For some reason, this did not repair all my initrd‘s, but it did seem to give me a working mkinitrd script (in hindsight, I did not think to analyze it or keep a copy of it… drat).  So I was now able to hand-build a working initrd for one of the kernels (the most recent before the update) with this command:

mv /boot/initrd-2.6.29.3-0.3.smp.gcc3.4.x86_64.img initrd-2.6.29.3-0.3.smp.gcc3.4.x86_64.img.bad
mkinitrd /boot/initrd-2.6.29.3-0.3.smp.gcc3.4.x86_64.img 2.6.29.3-0.3.smp.gcc3.4.x86_64

And now, I was able to reboot into this kernel with my new working initrd…. and this time I made backups of it in my /home directory!

So I proceeded to re-apply the patches bit by bit.  I quickly realized that the dreaded kernel update was a requirement as part of the major Openfiler update, so it came back with the re-run of the last few updates anyway.  But this time, I was ready.  I modified the /boot/grub/menu.lst to use my old trusty kernel and initrd, (default=1), and make sure my hand-made initrd was in place.  Ok, good.  Reboot.  Right.

Back up in my older kernel (phew!), but with my newer kernel installed, I troubleshot…  I tried to build my own initrd against the new kernel, but I kept getting errors like this for each needed module:

/usr/bin/strip: /lib/modules/2.6.29.6-0.15.smp.gcc3.4.x86_64/./kernel/drivers/rtc/rtc-lib.ko: File format not recognized

I dove in to the /sbin/mkinitrd and found the cause.  There are some lines in an “if” block that optionally call “strip” if present, and that is where it seems to err out.  If “strip” is not present, it just copies the module, like I want.  Hmm.  I don’t know if strip was there before or not, or if the mkinitrd suddenly has this new “if” block, and I don’t care.  I commented it out to look like this:

for MODULE in $MODULES; do
#    if [ -x /usr/bin/strip ]; then
#        /usr/bin/strip -g $verbose /lib/modules/$kernel/$MODULE -o $MNTIMAGE/lib/$(basename $MODULE)
#    else
cp $verbose -a /lib/modules/$kernel/$MODULE $MNTIMAGE/lib
#    fi
done

…and re-built my initrd for the latest kernel like this:

mv /boot/initrd-2.6.29.6-0.15.smp.gcc3.4.x86_64.img initrd-2.6.29.6-0.15.smp.gcc3.4.x86_64.img.bad
mkinitrd -f -v /boot/initrd-2.6.29.6-0.15.smp.gcc3.4.x86_64.img 2.6.29.6-0.15.smp.gcc3.4.x86_64

…and no more errors!  Yay!  I modified the /boot/grub/menu.lst back to use my new kernel and initrd, (default=0), and I re-booted into it with no kernel panic! Yay!

And that’s my story.  I really hope this helps someone out there…

UPDATE, 20100127, evening:  On the Openfiler forums, there is talk of a fix.  To quote a Rafiu, “This was due to a strange situation where 64-bit version of binutils was not built and the group update succeeded regardless.

We have now resolved this issue. Apologies to all that were affected by it. “

I have not yet tested this, but I do see that the latest binutils is in the update list now.  More to come…

UPDATE, 20100128, morning:  Yes.  The latest set of updates at this time, *including* the correct set of binutils (2.17.50.0.6-7-0.0.2) for 64-bit, worked perfectly, and my server is still running as smoothly as ever after rebooting.  Hooray.  Though I will never get that Saturday night back that I spent chasing my initrd all over the place, but there you go…

This question came in from Steve in a comment:  “…I am looking for a way to run the “rug lu” command and have it dump the output my local machine to look over and see what updates I have ahead of me…”

So I replied, but then I thought of alot more stuff… so much more in fact, that I thought it deserved its own post…  So here you go, an “extended play” version of my reply…

For OpenSuse servers…

Please see this post:  http://yourlinuxguy.com/?p=324

That is exactly what I was going for in the post linked above.  If you download that script I mention there in that post, then change it to executable (for instance, chmod 700 filename), then run it, it will generate a comparison and dump the results to screen and output file, and tell you where the file is.

The script will not actually update your system (in the current state); it will only report about potential updates. But, if you get more brave, you can go in the file and un-comment the zypper lines I commented out that actually update the system…  Or change them to rug lines…  Which leads me to…

For SLES/OES servers…

Just do this:
rug lu > /tmp/lu.txt

…then go look at the file with:
less /tmp/lu.txt

…Or, you could have it emailed to yourself like this:
rug lu |mailx -s "Updates from $HOSTNAME" root

…of course, that assumes that you are having root mail sent off the box (see this if you’re not).  Otherwise you use your email address instead of root.

But what if you want to limit the updates list?  Perhaps something more specific; to report only that in which you are interested in updating?  See these examples (note that you can change the rug catalog to taste, of course, depending on your version):

rug lu -t patch SLES10-SP3-Updates OES2-SP2-Updates |mailx -s "Updates from $HOSTNAME" root

By adding a grep statement to block out the “optional” lines, the result is even cleaner.  Here’s an example:

rug lu -t patch SLES10-SP3-Updates OES2-SP2-Updates |grep -v optional|mailx -s "Updates from $HOSTNAME" root

On the other hand, by only *including* the lines you want (instead of excluding those you don’t), you lose the headers and separators, and only get the lines in which you’re interested (if any).  Here’s an example:

rug lu -t patch SLES10-SP3-Updates OES2-SP2-Updates |grep -e security -e recommended|mailx -s "Updates from $HOSTNAME" root

Or if you were to be running this in a mass-batch (hmm… future post…) to a bunch of servers or a cron job, and just don’t want an email at all if there are no results (and you *do* want an email if there *are* results):

RESULT=`rug lu -t patch SLES10-SP3-Updates OES2-SP2-Updates |grep -e security -e recommended`;if [ "XX$RESULT" != "XX" ];then echo "optional updates:" $RESULT |mailx -s "Updates from $HOSTNAME" root;fi

Okay now, that’s good; but here’s a prettier version of the same…  Okay, the command itself is uglier, but the resulting email is prettier at least.  The above one doesn’t format the results as nicely as I like (losing all the line returns), so I had to make use of a temp file to maintain the output formatted with returns:

rug lu -t patch SLES10-SP3-Updates OES2-SP2-Updates |grep -e security -e recommended>/tmp/ruglu.txt;RESULT=`cat /tmp/ruglu.txt`;if [ "XX$RESULT" != "XX" ];then cat /tmp/ruglu.txt|mailx -s "Updates from $HOSTNAME" root;fi

And that’s about it, with a couple closing thoughts:  Remember, it’s definitely a good idea to do a “rug ping” before doing this, to wake it all up, so you’re not waiting in silence for each command to run while it wakes up.  Then if you actually need updates, do this:

rug up -y -t patch -g security -g recommended SLES10-SP3-Updates OES2-SP2-Updates

Do you feel updated?  I do.

…module compilation process.

Seriously, folks.  I know there are others of you out there, like me, who upgraded to Opensuse 11.2 (the latest at the  time of this writing), without concern that VMware Server 2.0.2 (also the latest at this writing) may or may not run on it.  Well guess what: it doesn’t.  Well, not without help, that is.

To cut to the chase, as I write this, the problem is that VMware Server 2.0.2 will not work with the newest kernel and libraries that are shipped with Opensuse 11.2, version 2.6.31.x.and.so.forth.  So I found some work-arounds while Googlin’, that I wanted to record for posterity.  Here’s what I did:

1. Go to this post from Radu Cotescu.  Read up.  Note that Radu’s post, problem, and fixes are all about Ubuntu.  Do not fear.  (Post-publish update, 20100119:  See http://radu.cotescu.com/2010/01/19/how-to-install-vmware-server-ubuntu-fedora-opensuse/ for a new version that I have not tested yet.)
2. As he instructs in his step 1, download the VMware 2.0.2 tgz file from VMware themselves (version 2.0.2-203138 at this time), and drop it in a directory like /tmp/vmware.  DO NOT decompress the tgz file!  The script will do it for you.
3. Get Radu’s script, and as instructed in his step 2, drop it in the same folder as the VMware tgz file, for instance, /tmp/vmware.
4. Here is where we slightly vary from the plan… open the script up in a text editor (vi, gedit, emacs, etc.), go down to the “install” section around line 76, and comment out all the “dpkg-query” checks from line 77 to line 95.  Save, and quit.  Funny… but I don’t remember those checks being there a month or so ago, so he may be changing them from day to day.  Tread carefully, and don’t necessarily trust my indicated line numbers.
5. Make sure we have the necessary script support software installed;  you need your kernel version “devel” package (for me, since I have kernel-pae, I need kernel-pae-devel), kernel-source, linux-kernel-headers, gcc, and make.  Use zypper in <package-name> to get them installed.
6. Now return back to Radu’s step 3, and complete his commands as listed.
7. If all goes well, when you follow his instructions, it will compile everything, and launch you right into to the VMware installation, and continue into the configuration.  Make sure you have your VMware registration code handy.  Oh, and of course, ignore that GCC version mis-match warning… And you may want to do a chkconfig vmware off when you’re done, I always do.

So there you go.  That’s the only way I could get it all to work together.  But if you know of a better way, or if I missed something, please share it with the group!  I assume that VMware will get a corrected version out in the near future that will mitigate this issue, but in the meantime, it’s a real life-saver.  And many, many thanks to Radu and any others involved….