Zimbra 8.0 upgrade from Zimbra 7.2 on CentOS 6.x quicky

Woot Woot. The rather well done Zimbra Collaboration Server ("enterprise-class email, calendar and collaboration solution") has a major version change from 7.2.1 to version 8.0.0! We choose to run the Zimbra Collaboration Server Open Source Edition (OSE). We have previously upgraded through the 7.1 and 7.2 series with no issues. This is a brief overview of what needed to happen to get from 7.2.0 -> 8.0.0 on my CentOS 64-bit test server. I will take the production system from 7.2.1 -> 8.0.0 after a couple of weeks of random testing. I'm not crazy enough to just put a dot0 version in production. I may even wait a month to make sure enough bugs are worked through. I do have a job I want to keep ;)

Naturally, one should start by reading the very informative Zimbra 8.0.0 GA Release Release Notes. I am glad to see the "Inline reply", "Autocomplete matches now work correctly for Contact Groups" bugs fixed! The "Per folder message retention policy creation" added is long overdue IMHO. Don't short change your upgrade by skipping the release notes. You *should* take the time to go through it!

As root:

screen

tar -xzvf zcs-8.0.0_GA_5434.RHEL6_64.20120907144639.tgz

cd zcs-8.0.0_GA_5434.RHEL6_64.20120907144639

./install.sh --platform-override

To get the new 5 year default SSL cert, you will want to run as user zimbra:

sudo /opt/zimbra/bin/zmcertmgr createca -new

sudo /opt/zimbra/bin/zmcertmgr deployca

sudo /opt/zimbra/bin/zmcertmgr deploycrt self

Production server upgrade note (10/29/2012):
The Zimbra 8.0.0 upgrade/install seems to have reset several of my custom settings to default attributes! I have made most of my custom changes based on the very handy Zimbra wiki for Performance Tuning Guidelines for Large Deployments in the past. The main changed items I've spotted so far are zimbraImapMaxConnections and zimbraImapNumThreads that reverted back to 200. I hope not to find too many more production system oddities! The reason I noticed the issue is that the /opt/zimbra/log/mailbox.log had MANY messages like:
WARN  [ImapServer-76] [] imap - Dropping connection (max connections exceeded)
WARN  [ImapServer-80] [] imap - Dropping connection (max connections exceeded)

Adobe Acrobat Reader 64-bit CentOS (RHEL or SL) linux LDAP problem

Let me start by saying, "Shame on you Adobe!" for not recognizing an opportunity to continue in the Linux OS realm in a meaningful way... I already use Evince more for PDF files now anyway. No more real Flash support is just another nail in the coffin.

Here's the deal; Adobe doesn't have a 64-bit Acrobat Readear (acroread). So, when you need to install the 32-bit version you get only some of the 32-bit stuff gets installed. More may actually be needed. This is especially true if you have LDAP (openldap) at the center of the authentication realm. You will end up with a message like:

GLib-WARNING **: getpwuid_r(): failed due to unknown user id

As user root, you will need to run:

yum -y install nss-pam-ldapd.i686

Eye-Fi Connect X2 mini review/recommendation

Summary:

Eys-Fi makes a nice little SD card with built-in wifi called an Eye-Fi Connect X2 among others. This little gem is great! The title should really be, "Amazing geek toy and CYA device"...
I find the Eye-Fi Connect X2 card and Android Eye-Fi App to be very useful and mostly reliable on my Samsung Galaxy Tab Plus GT-P6210 running both the original Android 3.2 Honeycomb and recently updated Ice Cream Sandwich. There is a great deal of comfort knowing I have an immediate backup copy of every picture I take. 

Background:

Since pictures are of major importance to me. Safeguarding my photos with multiple copies is a priority. Under normal circumstance, I would take some random number of pictures, head to my laptop or home system, copy the pictures, rotate out the SD card, take more pictures, etc.

I had an original Eye-Fi card from a couple of years ago. I tried a couple of the Linux options like the python powered eyefiserver with some luck. Sadly, at the time, this option was not very portable since it needed an access point plus laptop or similar. Besides, reading the original eye-fi card was a pain for me under Linux.

Skip ahead a couple of years and the X2 versions... and add a tablet or smart phone and Ad-hoc network support of wireless uploads... welcome to a whole new world.

Now with my Android powered phone or my great little Samsung Galaxy Tab Plus GT-P6210 and the Android Eye-Fi App (or IOS App), I just start the App, shoot a pic and have an original sized copy on my phone or tablet!

OK there's a bit more to process of course. Some will not like the *requirement* to have an Eye-Fi account to use the app. Others will note that I needed to register the SD card with a Windows system. I wish that was different, but it's not.

Just as a side note, the Ad-hoc network range was about 40-45 feet as a general rule for quick transfers. As the distance got just past this range, the time to upload increased by minute(s). So, proximity does matter as you would expect for such a tiny device. Also, I did have a couple of times that the Ad-hoc network would not connect. Restarting the app seemed to provide relief.

OMSA 7.0 firmware update issue or holdover public key problem from 2010?

Updated Dell's OMSA from 6.5.1 to 7.0 via  standard yum process. Checked for any new goodies via "yum install $(bootstrap_firmware)". Tried to update firmware, but failed:

# update_firmware  --yes
Running system inventory...
Searching storage directory for available BIOS updates...
Checking BIOS - 6.1.0
Available: dell_dup_componentid_00159 - 6.1.0
Did not find a newer package to install that meets all installation checks.
Checking SAS/SATA Backplane 0:0 Backplane Firmware - 1.07
Available: dell_dup_componentid_11204 - 1.07
Did not find a newer package to install that meets all installation checks.
Checking PERC 6/i Integrated Controller 0 Firmware - 6.3.1-0003
Available: pci_firmware(ven_0x1000_dev_0x0060_subven_0x1028_subdev_0x1f0c) - 6.3.1-0003
Did not find a newer package to install that meets all installation checks.
Checking OS Drivers - 0
Available: dell_dup_componentid_18981 - 7.0.0.4
Found Update: dell_dup_componentid_18981 - 7.0.0.4
Checking Dell Lifecycle Controller - 1.5.1.57
Available: dell_dup_componentid_18980 - 1.5.2.32
Found Update: dell_dup_componentid_18980 - 1.5.2.32
Checking NetXtreme II BCM5709 Gigabit Ethernet rev 20 (eth1) - 6.2.16
Available: pci_firmware(ven_0x14e4_dev_0x1639) - 6.2.16
Available: pci_firmware(ven_0x14e4_dev_0x1639_subven_0x1028_subdev_0x0235) - 7.0.47
Found Update: pci_firmware(ven_0x14e4_dev_0x1639_subven_0x1028_subdev_0x0235) - 7.0.47
Checking NetXtreme II BCM5709 Gigabit Ethernet rev 20 (eth0) - 6.2.16
Available: pci_firmware(ven_0x14e4_dev_0x1639) - 6.2.16
Available: pci_firmware(ven_0x14e4_dev_0x1639_subven_0x1028_subdev_0x0235) - 7.0.47
Found Update: pci_firmware(ven_0x14e4_dev_0x1639_subven_0x1028_subdev_0x0235) - 7.0.47
Checking ST3450857SS Firmware - es65
Available: dell_dup_componentid_20795 - es65
Did not find a newer package to install that meets all installation checks.
Checking iDRAC6 - 1.80
Available: dell_dup_componentid_20137 - 1.85
Found Update: dell_dup_componentid_20137 - 1.85
Checking NetXtreme II BCM5709 Gigabit Ethernet rev 20 (eth2) - 6.2.16
Available: pci_firmware(ven_0x14e4_dev_0x1639) - 6.2.16
Available: pci_firmware(ven_0x14e4_dev_0x1639_subven_0x1028_subdev_0x0235) - 7.0.47
Found Update: pci_firmware(ven_0x14e4_dev_0x1639_subven_0x1028_subdev_0x0235) - 7.0.47
Checking NetXtreme II BCM5709 Gigabit Ethernet rev 20 (eth3) - 6.2.16
Available: pci_firmware(ven_0x14e4_dev_0x1639) - 6.2.16
Available: pci_firmware(ven_0x14e4_dev_0x1639_subven_0x1028_subdev_0x0235) - 7.0.47
Found Update: pci_firmware(ven_0x14e4_dev_0x1639_subven_0x1028_subdev_0x0235) - 7.0.47
Checking Dell 32 Bit Diagnostics - 5154a0
Available: dell_dup_componentid_00196 - 5154a0
Did not find a newer package to install that meets all installation checks.
Checking System BIOS for PowerEdge R710 - 6.1.0
Available: system_bios(ven_0x1028_dev_0x0235) - 3.0.0
Did not find a newer package to install that meets all installation checks.
Found firmware which needs to be updated.
Running updates...
/ Installing dell_dup_componentid_18981 - 7.0.0.4Installation failed for package: dell_dup_componentid_18981 - 7.0.0.4
aborting update...
The error message from the low-level command was:
Update Failure: Partition Failure - The Delete Dynamic Partition has failed

Tried the /etc/redhat-release fix without success. Tried a reboot to flush out any oddities...

After much google'n it seems that I had some kind of public key issue:

rpm --import http://linux.dell.com/files/libsmbios/download/RPM-GPG-KEY-libsmbios
rpm --import http://lists.us.dell.com/linux-security-publickey.txt

Now update_firmware works again as expected.

CentOS 6.3 mdadm won't start older md arrays.

For some of us, the drive setups we create stays with a system for a long time. Keeping the same data disk array untouched even for major revision changes is common (like a OS rebuild of 5.x -> 6.x). Sometimes that long term usage bites back. Here is my failure case while upgrading from CentOS 6.2 -> CentOS 6.3.

Symptoms:
Simply md RAID 1 extra data drive will not boot. The system drops to recovery mode with a missing (md) drive to mount and an fsck request. The extra file system has 2 "linux_raid_member" drives that show under fdisk and blkid. Even a "cat /proc/mdstat" shows no arrays. If I run, as root:

mdadm --auto-detect

the /proc/mdstat will finally show info, however.

Solutions:

1. Make sure that the /etc/mdadm.conf contains the array info from: 

   
   mdadm --examine --scan >> /etc/mdadm.conf
   
   

2. There seems to be kinda "depreciated" mdadm technical note about older created arrays with BZ-788022 implicated and a "+0.90" needing to be added to/etc/mdadm.conf, but you need to get rid of the "+1.x -all" options!

How do you tell in advance that you will have an issue *before* an upgrade? If  you run, as root,

mdadm -E /dev/sdc1|grep Vers

and get output like: "Version : 0.90.00", you will want to make a change *before* you reboot!

It is interesting to note that I was able to just have this md array work in 6.0, 6.1 and 6.2 because,

In Red Hat Enterprise Linux 6.1 and 6.2, mdadm always assembled version 0.90 RAID arrays automatically due to a bug.

"DEFROUTE" in RHEL, CentOS or Fedora - a usage case for eth0

Here is the situation: There is a user with a remote office that includes networking equipment like printers, backup server etc. He uses a company provided CentOS laptop as the gateway for his network via a cell card since there is no other cheaper option available to get him connected. He travels with the laptop often and I don't need access to the equipment at his office unless he's there. The user always connects either via WIFI or a cell card for VPN connection depending on what is available. The laptop is running openvpn and is connecting to our company's openvpn server. No problem... until I want to also connect the laptops ethernet cable and use NetworkManager and use a DHCP server for the eth0... That's when the VPN drops and the laptop now has an incorrect default route. What's odd is that order of interface startup does not matter... dhcp on eth0 wins no matter what... bummer.


What's happening? Well, normally with DHCP, the client is given a default route as part of the information exchange. That eth0 default route takes over. It's just that simple... unless you give the networking system guidance on what to do in the form of the "DEFROUTE" option. The option has been around for a long time. The current Red Hat Enterprise Linux 6 Deployment Guide has DEFROUTE option hidden in the 8.2.4. Dialup Interfaces section. Here is a chunk of the information from the guide:

DEFROUTE=answer

where answer is one of the following:

• yes — Set this interface as the default route.
• no — Do not set this interface as the default route.         

In the past, I did not use the DEFROUTE option. I found that I could just statically assign the eth0 and *not* let NetworkManager have access to it (NM_CONTROLLED=no). In fact with Centos (and the like), NM seems to get disabled as a generally rule.

Also, if this was a server or I wanted to statically assign the interface, it would not be an issue. Just one of those fringe usage cases.

LTSP 5.2.x rsh server on client install, setup and HOWTO

Don't start with the, "rsh is bad..." message. I know, I know! It's an internal test network and was just easy to do for remote client checking. Besides, the "ltsp-localapps" only works for the logged in user and does not allow for arbitrary root user interaction with the client. If there is a built-in way to do this, let me know. At some point, I may try sshd client setup.

I am using CentOS 6.x as the server OS and customize the client build to be CentOS 6.x also. LTSP 5.2 is the software from k12linux at fedorahostedI don't think that affects the directions below in any way, however. And if this looks like part of a script, you would be correct.

Change the LTS_HOME variable to your own LTSP client build location on the server as required:

export LTS_HOME="/opt/ltsp/i386"

Check to make sure rsh is allowed in securetty for the client:

grep -q "^rsh" $LTS_HOME/etc/securetty && echo rsh >> $LTS_HOME/etc/securetty

Get rsh-server installed into you chroot'd environment:

Option 1 (re)creates the client build to have rsh-server instaled and includes future builds:

edit the "/etc/ltsp/kickstart/Fedora/common/release/el6.ks" and add "rsh-server" *before* the "%end" line. Then (re)run the ltsp-build-client and ltsp-server-tweaks as if a new install:

ltsp-build-client 2>&1 |tee /tmp/ltsp-build-client.out-`date +%Y%m%d%H%M`


cd $LTS_HOME

setarch i386 chroot .


chkconfig rsh on

ltsp-server-tweaks

Option 2 install and setup the rsh-server for this client build only:

cd $LTS_HOME

setarch i386 chroot .

mount -t proc proc /proc

#set proxy if needed

yum install rsh-server

chkconfig rsh on

umount /proc

Get the clients /root to be based on the $LTS_HOME/root from the server and not a tmpfs by commenting the "/root" line of k12linux.rwtab:

sed -i 's/^empty[[:space:]]\/root/#empty\t\/root/'$LTS_HOME/etc/rwtab.d/k12linux.rwtab

OR for you perl peeps

perl -p -i -e "s/^empty\t\/root/\#empty\t\/root/g" $LTS_HOME/etc/rwtab.d/k12linux.rwtab

Note: To safeguard your custom options from accidental rpm update overwrites, please consider creating your own blah.ks file to be referenced in /etc/ltsp/ltsp-build-client.conf.

Properly create a .rhosts file for the clients root user. This script chunk assumes the primary (eth0) interface is the interface that communicates with the clients. If your primary server interface is not the interface for client connection, you will need to add/modify the client's .rhosts file accordingly:

echo "server-`hostname --ip` root" >> $LTS_HOME/root/.rhosts
echo "rsh" >> $LTS_HOME/etc/securetty
chmod 600  $LTS_HOME/root/.rhosts

Now boot the client and test an rsh command from the server to the client. If you have issues, you will want to add a "shell" option for the client in the correct lts.conf then reboot the client. For i386 arch, the file is "/var/lib/tftpboot/ltsp/i386/lts.conf". This will give you a chance to see the /var/log/messages file if you have not setup remote logging for the client.

To make a custom PXE boot logo change, create/modify a theme run the following command from within the chroot:
ltsp-rewrap-latest-kernel

To apply a new theme
Create a new plymouth theme. You can do this by making simple variations on the stock theme by taking a copy of the default theme using the procedure below. You can replace "newtheme" in the commands below with whatever name you want to give the new theme. This procedure assumes the chroot is in the /opt/ltsp/i386 directory.

Start by copying the folder with this command:

cp -a /opt/ltsp/i386/usr/share/plymouth/themes/solar /opt/ltsp/i386/usr/share/plymouth/themes/newtheme

Now modify "newtheme" as appropriate. First go into the new theme directory by typing:

cd /opt/ltsp/i386/usr/share/plymouth/themes/newtheme

Then rename the .plymouth file by running:

mv rings.plymouth newtheme.plymouth

Edit the .plymouth file and change:

Name=Rings

to:

Name=Newtheme

and change:

ImageDir=/usr/share/plymouth/themes/rings

to

ImageDir=/usr/share/plymouth/themes/newtheme

You may also want to change the background colors. BackgroundStartColor is the color at the top of the screen and BackgroundEndColor is the color at the bottom of the screen. Plymouth will make a gradient of these colors across the screen. For example to make the background change from white to black change the lines:

BackgroundStartColor=0x080808
BackgroundEndColor=0x080808

to:

BackgroundStartColor=0xffffff
BackgroundEndColor=0x000000

When finished making changes save the file.

Next replace the image file named header-image.png with the desired replacement. Do not change the name of this file!

The exact size does not seem to matter as the plymouth will center it in the screen above the animated "rings".

You can also get fancy and replace all the other progress images also.

Chroot to the client directory by running:

chroot /opt/ltsp/i386

Activate the new theme with this command:

plymouth-set-default-theme newtheme

Note: you may get an error from sed (ex: sed: warning: failed to set default file creation context to unconfined_u:object_r:usr_t:s0: No such file or directory). This does not seem to cause problems.

Build a new initramfs file with the new theme:

ltsp-rewrap-latest-kernel

Exit the chroot by typing:

exit

and update the tftp directory with the new initramfs by typing:

ltsp-update-kernels

If you use NBD you will also need to run:

ltsp-update-image

Now fire up a client and enjoy the new theme!

Static DHCP is better than IP address assignment on a device

//BEGIN RANT//

Attention standalone network attached device vendors like large copier manufacturers:

Please train your onsite personnel in understanding that a DHCP assigned address is not always a "Dynamic" address. Please help them understand that there is such a beast as "Static Allocation DHCP" or "Address Reservation". And that Static DHCP gives the equipment *the same address* every time. And help them realize that the equipment will work just fine on the network and won't magically just break. And that I can change every part of the network properties without touching the dumb box or it's crappy web/console interface. Please also train them to not go behind a client's back who gives explicit instructions on keeping the DHCP option enabled (and then enabling a static address on the device).

//END RANT//

JShot - multiplatform screen capture and annotator

Recently, I needed to do a minor amount of screen annotation. I was very pleased to have found JShot for my Linux system. As quoted from the website,

"JShot is a free and multiplatform screen capture and uploader application which allows you to capture and annotate a part of your screen and share it via the Internet in one step."

And as luck would have it, one of the upload options is for Google's Picasaweb that helps provide images for Blogger.

JShot is a usefully featured screen capture program. It is fast in screen, area or region capture. JShot has an optional toolbar dock that lets you quickly take the screenshot you want. There are several easy to select and use annotation tools. The tools include circles, ovals, squares, rectangles, arrows or text. I like the transparency and highlight options for those tools. Arrows and text input pivot and rotate with little effort. Text input font is easy to modify.

JShot will also open arbitrary image files for annotation beyond just the screenshot image taken. Nice additional features include the mentioned Picasaweb single click upload as well as FTP or Dropbox to name just a couple. You can even free-hand draw on your screen prior to screen capture (yes that is close to my normal handwriting scribble).

JShot also includes an extendable plugin capability for those needing something more. Did I mention the Java Web Start option?

There are just a couple of minor issues from my usage attempts. First, large images can not be scaled to fit on the screen. Also, the shapes can not be rotated (not that you rotate a circle). They move on an vertical or horizontal axis only. The "File" -> "Open" dialog does not remember last settings (for stuff like this, the date sort is more often what I want). I would also like to see the auto-number name incrementing that other screen capture utilities have like ksnapshot.  Another only slightly annoyance is the "File" -> "Exit" produces a "All unsaved data will be lost" message even if you *just* saved. Fairly nit-picky issues overall. None outweigh the very useful capability.

I have not been much of a java app fan, but JShot is a very well done utility that will remain in my Linux geek toolbox. Hope you enjoy this utility as much as I have. And just to be clear, JShot screen capture and annotator works for Mac, Windows and Linux.

Google Voice + Talkatone + iPhone/Android = Google VOIP phone

I had an older iPhone 3gs sitting around after upgrading to an (much better) Android handset a while back. The contract was over for the iPhone and was ultimately claimed by my son. He has been watching Youtube videos and playing games on the thing ever since. For some strange reason, I decided to check for SMS and VOIP options for it's WIFI connection. The generic search of "iphone 3gs VOIP" lead to many options. Most were not free or just not what I was thinking. At some point I stumbled onto the free Talkatone app with the promise of "Unlimited FREE calls, texts and picture sharing to Facebook and GTalk friends, or any phone number in US/Canada." Wow, what a statement. I am happy to say that from my point of view, they are correct.

The Getting Started section spells out the general procedure. It was actually easy. I had already setup a Google account for my son and just added the Google Voice upgrade. No big deal. With prerequisites done, the Talkatone install was easy. The combination just worked. My only marginal issue is the voice lag starts to get on the slightly noticeable side. Not a deal breaker noticeable mind you. And yes, I was able to call the iPhone from other phones just like they say.

I did try to setup a SIP account at an early stage of just playing with a couple of apps. Not very easy and did not work for me. So, having this combo made my geeky day. Besides, almost any time you can integrate with Google, you are going to be better off. It has so much of my digital life anyway.

Just so it's clear, Talkatone will work on both the iPhone from the App Store and Android handset from Google play.

This is not actually a thorough review or install howto. I just have some general praise for a geeky and fun product combination that works. The Talkatone peeps have done a great job!

Enjoy

CentOS 6.2 BCM4312 working wifi howto

Linux on laptops has come a LONG way over the years. I am happy to say that most Linux installs for laptops go with very little or no issues. Recently decided to install CentOS 6 (but I'm sure this applies to RHEL 6 or SL6) on an otherwise decent Dell D630 laptop. My only issue was wifi not working out of the box. The "issue" seems to be mostly about the BCM4312 802.11 card in the laptop. Here is the easy fix:

1. Get the "updated" el6 b43-firmware rpm from the Russian Fedora guys. (make sure it's the *el6* version)
 

wget "http://koji.russianfedora.ru/koji/buildinfo?buildID=1041"

2. Install it (current version depreciates the b43-openfwwf package nicely)

yum install b43-firmware-5.10.56.27.3-2.el6.noarch.rpm

3. Wait several seconds and the wifi light comes on and wifi works!

I originally tried with the documented b43-fwcutter -w "$FIRMWARE_INSTALL_DIR" broadcom-wl-5.100.138/linux/wl_apsta.o but failed to extract the firmware needed.

I also looked into the kmod-compat-wireless but current information suggest, "RHEL6 packages are broken at present". Enjoy.

Here is all of the info from the BCM4312 card in question:

lspci | grep BCM
0c:00.0 Network controller: Broadcom Corporation BCM4312 802.11b/g LP-PHY (rev 01)

lspci -n | grep 14e4

0c:00.0 0280: 14e4:4315 (rev 01)

Original /var/log/messages indicated:

b43-phy0 ERROR: Firmware file "b43/ucode15.fw" not found
b43-phy0 ERROR: Firmware file "b43-open/ucode15.fw" not found
b43-phy0 ERROR: You must go to http://wireless.kernel.org/en/users/...devicefirmware and download the correct firmware for this driver version. Please carefully read all instructions on this website.

Google Music Manger issue with .ogg file?

Had a very head scratching issue with the (at least the) Linux version of Goggle Music Manger. GMM claims to have uploaded all of the songs and produced some errors on some individual song titles. I didn't think much of the errors since the upload showed successful. I then went to the Google Play page to take the next step of creating some play lists. To my surprise, I only had the original group of files I uploaded a while back and the recently purchased songs from Google (practically a) give-way of albums from last week. I went back to look at the errors noted by Google Music Manager and deleted from disk the files that were named in the errors. I was left with a single error from the "Run Troubleshooter" option; and the error listed that had no filename and a error with just "Failed to upload". Kinda odd to find no filename... Finally noticed that after hitting "Apply" and "Ok" I saw a "0%" on a Al DiMeola song and went searching for it. Immediately after moving the file from the original disk location on my system, Google Music Manger had a little green icon turn on and Google Play began to see the songs. That Al DiMeola song was an otherwise legit and playable .ogg file. I can only suspect that GMM does not like OGG files at this point, but doesn't want to ignore them. Hope my pain is your gain with Google Music Manager.

Dell Server Update Utility (SUU) v6.5.3 64-bit CentOS/RHEL 6 problems

Just going to vent here for a minute, so stay with me...Why? Why would you have so many 32bit dependencies when running SUU on a 64bit OS. I mean Dell has already shown that OMSA for 32bit is not going to happen going forward. At least fix your own documentation for requirements... please.

So, to get SUU 6.5.3 functional on a 64bit CentOS 6.2 or RHEL 6.x server (and SL I bet), you *will* need to:

yum install pam.i686 libXtst.i686 libXext.i686 compat-libstdc++-33.i686 pam.i686

As noted in the comments by Carlos Capriotti, if you want to run the GUI stuff, you will need a couple more packages:

yum install ncurses-libs.i686 libXp.i686

Verizon pc770 wireless card setup on CentOS 6.x

It's a very good time in a Linux lovers life when you can just say, "it works"... Because of all of the hard work of countless volunteers (and/or paid professionals). I am pleased to announce that the crappy unount of the virtual CD ROM is no longer needed in CentOS 6.x (or SL 6, RedHat 6)!

Thank You!

1. Plug in the card
2. Select the provider
3. Follow the prompts
4. Activate the card

NICE. It just WORKS!

P.S. Sorry about the situation for CentOS 5.x, but it's, "doable".

CentOS 6.x VMware Workstation 7.1 installation issue solved.

As this writing, VMware-Workstation 7.1 has issues building vmmon on CentOS 6.2 and therefore SL 6 and RHEL 6 also. After some head scratching, google'n and lots of reading, here is the easy way to get up and running.

This install example is for VMware-Workstation-7.1.5-491717.i386.bundle at the very least. Download that from VMware as you would normally.

First, make sure you have booted to the most recent kernel before installing. Otherwise you will not be able to build the VMware modules against the kernel you are running.

First, make sure to have some basic prerequisites before you start:

yum install gcc gcc-c++ kernel-headers kernel-devel

Next install (or update) the VMware-Workstation bundle as root and valid $DISPLAY set:

bash VMware-Workstation-7.1.5-491717.i386.bundle

Follow the promps as usual.

Bummer, vmmon won't load and produces errors in /var/log/messages like:
kernel: vmmon: disagrees about version of symbol smp_ops
kernel: vmmon: Unknown symbol smp_ops

First attempt at a work around yields the ever helpful Akemi Yag (aka "toracat")  blog and the perfect *helpful* comment by NomadAU. Why is that Redhat Bugzilla entry closed anyway??


Here is the portion that is key to fixing the issue; as root:

mv /usr/lib/vmware/modules/binary/bld-2.6.32-*-rhel6 ~/

Finally run:

vmware-modconfig --console --install-all

How to get system-config-netboot working on CentOS 6, RHEL 6 or SL 6

Sadly, Redhat has decided to drop system-config-netboot from it's offerings for RHEL 6. I was very much accustomed to the simplicity of using system-config-netboot for PXE boot client installs. Redhat may have not included the packages to install system-config-netboot, but it is certainly easy to get running on your RHEL 6 or clone. Here is the CentOS 6 i386example (please run commands as root or sudo you guts out):

1. Make sure some pre-requisites are in place:

yum install tftp-server xinetd pygtk2-libglade gnome-python2-canvas

2. Adjust for your arch type: Download the latest CentOS 5.x system-config-netboot* and alchemist* versions:

wget http://mirrors.kernel.org/centos/5/os/i386/CentOS/system-config-netboot-0.1.45.1-3.el5.noarch.rpm
wget http://mirrors.kernel.org/centos/5/os/i386/CentOS/system-config-netboot-cmd-0.1.45.1-3.el5.noarch.rpm
wget http://mirrors.kernel.org/centos/5/os/i386/CentOS/alchemist-1.0.36-2.el5.i386.rpm

3. Force the install of the above packages:

rpm -ihv --force --nodeps system-config-netboot-* alchemist-1.0.36-2.el5.i386.rpm

4. Move part of the installed alchemist package to the correct place... bad administrator! ;)

mv /usr/lib/python2.4/site-packages/* /usr/lib/python2.6/site-packages/

Running "system-config-netboot" through some warning message at me, but it did what I wanted it to do

Yeah, it's a bit hackish. I'm OK with it if you are. You *could* rebuild the source rpm for each of them correcting the the alchemist path etc. I will for my systems, but this is the "easy" version of the "How to get system-config-netboot working on CentOS 6, RHEL 6 or SL 6" after all...