Phil Cam in Action


Just snapped this today off the infamous "philcam". This is pretty much what those who know about the site (which is alot of folks at our New York and Colorado headquarters) see when they dial it up on our internal network. As I said on my personal blog earlier today, not a very pretty sight. My neighbors in the local branch sometimes have fun with it too.

How I set this up is described in an earlier article on this blog. The stuff that's whited-out (including the URL for my internal site) are obscured for security reasons. Hey, what do you expect? I am in system security, after all.

Me, my minicam and Linux

Finally got the SIIG Firewire card today. Popped it in and restarted the new Fedora 6 box.

Ran dmesg and saw:

ieee1394: Initialized config rom entry `ip1394'
ohci1394: fw-host0: OHCI-1394 1.0 (PCI): IRQ=[19] MMIO=[ecefe800-ecefefff] Max Packet=[2048] IR/IT contexts=[4/8]
ieee1394: Host added: ID:BUS[0-00:1023] GUID[0001080038024d39]
ieee1394: Node added: ID:BUS[0-01:1023] GUID[08004601035d5e58]
ieee1394: raw1394: /dev/raw1394 device initialized
WARNING: The dv1394 driver is unsupported and will be removed from Linux soon. Use raw1394 instead.
ieee1394: Node suspended: ID:BUS[0-01:1023] GUID[08004601035d5e58]
ieee1394: Node changed: 0-01:1023 -> 0-00:1023
ieee1394: Node resumed: ID:BUS[0-00:1023] GUID[08004601035d5e58]
ieee1394: Node changed: 0-00:1023 -> 0-01:1023


Output of lsmod:

dv1394 22821 0
raw1394 30789 4
ohci1394 37489 1 dv1394
ieee1394 294809 3 dv1394,raw1394,ohci1394


OK. OK. So I jumped the gun. Plugged in the camera and turned it on.

First issue was, what do I use to grab the 3 hours of mini tape I've got?

Already knew that kino was a little flaky (well, alot flaky -- very prone to crashing), at least on Red Hat.

Finally decided to use dvgrab. Simple, straighforward. No GUI to mess with.

Start pulling video off the first tape, run:
dvgrab --autosplit tape1_

Boom. Starts echoing back to me:

"tape1_001.avi": 136.78 MB 1154 frames timecode 00:00:38.15 date 2006.09.18 13:08:54
"tape1_002.avi": 34.61 MB 292 frames timecode 00:00:48.07 date 2006.09.18 13:09:19
"tape1_003.avi": 99.21 MB 837 frames timecode 00:01:16.06 date 2006.09.18 13:10:04

Well, you get the idea. Still running as I write this. Plan to let it wind out overnight. Tommorrow I'll begin looking at how to run all this video through an editor and put together some nice, topical, movies. After that it's on to figuring out how to build my own DVD with menus fit for sending to grandpa.

For now, time for lights out.

The Virtual AGC


The Virtual AGC simulates the operations of the Apollo Guidance Computer in software. Being home sick the last few days, I've been challenged to do more with my (few) waking hours (real bad virus, maybe flu -- definitely takes you down a few notches) than just watching TV.

So I came across Ron Burkey's site and downloaded his (still) incomplete AGC emulator, which includes a graphical representation of the original Apollo DSKY data entry pad.

I've been running through a few of the simulation tests since. Haven't got to anything really meaningful, but for a Cold War era kid like me this is a real thrill.

Starplot


Back when I was in law school I discovered the "Whole Earth Catalog" (2nd edition, entitled "The Next Whole Earth Catalog"). Well, actually I was introduced to it by an upperclassman. To this day I've carried with me two things from that book. The first is the memory of an article entitled "The Stillman Zero Maintenance Theory", that appeared alongside an entry for Joe Troise's book Drive it till it drops: how to keep your car running forever!. Basically, Stillman's "theory" was that you find the biggest, ugliest, gas-guzzler you can find (in 1980 this would have been something like a 1968 Plymouth Fury) and, so long as it passes some minimal safety tests (one I remmember involved taking the car up to about 60 MPH and then slamming on the brakes -- it the pedal didn't completely sink to the floor you were in), buy it and then do nothing to maintain it. No tuneups, no oil changes, nothing.

The other thing I took away was an introduction to astronomer Guy Ottewell's Astronomical Calendar and related publications. The most fascinating of these was the Astronomical Companion, an oversize format paperback that provided an ever expanding 3-D view out from Earth of it's stellar neighborhood.

I spent hours looking at those 3D views of the other star systems around us, and always wished there was a software program that could provide a similar perpective.

Well, StarPlot is such a program, whose source is available for compiling on Linux and "Linux-like" systems.

StarPlot uses the GTK toolkit, and so you'll need the appropriate development libraries to build it. When I compiled it last, I did a "./configure prefix=/opt/starplot" to keep all the code in one directory. Here's my "starplot.desktop", that I dropped into /usr/share/applications.

[Desktop Entry]
Name=Starplot
Comment=3D Star Mapping
Exec=/opt/starplot/bin/starplot
Icon=/opt/starplot/share/starplot/starplot1e.png
Terminal=false
Type=Application
Version=0.95.4
Actions=Full;
Categories=Application;Astronomy;X-Red-Hat-Extra;
Encoding=UTF-8


The application icon is a user contribution copied off the StarPlot home page.
After building and installing, I chowned /opt/starplot so that my "user" group had ownership and chmod'ed to give the group write permissions.

Using StarPlot is pretty intuitive. You can load (or merge) additional star catalogs like one that contains stars with planets. I loaded the Gliese catalog in order to locate GL581. There are tools included to convert generic star catalog files to the .star format used by StarPlot. Another great piece of open source astronomy software.

Building XEphem on Fedora 6


XEphem is a full-featured astronomical epehemeris program for Linux and Linux-like systems (e.g. FreeBSD and it's non-free cousin, Mac OSX). While there are prebuilt rpms out there, none are available for the latest version (3.7.2), and those that are require enough customization to make them work that it is easier just to compile from source.

Here's my own build and configure recipe.

  1. Download and unarchive the source tarball from http://www.clearskyinstitute.com/xephem/.

  2. Drill down to the GUI/xephem directory and (for Linux) run "make MOTIF=../../linux86".

  3. Create a directory called /opt/xephem and copy the newly compiled "xephem" binary to it. Then cp -R the other directories that the INSTALL file indicates to this same directory.

  4. Create a shell script called "xephem.sh" in /opt/xephem with the lines:
    #!/bin/bash
    cd /opt/xephem
    ./xephem

    Create a soft link from this shell script to /usr/bin/xephem.

  5. Use chown to set ownership on "staff" or other common user group for allowing people to write to shared directories, and then chmod g+w.

  6. For each user who will use the program, create a ~/.xephem directory and a XEphem file under it containing the line "XEphem.ShareDir: /opt/xephem".

  7. To get a menu item in Gnome, create the file /usr/share/applications/xephem.desktop and give it the following content:
    [Desktop Entry]
    Name=XEphem
    Comment=Astronomical Ephemeris
    Exec=xephem
    Icon=/opt/xephem/auxil/logo.gif
    Terminal=false
    Type=Application
    Version=3.7.2
    Actions=Full;
    Categories=Application;Astronomy;X-Red-Hat-Extra;
    Encoding=UTF-8

  8. Run xephem and set it to your default location, click update and then save.

It's the Hardware, Stupid!

Trying to track down the cause of my Firewire problems, I came across this blog post.

The output of dmesg on my machine matched his:

ieee1394: Initialized config rom entry `ip1394'
ohci1394: fw-host0: Get PHY Reg timeout [0x00000080/0x00000000/100]
ohci1394: fw-host0: OHCI-1394 1.1 (PCI): IRQ=[18] MMIO=[ecefe000-ecefe7ff] Max Packet=[2048] IR/IT contexts=[11/32]
ohci1394: fw-host0: Get PHY Reg timeout [0x00000080/0x00000000/100]
ohci1394: fw-host0: Get PHY Reg timeout [0x00000080/0x00000000/100]

The result from lsmod was less promising:

ohci1394 37489 0
ieee1394 294809 1 ohci1394

Doing a modprobe on raw1394, dv1394 and ohci1394 garnered this changed result:

dv1394 22821 0
raw1394 30789 0
ohci1394 37489 1 dv1394
ieee1394 294809 3 dv1394,raw1394,ohci1394

So far so good, I was tracking the author's experience closely. Running dmesg again, I now got:

ieee1394: Initialized config rom entry `ip1394'
ohci1394: fw-host0: Get PHY Reg timeout [0x00000080/0x00000000/100]
ohci1394: fw-host0: OHCI-1394 1.1 (PCI): IRQ=[18] MMIO=[ecefe000-ecefe7ff] Max Packet=[2048] IR/IT contexts=[11/32]
ohci1394: fw-host0: Get PHY Reg timeout [0x00000080/0x00000000/100]
ohci1394: fw-host0: Get PHY Reg timeout [0x00000080/0x00000000/100]
ieee1394: raw1394: /dev/raw1394 device initialized
WARNING: The dv1394 driver is unsupported and will be removed from Linux soon. Use raw1394 instead.

At this point I knew. It was my hardware. Specifically my IEEE1394 PCI card. It had to be. Over a decade of experience in computers told me that was the answer.

A cheap, $12 card, made in some sweatshop in China, had cost me a week's worth of late nights.

The moral of the story? Hardware fails. It's a physical law. As my middle brother used to say, heat is the greatest enemy of electronics -- and computers run awful hot compared to other appliances.

I could go down to the local computer shop and get a replacement card, but I already know they're only going to have the same low cost card that just failed on me. So instead I'm going up on Newegg and order something slightly more expensive made by SIIG (a company whose components went into the first PCs I built for hire back in the late 80's). Right now, however, I'm going upstairs to power down the machine and remove the faulty card.

Script to check on an Oracle DB

Just a simple shell script that uses tnsping to check if a remote db is listening.
$ORACLE_HOME and $ORACLE_SID are hardcoded (there are fancier scripts around that go out to parse oratab and tnsnames.ora, which is particularly useful when you want to ping more than one instance).

#!/bin/bash
ORACLE_HOME=/u01/app/oracle/product/10.2.0/client
ORACLE_SID=testdb
RESULT=`$ORACLE_HOME/bin/tnsping $ORACLE_SID|grep -q OK`
if [ $? -eq 0 ]; then
echo "db is up"
else
echo "db is down"
fi

Fedora 6 Tips & Tricks

Fedora 6 Tips & Tricks is a great page by Gregory Gulik that's just packed with information on customizing the configuration this distribution. It's going on my links list for sure.

x3270 configuration

A big shoutout to my colleagues out there who were among the pioneers of Linux on the S/390 (the Marist College distribution). Here is my .x3270pro file, which I shamelessly ripped off from here. Essential software for running all those TSO sessions required to get the "iron penguin" properly configured:

! x3270 profile
! This file overrides xrdb and .Xdefaults.
! To skip reading this file, set NOX3270PRO in the environment.
! Put together by Carey Evans, 1997-1998.
! This file is in the public domain.

x3270.keymap.5250: \
MetaF1: PF(1)\n\
ShiftF1: PF(13)\n\
ShiftF2: PF(14)\n\
ShiftF3: PF(15)\n\
ShiftF4: PF(16)\n\
ShiftF5: PF(17)\n\
ShiftF6: PF(18)\n\
ShiftF7: PF(19)\n\
ShiftF8: PF(20)\n\
ShiftF9: PF(21)\n\
ShiftF10: PF(22)\n\
ShiftF11: PF(23)\n\
ShiftF12: PF(24)\n\
F1: PA(1) PF(1)\n\
F2: PA(1) PF(2)\n\
F3: PA(1) PF(3)\n\
F4: PA(1) PF(4)\n\
F5: PA(1) PF(5)\n\
F6: PA(1) PF(6)\n\
F7: PA(1) PF(7)\n\
F8: PA(1) PF(8)\n\
F9: PA(1) PF(9)\n\
F10: PA(1) PF(10)\n\
F11: PA(1) PF(11)\n\
F12: PA(1) PF(12)\n\
Return: EraseEOF() Tab()\n\
ShiftInsert: Dup()\n\
Insert: ToggleInsert()\n\
KP_Insert: ToggleInsert()\n\
ShiftHome: PF(5)\n\
End: FieldEnd()\n\
Control_L: Reset() PF(10)\n\
Control_R: Enter()\n\
ShiftEscape: PF(11)\n\
Escape: PF(9)\n\
Pause: PF(11)\n\
Print: PF(4)\n\
Prior: PF(7)\n\
Next: PF(8)\n\
Scroll_Lock: PF(1)\n\
KP_Enter: Enter()\n

! model (-model)
x3270.model: 2
! keymap (-keymap)
x3270.keymap: alt,5250
! charset (-charset)
x3270.charset: us-intl
! toggles (-set, -clear)
x3270.blankFill: true

! File updated Fri Jun 17 21:26:10 2005 by x3270 v3.3.2p1 Wed Jul 7 11:09:00 EDT 2004 root
! emulator font (-efont)
x3270.emulatorFont: 3270-20

wireless networking with ndiswrapper

The house laptop (a Dell Inspiron 1200) just got an upgrade to Fedora Core 6, so I had to once again set up wireless networking on it. My prefered route is to use ndiswrapper, because it supports so many different cards. Basically I followed the instructions found on the project's web site. The steps were simple:
  • Install the kernel source rpm for the running kernel (for CentOS this would be something like kernel-devel-2.6.9-42.0.3.EL.i686.rpm, you usually can get by doing a "yum install kernel-devel"). If installing from a downloaded rpm file, use "rpm -ivh ".
  • Download and unarchive the ndiswrapper source tar.gz to /usr/src/redhat/SOURCES.
  • Change directory into the unarchived ndiswrapper directory under SOURCES and make an rpm using make rpm.
  • Install the rpm (found in /usr/src/redhat/RPMS).
  • Download and unarchive the D-Link driver for the card (in my case a DWL-G650C b/g device).
  • Install the desire driver with ndiswrapper -i DRIVER.INF from within the unarchived driver directory.
  • Do a modprobe ndiswrapper.
  • Edit modprobe.conf to include the following lines:

    options ndiswrapper if_name=wlan0
    alias wlan0 ndiswrapper

  • Create a ifcfg-wlan0 (see example below) and a keys-wlan0 file (containing the line KEY: xxxxxxxxxxxxxxxxxxxxxx) to hold your config and credentials for WEP authentication.
  • Restart the network and take the laptop for a walk around the house.

Following is a copy of my ifcfg-wlan0 file:
# Atheros Communications, Inc. AR5212 802.11abg NIC
DEVICE=wlan0
ONBOOT=yes
BOOTPROTO=dhcp
TYPE=Wireless
MODE=Managed
ESSID=mynetworkessid
RATE=Auto
NETMASK=
DHCP_HOSTNAME=
IPADDR=
DOMAIN=
HWADDR=
CHANNEL=1
USERCTL=no
IPV6INIT=no
PEERDNS=yes

Red Hat Summit

Here are the Summit Highlights from this year's meeting in San Diego.

liberation fonts

These are really good. Still not a 100% replacement for the old Microsoft core fonts (here is a recent link to an rpm for those), but a nice set of quality fonts that look great in Firefox.

Thanks to Red Hat for the gift.

VMware Server on Fedora Core 6

Ran into a little trouble installing VMware Server on Fedora Core 6 last night. Especially annoying because I had a limited time to get it done before going down to put the kids to bed.

There's apparently an issue with the latest Fedora Core 6 kernel (you've got to wonder if Red Hat is having a problem with kernel maintainence lately, see my earlier post on the show-stopper bug I experienced with Fedora 7) that prevents the vmware-config.pl script from compiling the module it needs to run the software.

This is not the same bug that was discussed here, and that fix does not work.

I finally found the answer on the VMware Workstation Forum in a post entitled "Error on rebuild after kernel upgrade, 2.6.20-1.2952.fc6". Note: As of 22 Aug 2007 the referenced patch is at v113, and the location it can be found at has been updated in the link below.

The latest "vmware-any-any-update" patch that provides the workaround discussed above is found here. Just run the enclosed runme.pl script instead of the shipping vmware-config.pl (runme.pl executes vmware-config.pl after applying the requisite patches). All Fedora users owe the patch author, Petr Vandrovec (userID "petr" on the VMWare Server Forum), a debt of gratitude for providing this free service to all of us.

Trouble among the hats

My effort to migrate to Fedora 7 isn't going well. Apparently the machine I'm running is subject to a bug in the shipping kernel that still hasn't been fixed.

Under "Common Issues" for this first release under the new community rules, there's this glaring acknowledgement:

Dell Dual Core Systems
Bug 241249 - Some Dell laptops with Intel dual-core CPUs (Core Duo, Core 2 Duo, Pentium Dual Core) may require the maxcpus=1 option at installation boot time.

Except, from the notes appended to the initial bug report, it's not just dual core Dell laptops, but also desktops, made within the last 2 years. My Dell E510n, which was made just last year, has a 1.83 GHz Pentium D 820 (Smithfield) and is a pretty generic desktop. In fact, it was built to run an open source O/S -- it shipped with FreeDOS.

Wading through all the comments, some of which characteristically include disparaging remarks about the processors involved that are extremely unhelpful from an engineering point of view, I found several proposed workarounds, none of which worked for me.

(Still no acknowledgement of other annoyances, like the latest Adobe Acrobat acroread script failing to work on anything after Red Hat Enterprise 4/Fedora 5)

As a result of all this I decided to rebuild my machine with Fedora 6 instead, which went very smoothly. Of course I'll keep checking in on bugzilla to see what, if any, progress is made fixing the Dell dual core CPU issue. Ironically, my free copies of the install discs for Ubuntu 7.04 i386 and x86_64 just arrived. Timing is everything. Still, I think I'll put those Ubuntu disks someplace where I can get to them quickly. Just in case. Being a sysadmin means ALWAYS having a Plan B.

Back to Fedora -- for Firewire!


It's been a long, fun trip with CentOS on the desktop. But all good things must come to an end. In the next week I'm going to move my personal workstation at home to Fedora 7. It's not that CentOS doesn't provide the best, most rock-solid server environment in the world (next to their Upstream OS Provider). It's the devices. A specific Firewire device in particular.

This has been a difficult decision because I migrated off Fedora a few years ago to get away from the exhausting pace of new releases that the developers maintain. Rebuilding up to a new major version every 6 months was just not my idea of fun. And then there were the dependancy failures that inevitably resulted when someone forgot to dot an "i" or cross a "t" when releasing an upgrade package that touched a few dozen other packages. That's OK for a development distro, which is what the developers keep reminding us is what Fedora is. For someone who spends most of his day wrestling enterprise software into submission, howerver, it was a little too much.

But I need good, reliable, Firewire support. I really do.

You see, in addition to being a full-time tech, I'm also a full-time dad to a couple of very active kids. That's why I bought a nice new Sony DV cam last summer. When I was on CentOS 4 I was able to use a combination of the latest centosplus kernel and hours of Googling to get the right configuration to allow me to download taped video onto my workstation for editing. Since getting up on CentOS 5 I've tried the same procedure again, although there still is no release version of centosplus and I've had to make due with test. Although it worked for a day, it suddenly just quit. Although lsmod shows the ieee1394 and ohci1394 modules loaded, none of my software like kino can see the camera or it's output.



So, in the hopes that the newly re-engineered Firewire stack in Fedora 7 will do the trick, I'm migrating off CentOS and back onto Fedora. I've already added a second, real big, hard disk to the box, and moved all the stuff I want to save onto it. All that's left is to tar up etc, home and var just in case I missed something. Then the fun will begin.

Hopefully this will be the last rebuild I'll need to do for awhile. I've already done 3 in the last couple of months, from CentOS 4 to CentOS 5 x86_64 and then to CentOS 5 x86. Just need to be careful about not running an open-ended "yum update".

Palm Foleo

The new Palm Foleo was just announced the other day.



Specs aren't all that detailed yet, but it's supposed to have a 10" screen, a web browser and a GUI e-mail app. It's being billed as a "mobile companion", but if I can run a terminal on it and the battery life is better than a laptop, I'd buy one in a second.

Four things in it's favor:

  • "Just right" sized screen and keyboard. 10" is small enough to still be portable, but big enough to let you get useful stuff done;

  • Rumor has it that it runs a Linux variant. That means it could run Linux, which means that systems guys like me can learn to expand it's capabilities (like by adding a terminal app).

  • Industry standard wireless networking. No info yet on whether it can handle WPA, or what protocls it uses (please, please, let it be a/b/g!).

  • Specs released so far say no hard disk (flash memory?), and works up to 5 hours on a charge. For something with no moving parts that's actually a little disappointing, because you know vendors never actually achieve the battery life they claim.

Although Palm is playing it safe by marketing it to the gadget-loving executives and executive wannabes who are their customer base, it has real potential as a no-nonsense laptop replacement for 24x7 sysadmins like me. For now, I've put myself on the mailing list for when they actually ship.