YAPC::NA 2008 abstract

This talk will cover the current state of Perl development in Fedora (and, by extension, RHEL, CentOS, etc.). Topics will include the following:

• Status of Perl on Fedora
  
  • Perl SIG
  
  
  • Number of Perl modules available in Fedora and EPEL
  
  
  • What we have and what we're missing
  
  
  • Licensing


• Using Perl packages
  
  • Using virtual rpm dependencies
  
  
  • yum, repoquery, etc.


• Packaging Perl modules
  • Generating packages using cpanspec
  
  
  • Building packages with rpmbuild
  
  
  • Using mock
  
  
  • Checking for problems with rpmlint
  
  
  • Submitting packages for inclusion in Fedora

And the fun continues...

I have desktop effects in KDE 4! For a while, it seemed like no matter what I tried, kwin gave the following error:

Failed to create Scene object. Compositing disabled

The solution was to turn off Xinerama and switch to using TwinView. I can't say that I'm thrilled with that, but since I only have two monitors on one video card at the moment, it does work.

Oh, and I'm learning to like the yum-skip-broken plugin... It makes yum a fair bit slower than usual, but a slow (but working) "yum --skip-broken update" is better than a failed "yum update".

Rawhide eats babies - Film at 11

So since moving into the new store, I haven't been doing as much Fedora work as I'd like (or need to). I thought I might kick myself in gear a little if I tried actually running rawhide on my personal desktop.

As an aside, I should note that the box in question has been hand-upgraded since Slackware 2.0 in July of 1994 when it was a 386SX/16. Sometime in 1995 or 1996, I converted the box from a.out to ELF by hand. Then a few months later I installed rpm so I could install some interesting applications that were available in Red Hat Linux. (By this point I was running RHL on all of my newer systems.) At some point, I converted my initscripts over to RHL-style SysVinit and ran almost entirely RHL packages. I never ran the installer for upgrades (doing upgrades by hand with rpm at first, with apt later) until I upgraded from FC1/i386 to FC3/x86_64. Since then, all my upgrades have been done with yum. (Oh, and the box that started life as a 386SX/16 is now a dual dual-core Opteron 265. I think it is on its 8th motherboard. I'm about due for the 9th, but that's another story...)

So, anyway, I was running Fedora 8, fully updated, so I tried just doing "yum --enablerepo=*development update" (the "*" so I'd get livna too). That didn't work for some reason I don't remember now, so I thought I'd try breaking up the upgrade into smaller, more managable chunks. I started by doing "yum --enablerepo=*development update yum* rpm*". That didn't exactly work.

At least rpm still worked. I manually updated apt. It was working fine for a little while (although dist-upgrade wouldn't quite work due to some confusion between packages being renamed/replaced, multilib weirdness, etc.) but then when I finally came up with a small transaction for it to run (hoping to get yum working again by upgrading python and a few other things), it complained about size mismatch on some packages on my local mirror. After holding some of them to try to get around the problem, all of a sudden apt-get would hang on any command and suck 100% of the CPU.

So, understandably a bit frustrated at this point, I decided to try smart out. The GUI crashed repeatedly. It filled up /var copying repodata off my NFS-mounted mirror. When I finally got around all that, it had the same problems "apt-get dist-upgrade" did.

So I gave up on smart and decided to try to get yum working. Obviously there was just a missing dependency somewhere, probably just on the newer python in rawhide, but unfortunately the newer python required a newer openssl, which means upgrading just about everything. So after cleaning up a bunch of unnecessary i386 packages, I cheated and installed the newer python, openssl, and a few other things with "rpm -Uvh --nodeps". (Note: Don't try this at home. I'm a professional.) Guess what? After all that yum blew up with the same error as before.

So back to apt. I uninstalled apt entirely, moved my /etc/apt/ out of the way, and reinstalled apt. I recreated the bare minimum configuration that I needed. After that, apt-get worked again! (Something finally worked right!) I did a "apt-get -f install", which sucked in most of the packages from rawhide, and it worked! And yum even worked! Next, I tried "apt-get upgrade". That worked, although it held back a lot of packages. When I tried "apt-get dist-upgrade", I started getting size mismatch errors again.

So I went back to yum. A yum update got me completely upgraded. Time to actually start testing...

I restarted X. Well, I tried to restart X. Guess what? The nvidia binary driver doesn't play nice with the newer Xorg server. So I tried nv and nouveau. Neither would drive my second monitor. (I run a dual-DVI 7800GT.) So I went back to the nvidia binary driver and downgraded X to the Fedora 8 version. Luckily, that actually worked.

I have a whole list of things that are messed up in KDE 4(.0.0, as I'm sure every KDE fan including myself would be quick to point out). In no particular order:

• In general, things (panel, desktop stuff) aren't Xinerama-aware.
• The panel won't auto-hide, resize, or otherwise not be in the foreground.
• The Oxygen kwin theme doesn't seem to be configurable. It's nice and all, but the window borders are way too wide, and I'd really like a color change in the title bar or something else really obvious to let me know which window has the focus. That, or somebody needs to implement focus-follows-eyes.
  
• Desktop effects don't work for me. I'm still trying to figure this one out. (Could be related to this. I'm still using version 100.14.19 of the nvidia driver from livna. The 169.07 driver made etqw crash.)

In other news, Firefox (or, as it refers to itself, Minefield) looks nice. It seems to run really well in fact. Unfortunately, the only extension I use that has been updated for Firefox 3 is Flashblock. Ironically, the flash plugin isn't actually working though. (In the process of upgrading, I ditched 32-bit Firefox for the 64-bit Firefox though, so I might just need to work a little to get nspluginwrapper working. At least I hope that's all it is...) (UPDATE: The applix-libs package installed in 1998 was mistakenly providing libXt.so.6, libSM.so.6, libICE.so.6, and various other things it shouldn't have. Apparently I had removed the correct versions while upgrading. Reinstalling those libraries made flash work again.)

On another positive note, I ran (package naming guidelines-violating) OpenOffice.org not-quite-2.4.0 briefly to look at a resume someone sent me, and it looked nice and ran fast, so no complaints there.

Oh, and etqw hangs after a while, but it started doing that on Fedora 8 + updates a couple of weeks ago, so I expected that. (It crashed entirely with 169.07. Backing off just the nvidia update made it only hang. Good thing I still have an un-updated laptop I can run the game on... :-)

Goodbye Perl6::Bible. Hello Perl6::Doc.

Ralf and I seem to have discovered independently at nearly the same time that the Perl6::Bible "module" is finally being replaced with Perl6::Doc. I have a perl-Perl6-Doc package sort of ready, but I am not sure what to do about a few things.

1. Do we bother to obsolete the perl-Perl6-Bible package? I wouldn't be surprised if I was the only person who bothered installing it.
2. If we obsolete the perl-Perl6-Bible package, should we symlink the p6doc script to p6bible on the off chance that anyone was using the p6bible script?
3. What do we do about the name conflict with the p6doc script included with Pugs?
   

Recovering data from a HP Media Vault

I had a customer bring in a drive from a HP Media Vault that had failed (or flaked out or something, we're really not sure yet). It was kind of interesting trying to find data on the drive, so I thought I'd share...

First, the drive obviously didn't have a standard PC partition table.

# fdisk -l /dev/hdi

Disk /dev/hdi: 300.0 GB, 300069052416 bytes
255 heads, 63 sectors/track, 36481 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Disk /dev/hdi doesn't contain a valid partition table

I should note that I tried testdisk at this point too, but it didn't find anything. Next, I checked for anything recognizable at the beginning of the disk.

# dd if=/dev/hdi count=8 | strings
Broadcom NAS Version 1.1 MBR Tag
SYSTEM
8+0 records in
8+0 records out
4096 bytes (4.1 kB) copied, 0.00013262 s, 30.9 MB/s

After a little Googling for "broadcom nas", "hp media vault", and a few other things, I figured out there was a reiserfs filesystem on the thing somewhere. (Note: As pointed out in the first comment to this post, there is some great technical documentation on this thing online. Rather than follow it, I chose to cheat and do this the (relatively) easy way.) Google found me this nice document describing the on-disk structure of reiserfs. That's how I figured out that I was looking for a magic string "ReIsEr2Fs" (or "ReIsErFs" for version 1, or "ReIsEr3Fs" for version 3, according to some other search results). I used hexedit to find the offset of the magic string by doing hexedit /dev/hdi, hitting tab, hitting /, then typing in ReIsEr.

2685A020   84 03 00 00  1E 00 00 00  00 00 00 00  00 10 CC 03  06 00 01 00  52 65 49 73  ....................ReIs
2685A038   45 72 32 46  73 00 00 00  03 00 00 00  05 00 B7 08  02 00 00 00  CC A3 00 00  Er2Fs...................

In this case, the magic string was at hex location 2685A034, which means the beginning of the superblock was at 2685A000, or (decimal) 646291456 bytes. The beginning of the superblock is 64k bytes before that, so I set up a loop device there:

# losetup -o $[ 646291456 - 65536 ] /dev/loop0 /dev/hdi
# mkdir /mnt/tmp
# mount -r -t reiserfs /dev/loop0 /mnt/tmp

The files my customer needed were in /mnt/tmp/FileShare/.

Why I suck at business

So anyone who knows me probably knows about the store, but I try not to make a big deal out of it here or in my normal away-from-the-store interaction with people. The fact is, I just don't like mentioning it, for fear that people will think I'm advertising, and I'm only in it for the money. This post is already making me incredibly uncomfortable...

That said, I need some help figuring out some way to advertise some classes I'll be teaching starting in February. Kara and I have invested a lot in the training room in our new store (which makes the local Linux users group meetings much more comfortable), so we have to start making some money on it soon. As it happens, I'm a darn good sysadmin (IMHO), and I like to talk, so teaching is a natural thing for me. ;-)

The classes I'll be teaching are all Linux system administration-related. Half of them are LPI Linux certification classes (on account of the O'Reilly book on the subject I helped write). There's a Google Calendar with dates, but no class descriptions yet. (Details available on request, but I obviously need to get them posted somewhere...)

So I need to figure out a way to get the word out, preferably to the St. Louis area (and the midwest in general, I suppose) that a) doesn't cost a ton of money (because that's all tied up in the new shop), b) doesn't make me feel like a total weasel, and c) doesn't make the intended audience think I'm a total weasel. Suggestions (like, what advertising do you actually pay any attention to and maybe trust a little) would be most appreciated.

Oh, since I'm talking about work, and in case my lovely and talented wife reads this, I have to point out for the record that she owns and runs the business. (In addition to being extremely averse to "sales", I also happen to be horrible with money. On the other hand, she happens to be good at that and more. :-)

Hard drives suck

In my day job, we go through a lot of hard drives. It seems now that no matter how good a drive manufacturer is, drives still show up DOA, die early, die not-so-early, etc. This is the reason I like Seagate so much. While I fully expect their drives to start dying naturally at 18 months or so (they don't always, but that's when I really start keeping an eye on them), at least with their 5-year warranty I know I can get replacement drives without spending a lot of money constantly.

Anyway, a while back I got rather tired of replacing drives that were DOA or after less than 30 days of service, so I figured out that burning them in with a combination of SMART self tests and badblocks seemed to weed out the early failures rather well. I wrote this script to run those tests for me. All it needs is smartctl and badblocks (which are probably available on most live Linux CDs, but definitely on Fedora and Knoppix). It will work on any IDE or SATA drive. With a little work, it could probably handle SCSI drives, ATA drives on 3ware controllers, etc.