Thursday, August 25, 2011

How to set or reset a Dell Service Tag

Kinda bummed about having to do this on my own, but it just seemed easier. I have a Dell PowerEdge R710 that DID NOT handle either a iDrac or BIOS version update very well. The BIOS would not show a version number and the iDRAC6 would just hang. Couldn't reset the iDRAC and could barely get the box running again (had to pull power and do a dance and hope for it to boot). Most of the time the iDRAC boot option would get auto selected... long story. None of the 2 days of work requested by Dell tech's helped... they had to replace both the motherboard and iDRAC6 card. (on a side note, I may post on the large number of ways to flash firmware or BIOS's that Dell has provided to Linux users)

Sadly, the "asset" program the tech had with him seemed to only set the "Asset Tag" and not the Service Tag. The BIOS was the only thing that would show the Service Tag correctly. None of the normal ways to get the ST would produce results:
dmidecode -s system-serial-number racadm getsvctag getSystemId
I did find a DOS asset.exe executable, but who wants to boot a server system to DOS?! There was the lonesysadmin.net peeps with a plausible boot .iso... nah, there's gotta be a better way without having to resort to that... More google'n and bingo the hint I needed.

Turns out that the OMSA install I had could do what I wanted. I just didn't know it. At least for CentOS 6.0 and with smbios-utils-python-2.2.26-6.1.el6.x86_64 on a Dell R710 with BIOS 3.0.0, I can run:
smbios-sys-info --service-tag --set=123456
and this will set/reset my newly replaced motherboard to have the Service Tag I need! Please note that this Service Tag also persists over reboots unlike some older posts seem to have issues with.

As always, YMMV

Tuesday, August 16, 2011

CentOS 5.6 bugzilla email reply-to bugs howto

This is a quick and dirty set of steps to get an internal bugzilla to allow replies from bugzilla emails to be added to a bug. I'm sure there is a more "proper" way, but since the user that runs email is "nobody" for CentOS, I don't see how at this time.

First, I am using the EPEL repository in order to be a newer bugzilla than is provided with stock CentOS 5.6 at this time. In fact, I tend to even use the "testing" repo in order to get what I want. The current version as of this writing is bugzilla-3.2.10-1.el5 if you are interested. The information here is realy just a documentation place for what I have had to do for a while now.

/usr/share/bugzilla/checksetup.pl

Make sure you have all the perl modules to run email_in.pl at least from the command line. If you run this, it should *not* return any error. It should just sit there waiting for input; just +c to terminate.

/usr/share/bugzilla/email_in.pl

Make sure you have a bugzilla alias. Make sure to check a past email to see what the reply-to address is going to be. You can add the alias like the following on the server that has bugzilla running on it.
echo 'bugzilla-daemon:"| cd /usr/share/bugzilla/ ; /usr/share/bugzilla/email_in.pl -vvv > /tmp/email_in.pl.out 2>&1"' >> /etc/aliases newaliases

Here is the shotgun approach I took in order to get replies to function. Keep in mind that this system does *not* have user accounts on it and is internal to a network. I would *NOT* do this for on with user accounts or if it was exposed to the outside world. If you happen to know the proper way to handle this, drop me a note!

find /var/lib/bugzilla/data -type d -exec chmod 755 {} \; find /var/lib/bugzilla/data -type f -exec chmod 744 {} \; find /var/lib/bugzilla/data \( -name "*.pm" -o -name "*.pl" -o -name "*.cgi" \) -exec chmod 755 {} \; find /usr/share/bugzilla/ -type f -exec chmod 744 {} \; find /usr/share/bugzilla/ -type d -exec chmod 755 {} \; find /usr/share/bugzilla/ \( -name "*.pm" -o -name "*.pl" -o -name "*.cgi" \) -exec chmod 755 {} \; chmod 755 /etc/bugzilla/ chmod 744 /etc/bugzilla/localconfig

Please note that *any* time you run "checksetup.pl", you will need to redo the commands above! That perl script will make the bugzilla install more secure again. It is good practice to make sure that you can past most all of the module recommendations it has prior to doing anything else.

When you start wanting to send test messages to bugzilla, make sure to watch the maillog for errors. Those errors *may* also come back as emails if you are lucky.
tail -f /var/log/maillog|grep bug

Also, based on an email_in.pl bugzilla bug I slightly modified the /usr/share/bugzilla/email_in.pl by applying THIS very easy patch to fix this next error.

Use of uninitialized value in concatenation (.) or string at Bugzilla/DB.pm line 106, <STDIN> line 49.
Use of uninitialized value in require at (eval 99) line 2, <STDIN> line 49.
Use of uninitialized value in concatenation (.) or string at Bugzilla/DB.pm line 106, <STDIN> line 49.
Can't call method "isa" without a package or object reference at /usr/share/bugzilla/email_in.pl line 303, <STDIN> line 49.

If the permissions are messed up, you will get errors like:


Use of uninitialized value in concatenation (.) or string at Bugzilla/DB.pm line 106, <STDIN> line 57.
Use of uninitialized value in require at (eval 100) line 2, <STDIN> line 57.
Use of uninitialized value in concatenation (.) or string at Bugzilla/DB.pm line 106, <STDIN> line 57.
'' is not a valid choice for $db_driver in localconfig: Null filename used 

OR

Error reading /var/lib/bugzilla/data/params: Permission denied at Bugzilla/Config.pm line 319.
Compilation failed in require at /usr/share/bugzilla/email_in.pl line 43.
BEGIN failed--compilation aborted at /usr/share/bugzilla/email_in.pl line 43.

OR

Use of uninitialized value in string ne at Bugzilla/Util.pm line 290, <STDIN> line 49.
Use of uninitialized value in string eq at process_bug.cgi line 435, <STDIN> line 49.
of uninitialized value in string eq at Bugzilla/Mailer.pm line 57.
Use of uninitialized value in string eq at Bugzilla/Mailer.pm line 121.
Use of uninitialized value in pattern match (m//) at Bugzilla/Mailer.pm line 141.
Use of uninitialized value in string eq at Bugzilla/Mailer.pm line 152.
Use of uninitialized value in string eq at Bugzilla/Mailer.pm line 160.
error: template error: file error - failed to create compiled templates directory: /var/lib/bugzilla/data/template/template/en/default/global (mkdir /var/lib/bugzilla/data/template: Permission denied 

Sunday, August 14, 2011

Garden of the Gods horseback riding review - Academy Riding Stables

Family vacations can still be an opportunity to blog. This one is not geek related in any way, however. Other than this geek had a GREAT time horseback riding on trails of the Garden of the gods. The horses and guides were provided by:
Academy Riding Stables
phone (888)-700-0410 or phone (719)-633-5667
4 El Paso Blvd. Colorado Springs, CO 80904
I even got a discount of a couple of bucks per person from pikes-peak.com.

The Academy Riding Stables are very well organized group. Even when a larger group than originally expected group appeared. They split our 2 hour time slot into 2 groups instead of one larger one. Each group had both a lead rider and trailing rider. Safety seemed to be a high priority for the leaders. There was emphasis on how to approach, mount and ride the horses in a safe way. Helmets were provided for all that wanted them and use of helmets was encouraged. There were 10 riders from 8(ish) to much older. A person in charge selected horses of appropriate sizes based on each riders' size. My horse was very well suited to me and was well behaved.

Our ride began with a rather uneventful trek through a portion of residential area that borders Garden of the gods. This was a couple of blocks that included public roads and alleys. A trail was started about 10 minutes into the ride. First portion of the trail was easy and very wide. The horses knew were they were going and none ventured from the path. The first third a portion of the park that was generally easy with more gentile hills and valley like views.

The next 2/3 of the ride were primarily single horse width trails with changing terrain. Some climbs were very exhilarating both in final view of the area and ability of the horses to get up them. I was very thrilling to have my horse going down some rather steep steps with little effort. Even my youngest thought this was very exciting! Theses trails were not part of the general hiking area of the Garden of the gods if you were to go into the main rock formation area. We had views of part of that area, but our route focused on more of the perimeter. The views from the top of some of the hills are very breathtaking! The surrounding mountains and area are just beautiful. Words do not do justice to the majestic view that I had.

The ride lasted for 2 hours and included interesting commentary from the ride leaders. They made every effort to make sure all of the group was given information about the area we were in. Many times the end support rider would repeat the entire message to make sure the end riders understood. The information they provided was both interesting and worthwhile.

On a animal treatment note, I would like to commend the Academy Riding Stables for how well they seem to treat the animals in their care. Each horse that was brought for a rider was known by name and treated with kindness. Each of the riders was made aware that the horses should be allowed to drink their fill of water before the trip. Horse handling instructions were emphasized. All the horse stables seemed to be well kept and stocked with plenty of food. There was large areas for horsed to roam free. Heck even observed a couple of horses that were given showers while we were waiting for our turn to ride.

Make sure to get there early to fill out the paperwork. Reservations are required.

Google has lots of images
I will post some of my own pics very soon. I even used my DroidX with GPS tracking to map the route.
Note: I did not receive any compensation for this review.

Tuesday, August 2, 2011

CentOS 6.0 Zimbra 7.1.1 Open Source Edition install

Update 8/12/2011:
Good news! CentOS 6.x is out of beta and in stable with version 7.1.2 from HERE. In fact, you may just want to check their download page.

I wanted to take a peak at what is going on with Zimbra and CentOS 6 install capability. Currently, CentOS 6/RHEL 6 is listed as a beta for Zimbra 7.x installs. To to be deterred, I grabbed the beta download from the beta download page
wget http://files2.zimbra.com/downloads/7.1.1_GA/zcs-7.1.1_GA_3196.RHEL6_64.20110527010625.tgz
Test server is decent Dell Poweredge 2950 type II with 2 Intel quad core E5335 with 6GB RAM, RAID 1 for / (qty 2x80GB SATA) and RAID 5 for /opt (qty 4x500 SATA)
CentOS 6.0 x86_64 install was done as a "web server" install to provide most options I thought I would need as a start for the Zimbra install.

Note: I always suggest to install OMSA on any Dell server!

After the system is setup make sure that services that will interfere with Zimbra installed version are stopped and will not turn on at boot time:
chkconfig postfix off service postfix stop chkconfig httpd off service httpd stop tar -xzvf zcs-7.1.1_GA_3196.RHEL6_64.20110527010625.tgz cd zcs-7.1.1_GA_3196.RHEL6_64.20110527010625 ./install.sh
64 bit install but the installer still wants "libstdc++-4.4.4-13.el6.i686" installed.?
yum install libstdc++-4.4.4-13.el6.i686
Read Zimbra install info seems to be the moral of the story.

Finally installed with:
./install.sh --platform-override
followed prompts. Initial failure with log message with many:
sudo: sorry, you must have a tty to run sudo

Ran visudo to temporarily comment the "Defaults    requiretty" line and then ran:

/opt/zimbra/libexec/zmsetup.pl
To complete the install. Reboot just to make sure everything starts and begin the setup process. Now on to the much harder Zimbra setup!

Wow, still not done! Zimbra zmconfigd seems to need netcat, but is not a rpm requirement.??
yum -y install nc

Also, the install seems to need a patch before I can start working:
wget http://files2.zimbra.com/downloads/7.1.1_GA/zcs-patch-7.1.1_GA_3213.tgz