The BFC Computing Weblog

From Fedora Weekly News:

Daniel P. Berrange laid it out there. “There is pretty much zero chance that Fedora 10 will include a Xen Dom0 host. While upstream Xen developers are making good progress on porting Dom0 to paravirt_ops, there is simply too little time for this to be ready for Fedora 10. So if you need to use Fedora 10 as a host, then KVM is your only viable option at this time. If you can wait for Fedora 11 (or use RHEL-5 / CentOS-5) then Xen may be an option for you.”

The basic issue is that the the virtualization groups are getting together on a standard kernel interface, paravirt_ops, and the Xen folks aren’t ready yet. Fedora 10 has a hard deadline, and the Xen group isn’t likely to make it in time.

Why Fedora 10 is important, is that Fedora 8 will stop getting security updates once Fedora 10 is released, per policy. When Fedora 9 came out, the Fedora Project told Xen users to hold off on Fedora 9, that Fedora 10 would have the Xen pieces. Had it told users at that time stop using Fedora they might have had a reasonable opportunity to plan for a chance, but at this point they have only weeks to get their systems off onto another operating system.

While RHEL/CentOS have always been billed as the ‘stable’ platform, many community-minded systems administrators run Fedora as a way to help find problems and improve the codebase. In return, they get more up-to-date packages and an expectation of being able to upgrade to new releases as they’re available.

Now, for the first time I can recall, Fedora has dropped its end of the bargain, for any folks who are using Xen virtualization. I know I don’t deploy any new servers these days that don’t use virtualization, and I doubt I’m highly unusual in that regard. Fedora thus stands to lose a great number of users, i.e. testers, trust and goodwill. After all, if one of the two major kernel flavors can get the axe, just about anything else can too. It raises the question of what Fedora provides, as a distribution. Sure, we understand that the upstream kernel isn’t ready, but is Fedora willing to merely have its feature set dictated by outside parties? This is as much a function of Fedora’s release-by-date rather than release-when-ready policy. They want to release approximately every six months, come hell or high water, and while momentum is desirable in a vacuum, sometimes the community might deserve some consideration as well.

The current expectation is that the Dom0 bits will be in kernel-2.6.28. By all expectations, this release will come about 90 days after 2.6.27 is released, or approximately mid-January, if not sooner. One would hope since the Xen kernel no longer requires a separate RPM package that when Fedora adopts 2.6.28 as its primary kernel (early Feb ‘09, perhaps) that Xen Dom0 support will re-appear.

So, to arrive at a detente, the most practical approach would be to extend Fedora 8 security updates until such a time as a Xen-Dom0 kernel is integrated into Fedora. Without argument, this will consume precious development hours among the Fedora development community. And Fedora can legitimately argue that it’s ‘for experimental use only’ and plausibly get away with not doing so. However, the practical reality of choosing this path is to lose community-sourced testing hours orders of magnitude larger than would be saved by continuing the updates. And since RHEL 6 will require a stable Xen base for its release, Fedora 10 with Xen is going to be very important to have well shaken-out for RHT.

On an RPM-based system, yum-utils provides a utility called ‘package-cleanup’. It has two useful options:

–orphans shows RPM packages that do not belong to any currently-configured repositories, and:

–leaves shows RPM packages for which there are no dependencies; that is removing them won’t trigger the removal of other packages. By default it’s concerned with libraries, but –all removes that restriction.

So, ideally you’d like to run:

package-cleanup –orphans –leaves –all

to get a list of all the packages you might want to consider for cleanup, say before or after an upgrade. But package-cleanup doesn’t support that.

So, here’s a little perl script, called leavesorphans.pl on my system that will run package-cleanup twice and print for you the intersection of the two sets:

#!/usr/bin/perl -w
          use strict;
          use warnings FATAL=>'all';
          
          use Data::Dumper;
          
          my @orphans = `package-cleanup --orphans`;
          my @leaves = `package-cleanup --leaves --all`;
          
          my (%orphans,%leaves);
          foreach my $orphan (@orphans) {
              $orphans{$orphan} = 1;
          }
          foreach my $leaf (@leaves) {
              $leaves{$leaf} = 1;
          }
          
          my (@matches);
          foreach my $orphan (keys %orphans) {
              foreach my $leaf (keys %leaves) {
                  if ($orphan eq $leaf) {
                      push (@matches,$orphan);
                      delete $leaves{$leaf};
                  }
              }
          }
          
          
          foreach my $match (@matches) {
              if ($match !~  m/Setting up yum/) {
                  print $match;
              }
          }
          
          

I recently ran it and found a few packages that were lingering on my system since Fedora Core 4, just wasting system resources. If all of your proper packages belong to a repository you can simply pipe the output of the command to xargs rpm -e. I’m not quite that slick, so I manually reviewed the list and kept the packages I had installed by hand.

Folks running their own local yum repositories using cobbler will have to add new repos to get continued updates, the ones signed with the new signing key.

This isn’t hard, simply pick your mirror for f8 or f9 and add it to cobbler like the following:

cobbler repo add --mirror=http://mirror.anl.gov/pub/fedora/linux/updates/8/i386.newkey/ --name=f8-i386-updates.newkey
          cobbler repo add --mirror=http://mirror.anl.gov/pub/fedora/linux/updates/9/i386.newkey/ --name=f9-i386-updates.newkey
          

and then edit your fedora-updates-newkey.repo file to point to your local software distribution host. Assuming you have a cron job installed cobbler will start your downloads when it next syncs.

Remember, this will get you 8-ish GB of updates per release, so make sure you need to do this. Assuming you do, the Fedora Project will be updating removal of the old signing key automatically, so get this done before they do that or your nightly security updates may stop coming in.

There’s been much made of the revelation that Diebold voting machines run an install of McAfee Anti-Virus, and that it’s caused trouble with the voting software.

The arguments against it typically boil down to:

• Your voting machines shouldn’t be use for anything else
• Your voting machines should be secured against anybody installing software on it
• You can’t verify the operation of MAV so it could possibly tamper with votes
• You should be running an operating system which is not so easily infected

Those arguments all have merit, but skip the fundamentals - the software image on a voting machine should not be running on read/write media, that is hard drives. If that basic criteria isn’t met, AV software might actually be a good idea, but missing the fundamentals is no excuse for dirty hacks.

I build my first appliance computer that could run from a CD in a CD-ROM drive in 2002. It’s neither new nor a difficult concept. When you need things to be secure, in that case under HIPAA regs, in this case for votes, you mount your media device (hard drive, flash memory, etc) with the ‘noexec’ flag, and then no software installed on the read/write media can be run from that media. Since you can’t write to the CD, software can’t be run from there either. You provide a stripped down OS image to make doing any more than the minimum very difficult, certainly requiring physical access to the machine.

This isn’t to say your machine shouldn’t be kept secure - of course it should, and the BIOS needs to be correctly configured (many of you know the security problems with certain BIOS configurations) - but read-only media and a good Q/A process obviates the need for anti-virus software. Certainly some software selection choices can make this difficult, but any good architecture starts with the requirements and works towards software selection, not the other way around. Assuming good security is a requirement.

Unfortunately the GNU java in CentOS 5 is too old to run modern Java code. So, you need to install the Sun version in many cases, and the jpackage method is typically the best way to do that. Two problems, though:

• They don’t have an RPM that represents the current Sun version
• Their version doesn’t work well on CentOS due to CentOS RPM bugs

If you don’t have them already installed, you need the RPM development tools. Something like:

yum -y install rpm-build rpmdevtools

should be sufficient. (note: I’m assuming you’re root. Most of this can also be done with a local RPM build tree and sudo, but is beyond the scope of this article).

As of this writing the current security release of the Java JDK is 1.6u7, which you can get here. Pick 32-bit linux (the only type I tested) get the linux non-RPM version, and put the downloaded ‘.bin’ file in /usr/src/redhat/SOURCES.

Now, download my updated spec file and put it in /usr/src/redhat/SPEC. If you’re on a Fedora platform or CentOS fixes their version of rpm you might want this non-CentOS spec instead. This latter one builds everything just fine on CentOS but there are UnixODBC link errors due to the rpm bug.

Now, build Java with:

cd /usr/src/redhat
          rpmbuild -ba SPEC/java-1.6.0-sun-centos-5.spec
          

This will take a while. You should wind up with a bunch of RPM files in RPMS/i586/, like this:

-rw-r--r-- 1 root root 43085836 Aug 11 22:48 java-1.6.0-sun-1.6.0.7-1jpp.i586.rpm
          -rw-r--r-- 1 root root    35903 Aug 11 22:48 java-1.6.0-sun-alsa-1.6.0.7-1jpp.i586.rpm
          -rw-r--r-- 1 root root 10473773 Aug 11 22:48 java-1.6.0-sun-demo-1.6.0.7-1jpp.i586.rpm
          -rw-r--r-- 1 root root 21709383 Aug 11 22:48 java-1.6.0-sun-devel-1.6.0.7-1jpp.i586.rpm
          -rw-r--r-- 1 root root  1259794 Aug 11 22:48 java-1.6.0-sun-fonts-1.6.0.7-1jpp.i586.rpm
          -rw-r--r-- 1 root root    26057 Aug 11 22:48 java-1.6.0-sun-jdbc-1.6.0.7-1jpp.i586.rpm
          -rw-r--r-- 1 root root   807126 Aug 11 22:48 java-1.6.0-sun-plugin-1.6.0.7-1jpp.i586.rpm
          -rw-r--r-- 1 root root 17692845 Aug 11 22:48 java-1.6.0-sun-src-1.6.0.7-1jpp.i586.rpm
          

Use yum to install them like this:

cd RPMS/i586
          yum --nogpgcheck localinstall java-1.6.0-sun-*.rpm
          

It should find dependencies, something like this:

Dependencies Resolved
          
          =============================================================================
           Package                 Arch       Version          Repository        Size 
          =============================================================================
          Installing:
           java-1.6.0-sun-alsa     i586       1.6.0.7-1jpp     java-1.6.0-sun-alsa-1.6.0.7-1jpp.i586.rpm   79 k
           java-1.6.0-sun-demo     i586       1.6.0.7-1jpp     java-1.6.0-sun-demo-1.6.0.7-1jpp.i586.rpm   15 M
           java-1.6.0-sun-devel    i586       1.6.0.7-1jpp     java-1.6.0-sun-devel-1.6.0.7-1jpp.i586.rpm   36 M
           java-1.6.0-sun-fonts    i586       1.6.0.7-1jpp     java-1.6.0-sun-fonts-1.6.0.7-1jpp.i586.rpm  2.0 M
           java-1.6.0-sun-jdbc     i586       1.6.0.7-1jpp     java-1.6.0-sun-jdbc-1.6.0.7-1jpp.i586.rpm   69 k
           java-1.6.0-sun-plugin   i586       1.6.0.7-1jpp     java-1.6.0-sun-plugin-1.6.0.7-1jpp.i586.rpm  1.6 M
           java-1.6.0-sun-src      i586       1.6.0.7-1jpp     java-1.6.0-sun-src-1.6.0.7-1jpp.i586.rpm   18 M
          Installing for dependencies:
           java-1.6.0-sun          i586       1.6.0.7-1jpp     java-1.6.0-sun-1.6.0.7-1jpp.i586.rpm   68 M
           libXp                   i386       1.0.0-8.1.el5    base               23 k
           unixODBC-devel          i386       2.2.11-7.1       base              739 k
           unixODBC                i386       2.2.11-7.1       base              832 k
          

And yum should download and complete without errors.

Now, make sure that this new version of Java is set to be the default with:

/usr/sbin/alternatives --config java

and enjoy current java. Hopefully it won’t be long before Sun gets its code freed so next time you can just ‘yum -y install sun-java’.

I’ve written before about the limited usefulness of plausible deniability, especially in relation to software like TrueCrypt, a hard drive encryption program.

The gist of plausible deniability with TrueCrypt is this: You have multiple encrypted hard drive partitions. When your enemy forces you to reveal your keys, you reveal the low-cost key, and the enemy sees some data that he doesn’t care about and sends you on your merry way. The ‘real’ stuff you want to hide is still hidden.

This works if two conditions are true:

• The enemy doesn’t know you employ a product with plausible deniability
• The enemy can merely detain you

If those conditions aren’t true, you’re in big trouble. Say a violent group gets you and your data. They know TrueCrypt has plausible deniability, and they really want your data. You’re going to be tortured until they get what they want, it’s that simple, and ugly.

Now, the worst possible scenario is that you can’t give up ‘your data’ because it doesn’t exist. But only you know that. The bad guys think you have it and they know you have plausible deniability. You’re completely screwed.

For this reason I’ve been against plausible deniability systems for defending against all threats (yes, TrueCrypt would still be fine from hiding that porn you have stashed away on your home PC).

This changed when Cal Harding introduced the concept of Complete Deniability. That is, you can prove that you have no more plausible deniability.

Here’s how it can work: With TrueCrypt, you could have a utility that, once inside a locked data set, could be given a set of keys and ensure that those keys account for all readable data and all blocks of the storage device. Because TrueCrypt is open source, the bad guys can trust this utility to verify that you’re no longer hiding anything. They can review the source and compile it themselves, if they wish.

But, good news for you, you get to go home. Because even bad guys don’t like to waste their time and you’re not otherwise terribly interesting. Odds are you’re not getting your laptop back once the bad guys find your porn bank, though.

Photos of Jeff Bonwick of ZFS fame and Linus Torvalds of Linux fame. Turns out that they’re neighbors and Jeff was just helping Linus hook up a new gas grill. (j/k)

ZFS is the ‘one filesystem to rule them all’ but it can’t be brought into the Linux kernel because of patents and licenses. ZFS is licensed under the CDDL, which gets it into FreeBSD and OSX, which are BSD and thus compatible with the CDDL, but not into the Linux kernel, which is GPLv2. If Linux were GPLv3, it would be possible for Sun to also license ZFS as GPLv3 and the twain could meet. However, Sun doesn’t really need to bother if Linux isn’t going to do it.

Note that a cleanroom implementation of ZFS could be GPLv2-compatible, but since it’s not CDDL-based the code wouldn’t have patents grants. “Sun Sues Linux Kernel Developers, News at 11” helps nobody.

I wrote on the ZFS list that having ZFS as a de-facto standard would lift all boats, and help Sun sell Thumpers. Assuming Jonathan dispatched Jeff to broker a “I’ll show you mine if you’ll show me yours” with Linus, we can look forward to the day when digital cameras come with ZFS flash cards instead of FAT32. And that the current owner of the FAT32 patents would be further isolated is really a key point.

In the long and continuing saga to have a decent mobile Internet solution that is friendly to Free Software, I’ve been working out a porting strategy to get rid of my Treo 650, which, while it’s been useful, is now beyond the end of its useful life. The replacement for the Treo is a Nokia n810, which is not a phone, but can use a phone over Bluetooth to get Internet access. It’s a great little linux box, with a Mozilla-based browser with Flash and wealth of 3rd party apps via .deb repositories. Wifi, bluetooth, GPS, etc. Meanwhile, I want a phone with good phone audio quality (pretty much rules out smartphones - bummer), EVDO, Bluetooth, and 4+ hours talk time (so I can run it all day without charging). A flip-phone is really what I want, to avoid accidental dialing in my pocket (DAMHINT), not just for the Captain Kirk factor.

I have a decent workflow established with the Treo 650 and Missing Sync on Mac OS X that works pretty well for me. Access, the company which owns Palm OS, released, a while back, a PalmOS 5 emulator for the Nokia n810 which runs all the basic Palm applications. I tried getting this working earlier but wasn’t successful.

Now that’s changed. One unexpected checkbox later and I have full HotSync between n810/Garnet and Missing Sync 5.1 on Mac OS X 10.4.11. Here’s how to do it:

First, in the Sharing Pane of System Preferences, make a new firewall exception like this, to allow in Network HotSync preferences:

Now, add a new handheld in Missing Sync, and change the Preferences, to include these:

And set the various standard conduits to overwrite data on handheld with desktop (once only).

Now, on the Garnet VM, put in the IP address of your Mac (dns didn’t work for me), and click the HotSync button. You should get a successful sync. Do it again to make sure it does nothing, quickly, indicating successful sync. Change some data on both ends and make sure it syncs. OK, you’ve got sync.

Now, go back and uncheck the allow-all-handhelds-to-network-sync box to protect your data. Make sure ‘Network’ is set in ‘Edit Handhelds’, and it’ll continue to work. I’m not sure what happens the first time, but there must be some handheld negotiation that’s required without permissions. Minor inconvenience, just needs to be documented.

All the iCal stuff should sync just fine, but MemoPad apparently doesn’t allow a way for sharing Memos between handhelds. So, to get this you also need to copy the Memo data file; copy:

~/Documents/Palm/Users/treo-profile/MemoPad.memopad

to:

~/Documents/Palm/Users/n810-profile/MemoPad.memopad

and sync again. You should have all your common Palm data on the n810 at this point.

Have fun. I ordered a new-in-box Motorola e815 radio from eBay for $90, which meets all my phone criteria. From here, I’d like to move to KDE PIM apps, and perhaps OpenSync. OpenSync to iSync is a non-starter, currently, but perhaps SyncML can bridge the gap.

This is good news for fans of RPM-based systems: Two separate consolidations are underway. rpmfusion will be created by the merging of livna, freshrpms, and dribble. rpmrepo will be formed by the merger of the former rpmforge (dag and dries anyway), atrpms, and CentOS Extras. Both will use either RHEL + EPEL or Fedora as the base package set.

This should lead to more hands, more users (larger community), easier configuration for users, and potentially fewer conflicts, and hopefully less prejudice.

For those who have been around a while, apparently livna and atrpms have stopped replacing system packages, so they need not be feared any longer.

Everybody keeps asking, “When will Linux be a serious contender on the desktop?”. My answer: “Oh, yeah, I remember PC’s.”

Linux is already well entrenched in the server space, it’s starting to dominate the mobile space, with at least Motorola and Nokia going linux, and it’s showing up on every other type of device - the Kindle, Kindle’s competitors, and every-other network device on the shelf at Staples.

So, just as Windows and MacOS are doing well defending their territory, people will start to abandon the historical concept of a PC and relegate it ‘to that thing they used to hook up to those old-fashioned landline phones.’

It’s been just about a decade since I beta-tested the MacNC (code name MiB), Larry Elison’s network computer that Steve Jobs was making for him. They canned that, stuck a hard drive in it and called it an iMac. Larry was right - he just thought everybody else had a ten meg pipe into their homes when they were all still on dial-up. A couple years from now, reality is going to catch up with him.