Thursday, June 2, 2011

My Tracks Android GPS route tracking app - mini review

I like to ride my road bike. I upgraded a year ago from a heavy 30lb mountain bike to a Fuji Roubaix Pro road bike off of craigslist. MUCH lighter at about 19lbs. I'm too lazy to actually chart my own road trip information. So, a quick google'n for a handy GPS app for my Droid X lead me to My Tracks. What a great find!

My Tracks reports itself as:
My Tracks records your GPS tracks and shows live statistics such as time, speed, distance, and elevation – while hiking, cycling, running or participating in other outdoor activities. Once recorded, you can share your tracks, upload them to Google Spreadsheets and visualize them on Google My Maps.

Here's a quick summary of the My Tracks Android app:
First, My Tracks is drop-dead easy to install. However, you expect ease of installation since basically all market place apps are easy to install.

My Tracks is very easy to just use. Start by enabling your GPS satellites on your phone. Not a big deal if you forget as My Tracks will remind you. That push-pin on the Google powered map is now your location. Want to see the satellite view of your current location, simply press Menu Key and toggle the Satellite/Map view option. Want to start a new GPS tracking session, just press Menu Key and Start Recording. Finished with the trip, well not surprisingly, press Menu Key and Stop Recording will stop collecting data.

The real beauty of My Tracks is what it will do after the collecting is done... the mapping and displaying and summarizing etc. My Tracks is geared toward google services - like it or not. I, personally, like it. Heck even the My Tracks web site is "Powered by Google App Engine". So, the visual gratification is to press the "+" icon on the screen and select to upload to Google and My Tracks will use your account to optionally create (Google) maps with the tracks or a (Google) fusion table to visualize your data points. Very cool overall!

Not into Google, no problem! My Tracks will allow you to export or email as  .gpx or .kml files. Heck, you can even tweet your ride. Check out the FAQ for more information on those features.

My only issue if you want to call it an issue is there is no delay option for starting. It does take me a several seconds to secure my Droid in it's pouch on the bike, get in on one pedal and start to ride. So, there, that's what could be improved ;)

On a side note, I am pleased to see that My Tracks source code is created with an Apache 2.0 License and is Open Source!

Note: Apps like "ShootMe" (Screen Grabber) seem to disable My Tracks ability to function for anything but time (as I learned the hard way).

Thursday, May 19, 2011

Dell printer warranty gathering information bash script for linux/unix

We have a LOT of different printer. A large number of them (over 60 and counting) are Dell branded printers. This includes laser printer models like the:
Dell Color Laser 3110cn
Dell Laser Printer 5210n
Dell Laser Printer M5200
Dell 5330dn Laser Printer
Dell Laser Printer 1720dn
Dell Laser Printer 5310n
Dell 2335dn MFP
Dell 2355dn Laser MFP
Dell 1815dn MFP
Dell 1600n MFP
Dell 3335dn MFP

I had a need to make sure to get all newer printers under warranty. Most of the units above have a web interface and most of the time the Service Tag is viewable from that interface. However, I'm very lazy even when it comes to clicking through all of the different types of printer web interfaces... then needing to go to Dell's support web site to manually check each Service Tag...

Naturally, I had to hack some shell script to do all of the dirty work for me. You will need snmpwalk, links, w3m and some added web fluff in the for of sortable columns and line highlighting via Sortable Table 2 java script. The script below will provide info on all printers found, just not warranty or Service Tag for non-Dell printers. The other good part is that you can tell from the "sysDescr.0" what firmware a printer is running also.

I don't remember why I have both links and w3m since this script was created a while back. I just thought it would be nice to post it now. Naturally, you could change out all of the html fluff and dump straight to csv for easy import into whatever you want.

If you have suggestions on code cleanup, I would love to see them. I think I have all the internal company specific stuff taken out and still usable. Enjoy. Sorry the formatting looks *UGLY*, but blogger freaks on the "span" greps in the code and this is the only way I have figured out how to show the code here. I need to verify that the stuff coming out of blogger is still working...

#!/bin/bash

WEBPINFO="/var/www/html/SOME/DIR/Printer_Info.html"
JSPATH="http://`hostname`/SOME/DIR"
PINFO="$WEBPINFO.`date +%y%m%d`"

cat > "$WEBPINFO" << EOF
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<title>Printer Warranty and firmware Information - sortable</title>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
<script type="text/javascript" src="$JSPATH/sortedTable.js"></script>
<link type="text/css" href="$JSPATH/sortedTable.css" rel="stylesheet"/>
<link type="text/css" href="$JSPATH/nav.css" rel="stylesheet" />
<style>
        .red{color:crimson;}
        #nav{font-size:0.82em;}
</style>
</head>
<body>
<div class="tableWrapper">
<table id="table_1">
<thead>
<tr class="headerLine"><th class="sorttable_alpha">Hostname</th> <th class="sorttable_alpha">sysDescr.0</th> <th class="sorttable_mmdd">warranty expire</th> <th class="sorttable_alpha">Service Tag</th> <th class="sorttable_alpha">Printer name</th></tr>
</thead>
<tbody>
EOF

#get all network based print servers and exclude if needed
for PRINT_SERVER in `lpstat -t | egrep 'lpd://|socket://' |egrep -v 'SOME_PRINTER|SOME_OTHER_PRINTER'| cut -d"/" -f3 | cut -d":" -f1 | sort -u`
do
 unset SER ST PRTS http_proxy
 PRTS=`lpstat -t|grep $PRINT_SERVER[/:]|awk '{ print $3 }'|tr -s ':\n' ' '`
 ping -c 2 $PRINT_SERVER >& /dev/null
 if [ $? -eq 0 ]; then
   MOD=`snmpwalk -Os -c public -v 1 $PRINT_SERVER sysDescr.0  | cut -d":" -f2 `
   echo $MOD | grep -qi dell
   if [ "$?" -eq 0 ]; then
      #2335dn and JD24 and 1815dn are the same ST, but hrDeviceDescr.1 provides firmware version.
      if [ "`echo $MOD | egrep -qi '5330dn|2335dn|2355dn|JD24';echo $?`" -eq 0 ]; then
        ST="`links -dump http://$PRINT_SERVER/printer_info.htm|grep Service|tr -s ' '|cut -f6 -d ' '`"
      elif [ "`echo $MOD | egrep -qi '1815dn';echo $?`" -eq 0 ]; then
        MOD="$MOD `links -dump http://$PRINT_SERVER/printer_info.htm|grep 'Printer Firmware Version:'|cut -f2 -d ':'|tr -s ' '`"
        ST="`links -dump http://$PRINT_SERVER/printer_info.htm|grep Service|tr -s ' '|cut -f6 -d ' '`"
      elif [ "`echo $MOD | egrep -qi '3335dn';echo $?`" -eq 0 ]; then
        ST="`links -dump "http://$PRINT_SERVER/cgi-bin/dynamic/printer/config/reports/deviceinfo.html" |egrep 'Service'|tr -s ' '|cut -f6 -d ' '`"
      elif [ "`echo $MOD | egrep -qi '1720dn';echo $?`" -eq 0 ]; then
        ST="`links -dump "http://$PRINT_SERVER/cgi-bin/dynamic/information.html?path=/printer/info" |egrep 'Service'|tr -s ' '|cut -f6 -d ' '`"
      elif [ "`echo $MOD | egrep -qi '5210n|5310n';echo $?`" -eq 0 ]; then
        ST="`links  -dump "http://$PRINT_SERVER/cgi-bin/dynamic/config/reports/deviceinfo.html" |grep Service|tr -s ' '|cut -f6 -d ' '`"
      elif [ "`echo $MOD | egrep -qi 'M5200';echo $?`" -eq 0 ]; then
        ST="`links -dump http://$PRINT_SERVER/printer/info |egrep 'Service'|tr -s ' '|tr -d '|'|cut -f6 -d ' '`"
      elif [ "`echo $MOD | egrep -qi '3110cn';echo $?`" -eq 0 ]; then
        ST="`links -dump http://$PRINT_SERVER/ews/status/infomation.htm |egrep 'Service'|tr -s ' '|tr -d '|'|cut -f7 -d ' '`"
      fi
      #need a proxy? Squid is a great one!
      #export http_proxy=http://USERNAME:PASSWORD@PROXY_SERVER:PORT
      LINK="http://support.dell.com/support/topics/global.aspx/support/my_systems_info/details?c=us&l=en&s=pub&servicetag=$ST"
      SER="`w3m -no-cookie -dump "$LINK" |grep -A 6 Days|cut -c50-|grep "/"|awk '{ print $3 }'|sort |tail -1`"
    fi
    echo -e "<tr><td><a href="http://${PRINT_SERVER}">${PRINT_SERVER}</a></td> <td>${MOD}</td> <td>${SER}</td> <td><a href="$LINK">${ST}</a></td> <td>${PRTS}</td></tr>" >> $WEBPINFO
  else
   echo -e "<tr><td>${PRINT_SERVER}</td> <td>No Response</td> <td></td> <td></td> <td>${PRTS}</td></tr>" >> $WEBPINFO
 fi
done

cat >> "$WEBPINFO" << EOF
</tbody>
</table>

<p>
Total print servers = `lpstat -t | egrep 'lpd://|socket://' |egrep -v 'SOME_PRINTER|SOME_OTHER_PRINTER'| cut -d"/" -f3 | cut -d":" -f1 | sort -u|wc -l`
Created by $0 at `date` on `hostname`
<script>
        var config = {
                tableId:'table_1', // the only mandatory parameter
                rowOver:'row_over',
                sortMap:'1,2,3:desc'
        }
        var t2 = new Chth.sortTable();
        t2.init(config);
</script>
</body>
</html>
EOF

#keep a historical copy
cp -f $WEBPINFO $PINFO

Friday, May 6, 2011

Fedora 13 VMware Workstation 6.5.4 and 6.5.5 installation issue solved.

We do have the VMware Workstation 7.1 licensed, but I find that it *really* likes to crash on Fedora 13 a lot! So, tried to roll back to the 6.5.4 version I had downloaded from about a year ago and failed on module build. Here is the generally un-helpful error:
/tmp/vmware-root/modules/vmnet-only/vnetUserListener.c: In function ‘VNetUserListenerEventHandler’: /tmp/vmware-root/modules/vmnet-only/vnetUserListener.c:240: error: ‘TASK_INTERRUPTIBLE’ undeclared (first use in this function) /tmp/vmware-root/modules/vmnet-only/vnetUserListener.c:240: error: (Each undeclared identifier is reported only once /tmp/vmware-root/modules/vmnet-only/vnetUserListener.c:240: error: for each function it appears in.) /tmp/vmware-root/modules/vmnet-only/vnetUserListener.c: In function ‘VNetUserListenerRead’: /tmp/vmware-root/modules/vmnet-only/vnetUserListener.c:282: error: ‘TASK_INTERRUPTIBLE’ undeclared (first use in this function) /tmp/vmware-root/modules/vmnet-only/vnetUserListener.c:282: error: implicit declaration of function ‘signal_pending’ /tmp/vmware-root/modules/vmnet-only/vnetUserListener.c:282: error: implicit declaration of function ‘schedule’ make[2]: *** [/tmp/vmware-root/modules/vmnet-only/vnetUserListener.o] Error 1 make[1]: *** [_module_/tmp/vmware-root/modules/vmnet-only] Error 2 make[1]: Leaving directory `/usr/src/kernels/2.6.34.8-68.fc13.i686' make: *** [vmnet.ko] Error 2 make: Leaving directory `/tmp/vmware-root/modules/vmnet-only' Unable to install vmnet

First, make sure to have some basic pre-requisites before you start:
yum install gcc gcc-c++ kernel-headers kernel-devel

Modify accordingly if you are running the PAE kernel:
yum install gcc gcc-c++ kernel-headers kernel-PAE-devel

Next install (or update):
rpm -Uhv VMware-Workstation-6.5.5-328052.i386.rpm
You may need to terminate part of the build process.

The hard part was finding the magical google incantation to finally getting me to THIS VERY helpful link and the real solution of:
cd /tmp tar xf /usr/lib/vmware/modules/source/vmnet.tar -C /tmp tar xf /usr/lib/vmware/modules/source/vmci.tar -C /tmp perl -pi -e 's,("vnetInt.h"),\1\n#include "compat_sched.h",' vmnet-only/vnetUserListener.c perl -pi -e 's,("compat_page.h"),\1\n#include "compat_sched.h",' vmci-only/include/pgtbl.h tar cf /usr/lib/vmware/modules/source/vmnet.tar vmnet-only tar cf /usr/lib/vmware/modules/source/vmci.tar vmci-only

Finally run:
vmware-modconfig --console --install-all

Wednesday, May 4, 2011

Mini book review: "The Book of XEN - A Practical Guide For The System Administrator"

Mini book review: "The Book of XEN - A Practical Guide For The System Administrator" by Chris Takemura and Luke S. Crawford, published by No Starch Press, copyright 2010, ISBN-10 1059327-186-7, ISBN-13 978-1-59327-186-2

I would first like to begin with some credit as to why I started down the path of Xen. My co-worker Chakri Girda was excellent enough to be my introduction into the real world of using Xen for virtualization. We had been a long time user of various VMWare products to get the virtualization job done. He was the lead on our revamped virtualization project and choose Xen. Good move all around I'd say!

The quest for enlightenment can take many paths. My quest generally does depart from the "path-of-google" when it comes to technology learning. That is I google the item of interest and read some links/pages/source/whatever and make it work. For some reason I just wanted a book. I had an urge to understand Xen virtualization in a greater way. Don't misunderstand, I currently manage 7 Dell PowerEdge Xen servers with 30+ domU's. Not huge by any standard, but enough to make me want to learn some of the "best practices" and not just "it's running and has fail-over". So, A quick google lead me to this book.

Chris and Luke are very clear in the beginning on the CentOS/Redhat Enterprise Linux (slight) slant of the book. But face it, Xen works on everything. And the xm command args don't not change from distro to distro. The sidebars throughout the book provide welcome distractions and helpful titbits as a general rule.

The authors set the practical and pragmatic tone from the start. The introduction clearly sets the stage for the rest of the book by creating a brief and down to earth (mercifully) short background and summary of Xen. No extra fluff. As a bonus, there is an actual "But I Am Impatient!" section that provides a reader with what chapter to turn for "step-by-step instructions" or chapters depending on the type of deployment being considered.

Chapter 1 is the the real introduction to virtualization. A well thought out overview with just enough background. As as overview, you are told that some general concepts are a bit over-simplified to speed you along.

Chapter 2 has to be the most foundational portion of the book. This begins the "Getting Started" with Xen. Well written and laid out for reading. This in spite of being referred as a "step-by-step instructions". It turns out the entire book is written in a very readable manner that goes beyond the regurgitation of man pages or help files. Quite interesting how some of the paragraphs flow more like a novel and less like a how-to. I say this in a good way! As part of the title states, this is, "A Practical Guide". So, chapter 2 is the short version of follow-the-Xen-leader.

Chapter 3 is "Provisioning DomUs" it seems to go out of its way to be distro inclusive when setting up domU's. There is a tar install section, a Redhat/CentOS and even a Debian install section. The information provided even provides insight into the large scale deployment options. The quick and dirty version of SystemImager or Cobbler/koan. The array of choices for the newbie is quite large in this chapter.

Chapter 4 is "Storage With Xen" and begins the, "I know I have shown you the easy way, but that may not be the best way" approach to storage spelled out from chapter 2. What you get here is the blktap -vs- LVM information. The chapter is still presented in a very readable way. However, the spoiler of the chapter, in my opinion, is, "blktap is easy to set up and good for testing, while LVM is scalable and good for production". This chapter not only presents some basic commands, but also provides the foundation of *why*. The "why" something is done is often as important is what is done. So knowing both pieces allows a sysadmin to actually make the best decisions. In this chapter, the, "why" deals with storage allocation choices.

Chapter 5 is simply "Networking". Networking is really the whole focus of this chapter. The authors begin with the startup script hierarchy. Then explains when Xen preforms certain actions - on xend startup or domU startup. Followed by a well laid out how and why to name virtual interfaces. I had to dog ear one of the pages (page 65) as it perfectly explained an odd interface issue being reported by our MAC address monitoring. Nice, very nice.

Chapter 6 is "DomU Management: Tools and Frontends". Again, this chapter steps out to be more disto independent. They make sure to say that there are choices. The authors even provide installation instructions for the frontend tools. Really a continuation of the "step-by-step" approach taken throughout the book. Suffice it to say that there are frontend options and you will need to choose one.

Chapter 7 is "Hosting Untrusted Users under Xen: Lessons from the Trenches". This chapter could have been entitled, "Cover your A$$" or even "Share". The focus of this chapter is sharing (well, maybe imposing restrictions is another way to put it). The reader is gently stepped through a why and how to restrict CPU, IO and even networking. I love the whole system approach to handling DomU's taken in this chapter. The authors clearly provide the basics on how to generally handle each type of resource in a fundamental way. This means using system tools most likely in use already. I suspect this chapter is built from, "college of hard knocks" style learning. The authors are unusually nice when referring to the general user base that lead to this chapter. I would not have been so nice... I consider this chapter a must read no matter if your are a external (public) or internal (company) Xen administrator.

Chapter 8 is "Beyond Linux: Using Xen with other Unix-Like OS's". Honestly, I found this the least interesting. I was lead to this book with the general belief of being CentOS/Redhat centric since these are my OS platform of choice. Needless to say I do not need to know about Solaris or NetBSD.

Chapter 9 is "Xen Migration". This chapter does a good job of exploring the foundation of the migration options ("live" and "cold"). There are command examples for each option provided and well thought out reasoning. A nice addition was the inclusion of storage options in the migration mix. This included basic setup and configuration of ATA over ethernet (AoE) as well as iSCSI. Again, both informational context and actual implementation is provided.

Chapter 10 is "Profiling and Benchmarking under Xen". I was almost expecting a, "this is my kickass benchmark score for my servers" chapter. Luckily, I was wrong. Instead, the chapter lays a well balanced look at testing in general and how it can relate to Xen. Careful attention is noted at the beginning to state that no benchmark is a substitute for a production workload of a server. As common through the book, several options are provided and discussed. I do like inclusion of actual results and a real world application. The OProfile section is a nice addition and goes beyond the usual benchmarking spew. This is the section that provides the real world experience on how a problem was solved. My only issue with this chapter is the need to make all auxiliary program additions a download, configure, make and make install treadmill. Not a good idea for any production server to have 1.)build tools and 2.) "dead programs" that will never get updated and 3.) it's a bad idea.

Chapter 11 is "Citrix Xenserver" Xen For The Enterprise" - What?! A whole chapter devoted to non-Xen. Maybe a longer Introduction that included some of the Xenserver stuff. In spite of stray from Xen at it's core, the chapter does a good job to balance the open source -vs- commercial aspect of Xen core virtualization. I like the "gladiator combat" reference. It's good to have a sense of humor.

Chapter 12 is "HVM: Beyond Paravirtualization". This chapter represents a brief introduction into the HVM install process and setup. The only part that seems out of place is the 5 paragraph
Xen HVM vs. KVM in the middle of the chapter.

Chapter 13 is "Xen and Windows". This short chapter is another nice plunge into a specific implementation are for Xen. Well laid out chapter with good examples and very handy discussion of options. I managed to dog-ear a couple of the pages for later quick reference. The small section on HALs is a good addition in this chapter.

Chapter 14 is "Tips". I always like the real world problem -> resolution sections and this is the pinnacle for this book. This chapter has tidbits of knowledge for all to enjoy. I found the "PCI Forwarding" (passthrough) and a couple of other sections to be of great interest. Good chapter overall and one that *ALL* people should read IMHO.

Chapter 15 is "Troubleshooting". This chapter has the most dog-ears for me with 4. I will likely return to this chapter a couple of times in the near future. I have had (and ignore today) some of the issues noted in this chapter. Issue like the DomU interface number incrementing has just be an annoyance. While the VM restarting too fast has been a major battle on occasion. Another must read for the Xen (want-to-be) server administrator as far as I am concerned.

In summary, a well written book with lots of tidbits of wisdom and years of experience. This was actually an easy read. I would find no issue in recommending this book to a new -> intermediate Xen admin.

Friday, April 29, 2011

Dell E6410 Fedora 13 32-bit Linux install and mini review

This is a catch up article. More of a documentation piece of (past) success than a current Fedora 13 review.

This Fedora install is a stock 32-bit DVD install (PXE install failed issue with flashing video problem). The target system is a nice Dell E6410 with 4GB RAM, Broadcom BCM4313 802.11b/g, nVidia GT218 [NVS 3100M] rev 162 dedicated video card and Intel I7 CPU. Let me just add the note here and state, for the record, that the Intel I7 ROCKS! The E6410 is a physically solid chassis with precise feel. No cheap feeling plastic on this bad boy. The LCD hinge is firm and smooth with no lateral wiggle or bounce issues. The 14.1 inch screen is bright with no dead pixels. Screen glare is fairly minimal and the function brightness control is handy. I have been a big fan of the Dell Latitude laptops for a long time. The product line continues to excel in many ways. However, please don't mistake this unit for any ultra-portable! Especially with the longer runtime extended battery.

Install with Fedora DVD is best accomplished with the "Basic Video Driver" install selection. Otherwise the screen flashing techni-color screen makes it impossible to install. I choose to install with whole disk encryption as a general rule for any laptop. Let me just say that it is easier to type in a pass-phrase every once in a while than it is to explain why all of the confidential emails or data from a boss is floating around the internet. I will file whole drive encryption under the "CYA" category. Basically, install is click-button-simple. Besides my video issue and encryption desire, there was no real need to not click "next" button when presented. All of the Linux distributions have made HUGE progress in ease of installation over the years. And Fedora is no exception!

Reboot after install leads to a rather disappointing 800x600 resolution login screen. At least there is a login screen at all. First a quick key sequence to dump me to console in order to log in as root in order to do a full update and reboot just to see if that will help my screen resolution issue with the *default* install. I do need to note, I have a standard practice that on any NVIDIA installation, I get the kmod-nvidia drivers or the official NVIDIA driver installed as quickly as possible. I want to see about "stock" install at this point ... but no luck... Sadly, in order to get the 1280x800 capable on this 14.1 WXGA (not WXGA+!) LCD panel I install the kmod-nvidia-PAE drivers (I'm running PAE kernel). However, I still end up with the long dreaded invalid pointer problem and need to remove the "InputDevice" lines in the /etc/X11/xorg.conf file. A reboot an all is better now with video.

The Broadcom BCM4313 is not working out of the box. A quick bit of google'n and an install from the rpmfusion-nonfree-updates repository used for the kmod-nvidia above:
yum -y install broadcom-wl kmod-wl-`uname -r`
modprobe wl
makes the wifi issue go away without the need to reboot. Cutting the ethernet cord an goin' mobile now.

The bluetooth functions without issue. I could pair with my Droidx in seconds. Nice.

Helpful links:
E-Family Reimage “How-To” Guide
E6410 Manuals

Wednesday, April 27, 2011

Fedora 15 beta first impressions - aka mini review

First and foremost please remember THIS IS A BETA. There are going to be issues. However, I find myself more fixated with my issues with the GNOME 3.0 interface than anything else. I know Fedora HAD to move on and stay with the latest and greatest GNOME release. After all that is what is Fedora is known for (and the reason I prefer CentOS/RHEL for servers!). More on GNOME shortly.

My Fedora 15 beta test attempt is happening on real hardware. No virtual container. It's a Dell D630 laptop with 2GB RAM, a dual core Intel T7500 and dedicated nVidia G86M Quadro NVS 135M video card. WIFI is handled by the Broadcom BCM4312 802.11a/b/g chipset. Modest by today's standards.

Normally for laptops, I will do whole disk encryption using a kickstart file. This is just a plain, "select some defaults" and install test. Install worked without issue (as expected). In fact, installs have been very easy for a long to the point of being almost boring. Really just a few clicks and I was done.

Start-up for Fedora 15 beta is very fast. Though not timed, the perceived boot time difference from Fedora 13 to Fedora 15 seemed significant. More specially, Fedora 15 boot time is faster. If I get bored, I may consider actually install Fedora 13 or 14 again just to time the boot-to-login screen time. Many people dig that.

Initially, I was interested in how the nouveau video driver was going to handle my Quadro NVS 135M. Not a real common chipset. The former nv driver has woefully inadequate to say the least. The install and/or nouveau found the LCD SVGA+ 1440x900 without any problems. For any other NVIDIA installation, I would get the kmod-nvidia drivers or the official NVIDIA driver installed as quickly as possible. I'm going to stick it out with nouveau for now. No urgent video need to bail just yet. Not a big compiz fan, however, so that's off.

The install found my wireless card (Broadcom model BCM4312 a/b/g) without any issue. I was able to see AP's in the area. It's nice to see this, "just work". However, wifi passphrase didn't seem to work for some reason. I had to put in the hex key instead in order to connect to the test wifi router. In addition, getting connected to an access point seems to take several seconds longer that with Fedora 13 and GNOME 2.30.

Now for the BIG CHANGE... GNOME 3.0! Not sure if it's Fedora's ruff edges on this beta or my shear newness with GNOME 3.0, but wow it's hard to get used too. Don't get me wrong, a window manager that stays out of your way is good! But one that you can't figure out how to change (yet)?! I was kinda overwhelmed with the Activities and trying to guess under what category a program would be under. Select all and just keep looking. All I wanted to do was fix my touchpad issues. Need to middle click paste with the double mouse button touch pad on the Dell? Can only use the bottom set of buttons... Not sure why yet. I've gotta tell you I use middle mouse/double mouse button paste A LOT as my typing speed and skill is not the best. Also, spent 10 minutes trying to figure out if I could get System Monitor back on my screen or CPU scaling info... and never did...

My solution, at the moment, to GNOME 3.0 is to run LXDE instead! Thank goodness for choice at this time. My frustration rate is high GNOME and back to basics is good. I will likely make more attempts to use the new GNOME, just not tonight.

Tuesday, April 19, 2011

CentOS 5.x bugzilla 3.2 blank page...

This may be more of a rant... I mean the whole purpose of having a "checksetup.pl" in bugzilla is to, well, check the bugzilla setup... It looks like they should add at least one more check (or I should take better care to read the instructions)...

So, a basic/minimal install of CentOS 5.6 and bugzilla I'm greeted with a non-helpful "failed to connect" page and a /var/log/httpd/error_log message of:
[Tue Apr 19 13:10:15 2011] [error] [client xx.xx.xx.xx] [Tue Apr 19 13:10:15 2011] index.cgi: Use of uninitialized value in substitution (s///) at (eval 42) line 44.
[Tue Apr 19 13:10:15 2011] [error] [client xx.xx.xx.xx] [Tue Apr 19 13:10:15 2011] index.cgi: Use of uninitialized value in concatenation (.) or string at Bugzilla/CGI.pm line 312.

Following google search links proves useless (which is not often the case).

I added all of the interesting perl modules that bugzilla may want. Modules like perl-DateTime, perl-List-MoreUtils, perl-PatchReader, perl-HTML-Scrubber, perl-Template-GD, perl-GD-Graph, perl-Chart and ImageMagick-perl (plus their dependencies). /usr/share/bugzilla/checksetup.pl ran without issue, produced no error, fixed and rebuilt etc... still the error... paying a tiny bit more attention to the area around line 312 in Bugzilla/CGI.pm, I finally notice https redirection code... Wait, bugzilla defaults to requiring https but does not check for https... finally problem solved. The solution is just to install "mod_ssl".

Saturday, April 16, 2011

CentOS 5.6 GitCO xen 3.4.3 kernel, libvirt-client and xen-libs update issues

A recent CentOS 5.5 to 5.6 update has caused one of my xen servers to stop functioning... This has happened few times in the past... and I keep forgetting to look before I reboot. Maybe documenting it here will help me remember and help others QUICKLY get past the xend failing to start with the error of:
[2011-04-16 15:34:19 5082] INFO (SrvDaemon:336) Xend changeset: unavailable.
[2011-04-16 15:34:19 5082] ERROR (SrvDaemon:349) Exception starting xend ((13, 'Permission denied'))
Traceback (most recent call last):
File "/usr/lib64/python2.4/site-packages/xen/xend/server/SrvDaemon.py", line 341, in run
servers = SrvServer.create()
File "/usr/lib64/python2.4/site-packages/xen/xend/server/SrvServer.py", line 251, in create
root.putChild('xend', SrvRoot())
File "/usr/lib64/python2.4/site-packages/xen/xend/server/SrvRoot.py", line 40, in __init__
self.get(name)
File "/usr/lib64/python2.4/site-packages/xen/web/SrvDir.py", line 84, in get
val = val.getobj()
File "/usr/lib64/python2.4/site-packages/xen/web/SrvDir.py", line 52, in getobj
self.obj = klassobj()
File "/usr/lib64/python2.4/site-packages/xen/xend/server/SrvNode.py", line 30, in __init__

Here is the deal. We have been using the Xen 3.4.3 repo from Gitco. For some reason yum will not keep the "kernel" line that matches up with the xen install from xen-3.4.3. So, the VERY simple fix (till the next kernel update) is just to make sure that your grub.conf has a line of "kernel /xen.gz-3.4.3" and not whatever gets dumped there by yum. Hope this helps people with this error.

The second issue with the (finally) released CentOS 5.6 update related to using the xen 3.4.3 from GitCO is the inclusion of the libvirt-client-0.7.0-6.el5. This is now an older version with the 5.6 update now out. The error you see from try a yum update is:
Transaction Check Error:
file /usr/bin/virsh from install of libvirt-0.8.2-15.el5.3.x86_64 conflicts with file from package libvirt-client-0.7.0-6.el5.x86_64
file /usr/bin/virt-xml-validate from install of libvirt-0.8.2-15.el5.3.x86_64 conflicts with file from package libvirt-client-0.7.0-6.el5.x86_64
file /usr/lib64/libvirt.so.0 from install of libvirt-0.8.2-15.el5.3.x86_64 conflicts with file from package libvirt-client-0.7.0-6.el5.x86_64
file /usr/share/libvirt/schemas/capability.rng from install of libvirt-0.8.2-15.el5.3.x86_64 conflicts with file from package libvirt-client-0.7.0-6.el5.x86_64

The fix is:
rpm -e --nodeps libvirt-client yum update

If you accidentally got the old i386 xen-libs, just run:
rpm -e xen-libs.i386 yum update

Thursday, March 24, 2011

CentOS 5.x and Firefox 4.0 howto!

Don't be confused. I did not come up with this! I just want to spread the word as much as possible that one very enlightened fellow referenced as "rkl" at forums.mozillazine.org has made it possible for the rest of us to hit the "easy button" and get FireFox 4.0 working on CentOS 5.x (CentOS 5.5 at this time). HERE is the original link that I lucked upon while trying to google it on my own.

This is the a quote of the general (FF4beta version) steps if you are too lazy to click another link:
1. Unpack the Firefox 4.0b9.tar.bz2 somewhere (e.g. /usr/local/firefox). With the "en_GB" release, I throw in a "dictionaries" sub-dir under there with en-GB.aff and en-GB.dic in there (and en-US.aff/.dic soft-linked to the en-GB ones) otherwise, sadly, Firefox 4 uses US spellings on what's supposed to be an en_GB release :-(

2. Download this 32-bit Fedora 9 libstdc++ RPM and unpack it with this command:

rpm2cpio libstdc++-4.3.0-8.i386.rpm | cpio -i --make-directories

3. Move the unpacked shared library into /usr/local/firefox thus:

mv usr/lib/libstdc++.so.6.0.10 /usr/local/firefox/libstdc++.so.6

Note: It's "usr/lib/libstdc++.so.6.0.10" above (i.e. the unpacked tree from the RPM, not the system /usr/lib tree) - do NOT put a leading slash there!

4. Run Firefox 4.0b9 with:

/usr/local/firefox/firefox

rkl references the beta version, but all steps still apply for official release.

I will say that FF4 is very nice! I am very impressed with what I have seen so far!

Tuesday, March 15, 2011

Basic OMSA install and usage with RHEL or CentOS 5.x

I am a big fan of Dell Poweredge hardware. It's well designed. It runs CentOS rock solid. It just works well. Dell must have figured out that many people like me feel this way (companies really). To their credit, Dell has a very full featured Linux support offering in the OpenManage Server Administrator (OMSA) for free.

To be fair, OMSA has historically had some speed bumps. Full 64-bit install has only recently been possible. And some past upgrades have not been smooth and actually required removing packages and manually removing directories and files in order to upgrade.

Note: make sure "plugins=1" is in the /etc/yum.conf

As root from a terminal prompt:
wget -q -O - http://linux.dell.com/repo/hardware/latest/bootstrap.cgi | bash wget -q -O - http://linux.dell.com/repo/community/bootstrap.cgi | bash wget -q -O - http://linux.dell.com/repo/firmware/bootstrap.cgi | bash yum install srvadmin-all OpenIPMI OpenIPMI-tools dell_ft_install

Install BIOS and firmware files
yum -y install $(bootstrap_firmware) update_firmware --yes
Reboot if needed/requested. If you don't reboot, make sure that you exit and log back in to have the srvadmin bin and sbin directories set for you.

Just to make sure some startup services will be started on reboot.
chkconfig dsm_sa_ipmi on chkconfig ipmi on srvadmin-services.sh stop && service ipmi start && srvadmin-services.sh start

The web GUI is good. Just point your browser to http://yourhostname_or_IP:1311 and login as root and check it out from there.

The command line tools, however, can offer some very good information when you don't have that option or need some scripting magic. For example, "omreport" can provide MUCH information about your server and it's state. Here is a quickie on controller:
omreport storage controller
Will spew lots of data like:
Controller PERC 5/i Integrated (Embedded)

Controllers
ID : 0
Status : Ok
Name : PERC 5/i Integrated
Slot ID : Embedded
State : Ready
Firmware Version : 5.2.2-0072
Minimum Required Firmware Version : Not Applicable
Driver Version : 00.00.04.17-4.31.z-RH1

Minimum Required Driver Version : Not Applicable
Storport Driver Version : Not Applicable
Minimum Required Storport Driver Version : Not Applicable
Number of Connectors : 2
Rebuild Rate : 30%
BGI Rate : 30%
Check Consistency Rate : 30%
Reconstruct Rate : 30%
Alarm State : Not Applicable
Cluster Mode : Not Applicable
SCSI Initiator ID : Not Applicable
Cache Memory Size : 256 MB
Patrol Read Mode : Auto
Patrol Read State : Stopped
Patrol Read Rate : 30%
Patrol Read Iterations : 41
Abort Check Consistency on Error : Not Applicable
Allow Revertible Hot Spare and Replace Member : Not Applicable
Load Balance : Not Applicable
Auto Replace Member on Predictive Failure : Not Applicable
Redundant Path view : Not Applicable
CacheCade Capable : Not Applicable
Persistent Hot Spare : Not Applicable
Encryption Capable : Not Applicable
Encryption Key Present : Not Applicable
Encryption Mode : Not Applicable
Spin Down Unconfigured Drives : Not Applicable
Spin Down Hot Spares : Not Applicable

To see information on the status of the virtual disk created on your PERC RAID controllers:
omreport storage vdisk
List of Virtual Disks in the System

Controller PERC 5/i Integrated (Embedded)
ID : 0
Status : Ok
Name : vd0
State : Ready
Encrypted : Not Applicable
Layout : RAID-1
Size : 67.75 GB (72746008576 bytes)
Device Name : /dev/sda
Bus Protocol : SAS
Media : HDD
Read Policy : Adaptive Read Ahead
Write Policy : Write Back
Cache Policy : Not Applicable
Stripe Element Size : 64 KB
Disk Cache Policy : Enabled

ID : 1
Status : Ok
Name : vd1
State : Ready
Encrypted : Not Applicable
Layout : RAID-10
Size : 1,396.25 GB (1499212021760 bytes)
Device Name : /dev/sdb
Bus Protocol : SATA
Media : HDD
Read Policy : Adaptive Read Ahead
Write Policy : Write Back
Cache Policy : Not Applicable
Stripe Element Size : 128 KB
Disk Cache Policy : Enabled

The parameter changing mate to omreport is "omconfig". You get to set or change options and can even trigger events like MAKING SURE YOU HAVE VIRTUAL DRIVE PARITY (AKA parity scrub)!

So to verify/validate/fix drive parity issues, add a cron job (and/or run the command now) to make sure that the RAID groups on your PERC RAID controllers are in perfect shape. You don't want any failed disk rebuild surprises!
crontab -e
00 17 * * 0 /opt/dell/srvadmin/bin/omconfig storage vdisk action=checkconsistency controller=0 vdisk=0 > /tmp/omconfig-vdisk0.out 2>&1 || cat /tmp/omconfig-vdisk0.out |mail -s "omconfig issue on `hostname`" admin
30 17 * * 0 /opt/dell/srvadmin/bin/omconfig storage vdisk action=checkconsistency controller=0 vdisk=1 > /tmp/omconfig-vdisk1.out 2>&1 || cat /tmp/omconfig-vdisk1.out |mail -s "omconfig issue on `hostname`" admin

Or better yet, get crazy with a shell script to dynamically ask for *each* controller and virtual disk to be checked. I will leave that up to you to figure out.

Again, just a basic install and use for OMSA. Take the time and go through the links, get the OMSA manual and enjoy.

Friday, March 4, 2011

Digi Portserver II 16 serial port server setup for RHEL or CentOS 5.x

I had an opportunity to test some additional equipment recently. This is the general setup and install and basic configuration for the Digi Portserver II 16 serial port server for CentOS 5.5. All of this is just a step in adding additional capabilities to our Hylafax servers. Additionally, other serial devices are also connected to give us network access to them. This includes serial port consoles and serial admin ports for some power strips to remotely power cycle some equipment if needed. The Digi Portserver II is not new and has been around for a while. This makes it cheap to pickup on eBay and use.

As a note, all commands that install something will need to be done as effective user "root". You can "sudo" your way there or just "su -"; your choice. Please take some time to
sanely setup a build environment on another box (if possible/practical).

This article is a follow up to a previous post on How to get a Digi Edgeport/416 working with RHEL/CentOS 5

Here is the Digi Portserver II overview from Digi. Nice starting point for information.

Here is the Driver download page if the overview is too much reading.

For even less effort you can get the latest stable kernel driver this way:
wget ftp://ftp1.digi.com/support/driver/40002086_P.src.rpm

or grab the beta code like I did:
wget ftp://ftp1.digi.com/support/beta/linux/dgrp/dgrp-1.9-29.src.rpm

To build the kernel module, you will need a few prerequisite packages. These are the ones that got me what I needed. You may need more or less depending on what you already had installed:
yum -y install ncurses-devel openssl-devel rpm-build kernel-headers

rpmbuild --rebuild dgrp-1.9-29.src.rpm

Install the built dgrp-1.9-29.i386.rpm with rpm or yum. You could choose to reboot or more simply just run
modprobe dgrp

If you just want the command line setup for the tty ports under /dev/, you can run something like:
/usr/bin/dgrp/config/dgrp_cfg_node init -v -v -e never 1 IP_OR_HOSTNAME 16

If you prefer a GUI setup and have tk and xorg-x11-xauth at least installed:
/usr/bin/dgrp/config/dgrp_gui

Finding firmware version of your Digi Portserver II to tell if you need a firmware update:
telnet IP/hostname #> cpconf term

May show something like:
# PortServerII Version 3.1.13 Nov 1 2006

Post dgrp driver setup with udev if you need:
For wide open perms edit /etc/udev/rules.d/10-dgrp.rules and change the line from
KERNEL=="tty_dgrp*", PROGRAM="/usr/bin/dgrp_udev %k", NAME="%c"

to
KERNEL=="tty_dgrp*", PROGRAM="/usr/bin/dgrp_udev %k", NAME="%c", MODE="0666", OPTIONS="last_rule"

For just group perms change to group "uucp" for example, alter original line from
KERNEL=="tty_dgrp*", PROGRAM="/usr/bin/dgrp_udev %k", NAME="%c"

to
KERNEL=="tty_dgrp*", PROGRAM="/usr/bin/dgrp_udev %k", NAME="%c", MODE="0660", GROUP="uucp"

A quick way to see all of the dev files created by the dgrp driver is the default major number 253 is kept:
ls -la /dev/|grep " 253"

Make sure the dgrp kernel module is loaded:
lsmod|grep dgrp

On a sad note, following these instructions will only create a kernel module for the current kernel. You will need to do rebuild on the dgrp package on any kernel update... sorry I have not yet incorporated kmod or DKMS for a dynamic module build. There is hope for me if would just try THIS link, however.

Wednesday, February 16, 2011

UPDATE: Linux RHEL/CentOS 5 RoundCube webmail setup for latest stable tar install

Roundcube webmail has updated to roundcubemail version 0.5 recently. The previous article is still mostly true with a couple of changes.

The first obvious one is the download link is now HERE
The other is a name change for php53 to php53u to get past an naming issue with RHEL/CENTOS 5.6.

Tuesday, February 1, 2011

Failed BIOS update on Dell R710 with CentOS 5.5 solved! (Worked around, realy)

Problem: Dell R710 (and likely R610 and others) under CentOS 5.5 with OMSA 6.4 (newest at this time) fails to update BIOS and will not attempt to update any other component:
# update_firmware --yes
...

Found firmware which needs to be updated.

Running updates...
hey, we are supposed to be installing now... :)
loading xml from: /usr/libexec/dell_dup/BIOS_NONE/PIEConfig.xml
loaded.
/ Installing dell_dup_componentid_00159 - 2.2.10 Plugin command is biosie.bin -u update.xml
Output file is update.xml
Plugin timeout is 600
- Installing dell_dup_componentid_00159 - 2.2.10output from the cmd was:

\ Installing dell_dup_componentid_00159 - 2.2.10Could not parse output, bad xml for package: dell_dup_componentid_00159
None
Installation failed for package: dell_dup_componentid_00159 - 2.2.10
aborting update...

The error message from the low-level command was:

Could not parse output, bad xml for package: dell_dup_componentid_00159
Complete!


Closest as I can tell, there is a Dell parser utility that is not understanding the CentOS derived content of the /etc/redhat-release and a possible "distroverpkg=redhat-release" in the /etc/yum.conf.

There are at least 4 ways to work around or fix this issue until Dell can fix the parser problem.

1. Change the contents of the /etc/redhat-release to the official RHEL information
cp -p /etc/redhat-release /etc/redhat-release.org echo "Red Hat Enterprise Linux Server release 5 (Tikanga)" > /etc/redhat-release
And the BIOS update will work. Just put back your redhat-release.org when your done.

2. Get the official stand alone Dell BIOS Linux update .BIN file for the R710 and update via the normal
bash ./PER710_BIOS_LX_2.2.11_1.BIN
You will need the "compat-libstdc++-33.i386" package installed if not already. Sadly, this option has not proved 100% yet.

3. If you have the *.BIN file and option #2 fails, you could
bash ./PER710_BIOS_LX_2.2.11_1.BIN --extract PER710_BIOS_LX_2.2.11_1 modprobe dell_rbu smbios-rbu-bios-update -u -f PER710_BIOS_LX_2.2.11_1/payload/*
Of course you will need to replace with *YOUR* downloaded .BIN file for *YOUR* class of system.

4. Bypass some Dell safeguards and update directly
updatedb locate dell_dup_componentid_00159|grep ".hdr"
If you get only one return value you can short cut by running
dellBiosUpdate -f `locate dell_dup_componentid_00159|grep ".hdr"` -u
Or just figure out which one you want a put it in
dellBiosUpdate -f /usr/share/firmware/dell/dup/system_ven_0x1028_dev_0x0235/dell_dup_componentid_00159_version_2.2.10/R710-020210C.hdr -u

5. Bypass the OS completely with iDRAC card and Lifecycle Controller. In this case the part that you will care about is that:
Unified Server Configurator (USC) aims at local 1-to-1 deployment via a graphical user interface (GUI) for operating system install, updates, configuration, and for performing diagnostics, on single, local servers. This eliminates the need for multiple option ROMs for hardware configuration
You are suppose to be able to update the BIOS from this thing in other words. The LC will download and install all on its' own. It will scan your hardware and update everything it can find that needs updating. You will need to shutdown and boot into the iDRAC and then do all of the updates. Good, but not ideal for normal production servers with the extra downtime. On the other hand, this should not be a huge issue if you applying updates on a scheduled basis. It would still suck (a lot) if you have a large number of servers.

6. Grab a OMSA LiveCD and boot from it. Initial blog entry is HERE The most recent version is running CentOS with some of the mods above including the /etc/redhat-release change (in part). I did have issues with attempting to use OLDER BIOS .BIN files when I had a badly behaving R710 BIOS. Again, the downside is a shutdown for this to happen and not just a simple reboot.

With *ANY* of these options make sure to *REBOOT* your server and not shutdown or your BIOS update will not take into affect.

Thursday, January 27, 2011

LPI exam prep help for free...

Like it or not, companies like certifications. Cert's help HR department figure out baseline skills. They make for an easy box to check on an hiring request. It is far more difficult to interview and discover abilities than it is to look for some acronym of ability.

Need another reason?? Learning is fun or at least should be. Especially if your a full time geek. I am amazed on how many new things I learn just looking at some of the prep information. Besides, some of our favourite commands evolve and morph all the time.

That being said, one very good organization is the Linux Professional Institute or just LPI. I'm not saying it's a Cisco cert or RHEL cert but it's a good all around way to get a little more on the old resume. Besides it's a bunch cheaper to get than a lot of the others.

What's even more interesting is that IBM has a very large amount of helpful training information geared directly toward passing LPI group of tests. And best of all, the price is right... free.

The main starting point for IBM is HERE
LPIC-1 certification prep.
LPIC-2 certification prep.
LPIC-3 certification prep.

Monday, January 24, 2011

Dell Poweredge, Latitude and Optiplex BIOS updates HOWTO for Fedora, CentOS and RHEL

BIOS updates for us Linux types have not been very easy. It was often difficult enough when there was boot floppies to deal with. Now it seems that many vendors even require actual Windows to be running in order to update. Luckily, Dell has not been one of those companies when it comes to their business lines of servers, laptops and desktops.

The whole process is very easy thanks to Dell's commitment to Linux:
  1.  wget -q -O - http://linux.dell.com/repo/community/bootstrap.cgi | bash
  2.  wget -q -O - http://linux.dell.com/repo/firmware/bootstrap.cgi | bash
  3.  yum -y install libsmbios-bin firmware-tools firmware-addon-dell
  4.  yum -y install $(bootstrap_firmware)
  5.  update_firmware --yes
Make sure "plugins=1" is in your /etc/yum.conf
Don't take my word for it look at Dell's firmware repository information.

I have had success using these steps for Poweredge 2850, 2950, R710, Optiplex GX280, GX520, GX620, Latitude D620 and D630 just to name a few. In addition, OS's have been CentOS 5.x, Fedora 11, 12 and 13.

Thursday, January 13, 2011

RHEL or CentOS 5.x RPM sanity and not source installs

I am a firm believer in package managers. What's there not to like? Dependency chains, package verification before installation, package validation after installation, versioning and reproducibility are among my favorite reasons for liking the Redhat and Fedora default "RPM Package Manager" rpm  and by extension, yum.

The focus for this short article will be on RHEL or CentOS 5.5 as the base OS. These are often considered a "server" based OS and tend to focus on stability, security and not on newest version. However, with many production systems, there tends to be needs or demands imposed on the systems administrator. It  will be our issue to safeguard the installed base OS and even extended repository installs against harm. Many new creative and useful perl modules are not even available as rpm's. Or the versions that are found are relegated to an older version than required (by the boss, the project etc).

Every effort should be made avoid source installs. As an added deterrent, " DO NOT attempt to install software packages which are part of CentOS as a source package, because you think you absolutely need the newest version. THIS WILL OFTEN BREAK THINGS"

Luckily, there are many tools to help ease this burden by attempting to create an rpm package for you. Some will work better in certain situations than others. Some are designed to handle a specific type of source (like a perl module):
  1. checkinstall is for general source installs that do not offer .spec files
  2. rpmbuild is easy if there is a usable .spec file in the source install or if there is a .src.rpm file for the needed install
  3. cpan2rpm will help with many pesky perl modules
  4. perl2rpm will help with many pesky perl modules
  5. cpanflute2 will help with many pesky perl modules
Here is an example from a recent requirement to have the newest tesseract-ocr 3.0 installed. Make sure you read over Setuping up an RPM Build Environment!

I found a needed tesseract-3.00-1.fc15.src.rpm from Fedora 15. The original source tar file did not have a spec file that was usable by RHEL/CentOS 5.5 version of rpmbuild. And it will not build without some help. Also the "--nomd5" is needed as rpm version issue from newer Fedora and RHEL and CentOS 5.x.

rpm -ihv --nomd5 tesseract-3.00-1.fc15.src.rpm
rpmbuild -bb /path/to/tesseract.spec
yum update /path/to/tesseract-3.00-1.i386.rpm

Darn. Can't install without a much newer version of the "optional" leptonlib of greater than 1.60. There is not an updated src.rpm version to be found anywhere. Going to need to use the source...

wget http://www.leptonica.org/source/leptonlib-1.67.tar.gz
tar -xzvf leptonlib-1.67.tar.gz
cd leptonlib-1.67
./configure
checkinstall -R --review-spec --install=no

Check through the generated spec ("--review-spec" - sometimes need to use "--fstrans=no" if checkinstall gets too many other files included)
Then finally:

yum update /path/to/leptonlib-1.67-1.i386.rpm /path/to/tesseract-3.00-1.i386.rpm

Checkinstall is one of my general go-to options for source installs when I come up empty looking for prebuilt rpm packages from known repositories.

But the fun was not over... boss wanted the newest perl Image-OCR-Tesseract module...

wget http://search.cpan.org/CPAN/authors/id/L/LE/LEOCHARRE/Image-OCR-Tesseract-1.24.tar.gz
#no spec file to be found in the tar file
perl2rpm Image-OCR-Tesseract-1.24.tar.gz
yum install /path/to/perl-Image-OCR-Tesseract-1.24-1.noarch.rpm

Honestly, any one of perl2rpm or cpanflute or cpan2rpm would have worked.

Now boss is happy and sysadmin is happy and the CentOS forum won't hassle you as much about source installs ;)

Sunday, January 9, 2011

Archiving with tar & compresing with pbzip2 -- a great combination

Creating a tar archive is not anything new or fancy. Heck, it's not even glamorous or exiting. But, if you need a ubiquitous all around good tool to create an archive of files, tar should be toward the top of your list.

First, let me say that this quick intro will generalize on tar and a couple compression options. No lvm or disk snapshots, rysnc, librsync or any other sometimes similar choices will be compared here. However, there are many situations when you will want to incorporate those other choices into a bigger strategy. This information will shed some light on a couple of opportunities that are present either directly or indirectly that may need to be thought about depending on your situation when using tar.

Generally, when you just need a quick archive the standard tar command will just be:
tar cf /path/to/archive.tar /path/to/source

That's good. It will work, but many will compress the archive with either gzip (z) or bzip2 (j) options:
tar czf /path/to/archive.tar /path/to/source
tar cjf /path/to/archive.tar /path/to/source

The space required to create the archive is normally reduced if file is not already compressed or of a compressed type like avi's or mp3 etc. That's often better but there are issues when dealing with larger sized files or directories:
  1. tar compression extends the time required to hold open file(s)
  2. tar compression extends the time required to complete the archive
  3. tar compression tends to create files slightly larger than post compressed files
  4. tar compression is limited to single processor utilization
All of these issue are overcome by post compression using "pbzip2". pbzip2 is "a parallel implementation of the bzip2... and achieves near-linear speedup on SMP
machines". With pbzip2 (optionally) all of the systems' processors can be put to use at the same time. The archive requiring 2 hours to bzip2 can take as little as 30 minutes on a idle single quad core system.

Naturally, the trade off will be an increase in the free disk space required to complete the process. A trade off will be the need for increased free disk space. As a general minimum you will need at least 1.5 times the size of the files to be archived in order to complete the process.

This is a small scale example with a modest 1.5GB directory. The directory has data base SQL unload files. The system has 2 older quad core CPU's and a fairly fast disk subsystem along with 16GB RAM.

testdir = 1603076072 bytes or 1.5GB

time tar cf test.tar testdir
real    0m12.039s
size 1603164160 bytes or about 1.5GB

time tar cjf test.tar.bz2 testdir
real    9m37.415s
size 216820944 bytes = 207M

time tar czf test.tar.gz testdir
real    2m44.550s
size 282025065 bytes = 269M

time pbzip2 test.tar
real    2m17.014s
size 217235869 = 208M

time bzip2 test.tar
real    9m13.197s
size  216820491 = 207M

Combining a normal tar file with pbzip2 provides about 22% greater compression than gzip in less time for this test. For some situations, tar + pbzip2 is a great combination. I just wanted to share ;)

Wednesday, January 5, 2011

Linux CentOS 5.5 + Xen 3.4.x and virt-manager 0.8.5

Xen Hypervisor is a very powerful tool for any sysadmin. Loads of virtualization capability and free (GPL "free"). What's there not to like... Well, I don't like the CentOS/RHEL xen-3.0.3 version from 2007 for starters and the equally ancient virt-manager. Solution...  with minimal effort follows:

This pair of updates will be done using 2 distinct parts. One easy one a little harder. Please make sure you start with a CPU with vmx or vt (virtualization or vanderpool technology) enabled and running CentOS 5.5 64bit!

Easy part Xen 3.4.x:
  1. cd /etc/yum.repos.d/
  2. wget http://www.gitco.de/repo/GITCO-XEN3.4.3_x86_64.repo
  3. yum install xen kernel-xen (or "yum update" if you an older xen installed)
You could run/try the xen 4.0.x version if you want. You take a look at the information from http://www.gitco.de/repo/.

Note: 03/25/2011 newer versions of 0.8.6 and 0.8.7 have some hefty dependencies on new and/or updated packages. I have yet to successfully build either on CentOS 5.5.
Harder part virt-manager:
  1. sanely setup a build environment on another box (if possible/practical)
  2. install a usable virt-manager-0.8.5-1.fc14.src.rpm :
    rpm --nomd5 -ihv virt-manager-0.8.5-1.fc14.src.rpm
    rpmbuild -bb virt-manager.spec
  3. note the location of the created virt-manager-0.8.5-1.noarch.rpm
  4. install a usable python-virtinst*src.rpm:
    rpm --nomd5 -ihv python-virtinst-0.500.4-1.fc14.src.rpm
    rpmbuild -bb python-virtinst.spec
  5. note the location of the created  python-virtinst-0.500.4-1.noarch.rpm
  6. install both of the packages created with yum:
    yum install /path/to/virt-manager-0.8.5-1.noarch.rpm /path/to/python-virtinst-0.500.4-1.noarch.rpm

Post install notes:
Some kernel updates create an issue for the /etc/grub.conf kernel line entry. Currently for the Xen 3.4.3 installed system, the line should read:
kernel /xen.gz-3.4.3 or
kernel /boot/xen.gz-3.4.3

For example, if you run "xm list" and get " Error: Unable to connect to xend: No such file or directory. Is xend running?" you may need to check your /etc/grub.conf!

You could also try to get the Xen Hypervisor 3.4.3 yourself and try to build a sane package from the Xen guys. Make sure to get the "Linux 2.6.18 with Xen 3.4.x support source tarball"

Virt Manager official web site is HERE

Sunday, January 2, 2011

Linux Centos 5.x on PowerEdge 2950 with PERC 5/e and Dell MD3000 followup

Here is an update to a previous post that now includes a graph along with some additional quick tests. Even though the MD3000 line is getting a bit old, I got a killer deal on a unit had some free time for testing.

Quick info: Dell PowerEdge 2950 with PERC 5/e SAS card dual connected to a Dell MD3000 disk array with qty 15 73GB 15K drives running CentOS 5.5 all with kernel  2.6.18-194.26.1.el5. The MD3000 has 1 global host spare setup and is performing the RAID 1, 5 or 6 portion of the test and linux md is the RAID 0 part. The MD3000 really only performs well when both controller are active in all of the tests that I have run. In addition, mirrorCacheEnabled=FALSE is set on the MD3000 controllers.

A picture does speak a thousand words. Higher is better.



Very nice for ext4! I did test with the "nobarrier" option just to make sure there was not the performance regression in this kernel. The issue does not appear in this kernel since the iozone numbers were right on.

As a note, this is mostly "stock" setup changing the RAID types. You *can* have even better performance numbers by playing with simply items like " blockdev --setra xxxx". For example, a change of "blockdev --setra 8192" produced about a 20% increase under ext4 for both read and re-read in iozone ("--setra 32768 got 30%)! Also, a scheduler change to "deadline" may help depending on your workload.