The BFC Computing Weblog: Category Linux

Fedora 10 GPG Key

Bill McGonigle — Thu, 04 Dec 2008 03:21:00 -0500

To verify the Fedora 10 package downloads, you need the new key they're signing the Fedora 10 packages with, but it's only included in the -release rpm which you don't want to install on some other machines, say your repository mirror.

This works:

rpm --import 'http://pgp.surfnet.nl:11371/pks/lookup?op=get&search=0xBF226FCC4EBFC273'

I wonder why this is different than the -newkey key. Anyway, don't take my word for it, check the signatures to prove it for yourself.

Snow Leopard Comes in the Dark and Kills Your Tiger

Bill McGonigle — Fri, 21 Nov 2008 03:04:00 -0500

Apple's Snow Leopard (10.6) operating system is due out in the next quarter according to slides shown recently at the LISA conference. It adds a small handful of features but it's mainly an architecture, performance, and bugfix release. Leopard (10.5) is pretty buggy and Apple readily admits it's not what an OS should be. So they're coming out with an update less than a year and a half since the last one, which is by most counts what Leopard should have been. This isn't really disputed, even Apple's name isn't for a new cat, this is the one with all the 'marks cleaned off'.

OK, so it's great that Apple's getting everything squared away so quickly, right? Yeah, it is if you've got recent hardware.

But what if you have a computer that was purchased in, say, the first half of 2006? It's going to have a PowerPC processor in it, and Snow Leopard doesn't support PowerPC. OK, so then you can run Leopard, which does support PowerPC. But, wait, Leopard is buggy, that's why they're fixing it.

OK, so you can run Tiger (10.4). Well, no, if you're going to be connected to a network you'd be foolish to do that; Apple only issues security updates for the current and previous versions of its OS, and with 10.6, 10.4 will go by the wayside. Within months there will be public exploits for your 10.4 machine available and the time to your machine being compromised is just a roll of the dice.

"Wait," you may be saying, "my machine is less than three years old and it's now unsupported?" "It's still under AppleCare warranty and I can't even get security updates?"

Yep, and there we see the tactical brilliance behind splitting the Leopard and Snow Leopard releases - Apple gets to book its revenue early on a not-ready OS, beat Microsoft to the market, and save a ton of money really only supporting one majoor version of its operating system. So, this doesn't really work out well for you? Just buy a new Mac, they're probably not going to do this again in three more years. Right?

This may be a dangerous gamble for Apple in a recessionary economic period, so perhaps they'll do the right thing and simultaneously keep their customer base. If not, Ubuntu 8/PPC isn't eligible for a commercial support contract but it'll run on your Mac and its security updates will be current for another two years. At that point your machine will be five years old and you can keep it around with debian or netbsd or if we're coming out of the downturn get yourself a brand new machine. By then you'll be so used to Ubuntu you'll have broad purchase options.

My Last Mac

Bill McGonigle — Tue, 14 Oct 2008 14:29:00 -0400

From today’s new Macbook announcement:

11:01AM Q: Concern about the glossy screens. Are you going to offer another option?
A: Steve: We're going all glass -- we won't offer another version. 
Phil: You offset the reflection by the brightness, and consumers love it. One of the great things about a notebook is you can turn it however you want!

I’ve used a Mac laptop since 1992 as my primary machine and often find myself using it in situations where I can’t actually rearrange the furniture or move the windows (Phil apparently lives in an opaque bubble). So I’ve always ordered a Macbook Pro with a matte screen, because my brain simply can’t see through the glare. Some people can, my eyes don’t work that way.

Yeah, their marketing images actually
show the reflected keyboard

So, today marks the end of availability of new Macs I can use. Since OSX doesn’t run on other hardware (securely) this means I can’t plan on using OSX into the future. I’ll keep a machine around for media work in the short term, but it’s obvious I need to get as much of my work moved over to Linux as possible if I’m going to have hardware that’s current technology.

With Apple’s primary focus on the iPod/Phone market, its draconian tactics there, and its inability to deliver a stable next OS release this is merely the last straw (if it were the only problem I’d consider investing in custom coatings, etc.) Thanks, Apple, it’s been a fun 16 years.

Update: Not just me.

Fedora Strands Xen Users

Bill McGonigle — Mon, 06 Oct 2008 12:39:00 -0400

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.

Package Cleanup - Leaves and Orphans

Bill McGonigle — Tue, 30 Sep 2008 14:12:00 -0400

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.

Fedora, Cobbler & Newkey

Bill McGonigle — Thu, 18 Sep 2008 22:11:00 -0400

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.

Anti-Virus on Voting Machines

Bill McGonigle — Mon, 25 Aug 2008 21:10:00 -0400

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.

Sun Java for CentOS 5

Bill McGonigle — Mon, 11 Aug 2008 23:03:00 -0400

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’.

Complete Deniability

Bill McGonigle — Thu, 10 Jul 2008 19:51:00 -0400

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.

ZFS/Linux Summit Meeting

Bill McGonigle — Mon, 19 May 2008 20:19:00 -0400

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.