The Changelog - Debian

Thoughtfulness on the OpenSSL bug

nospam@example.com (John Goerzen) — Wed, 14 May 2008 05:48:00 -0500

By now, I'm sure you all have read about the OpenSSL bug discovered in Debian.

There's a lot being written about it. There's a lot of misinformation floating about, too. First thing to do is read this post, which should clear up some of that.

Now then, I'd like to think a little about a few things people have been saying.

People shouldn't try to fix bugs they don't understand.

At first, that sounds like a fine guideline. But when I thought about it a bit, I think it's actually more along the lines of useless.

First of all, there is this problem: how do you know whether or not you understand it? Obviously, sometimes you know you don't understand code well. But there are times when you think you do, but don't. Especially when we're talking about C and its associated manual memory management and manual error handling. I'd say that, for a C program of any given size, very few people really understand it. Especially since you may be dealing with functions that call other functions 5 deep, and one of those functions modifies what you thought was an input-only parameter in certain rare cases. Maybe it's documented to do that, maybe not, but of course documentation cannot always be trusted either.

I'd say it's more useful to say that people should get peer review of code whenever possible. Which, by the way, did occur here.

The Debian maintainer of this package {is an idiot, should be fired, should be banned}

I happen to know that the Debian programmer that made this patch is a very sharp individual. I have worked with him on several occasions and I would say that kicking him out of maintaining OpenSSL would be a quite stupid thing to do.

He is, like the rest of us, human. We might find that other people are considerably less perfect than he.

Nobody that isn't running Debian or Ubuntu has any need to worry. This is all Debian's fault.

I guess you missed the part of the advisory that mentioned that it also fixed an OpenSSL upstream bug (that *everyone* is vulnerable to) that permitted arbitrary code execution in a certain little-used protocol? OpenSSL has a history of security bugs over the years.

Of course, the big keygen bug is a Debian-specific thing.

Debian should send patches upstream

This is general practice in Debian. It happens so often, in fact, that the Debian bug-tracking system has had -- for probably more than a decade -- a feature that lets a Debian developer record that a bug reported to Debian has been forwarded to an upstream developer or bug-tracking system.

It is routine to send both bug reports and patches upstream. Some Debian developers are more closely aligned with upstream than others. In some cases, Debian developers are part of the upstream team. In others, upstream may be friendly and responsive enough that Debian developers run any potential patches to upstream code by them before committing them to Debian. (I tend to do this for Bacula). In some cases, upstream is busy and doesn't respond fast or reliably or helpfully enough to permit Debian to make security updates or other important fixes in a timely manner. And sometimes, upstream is plain AWOL.

Of course, it benefits Debian developers to send patches upstream, because then they have a smaller diff to maintain when each new version comes out.

In this particular case, communication with upstream happened, but the end result just fell through the cracks.

Debian shouldn't patch security-related stuff itself, ever

Well, that's not a very realistic viewpoint. Every Linux distribution does this, for several reasons. First, a given stable release of a distribution may be older than the current state of the art upstream software, and some upstreams are not interested in patching old versions, while the new upstream versions introduce changes too significant to go into a security update. Secondly, some upstreams do not respond in a timely manner, and Debian wants to protect its users ASAP. Finally, some upstreams are simply bad at security, and having smart folks from Debian -- and other distributions -- write security patches is a benefit to the community.

LinuxCertified Laptop LC2100S

nospam@example.com (John Goerzen) — Tue, 22 Jan 2008 05:21:00 -0600

As you might know from reading my blog, at my workplace, we have largely standardized on Linux on the desktop and laptop.

We use systemimager to maintain a standard desktop image and a separate standard laptop image. These images differ because there are different assumptions. The desktop machines mount /home over NFS, authenticate to LDAP, etc. This doesn't work on laptops. Moreover, desktops don't use network-manager or wifi, but laptops do.

Our desktop image uses Debian's hardware autodetection -- plus a little hacking in /etc/init.d/gdm -- to automatically adjust to a wide range of hardware. So far this has worked well.

Laptops are much more picky. Our standard laptop model had been the HP nc4400 -- a small and light 12" model that people here loved. HP discontinued that model. Their replacement was the 2510p. We ordered one in here for evaluation. Try as we might, we couldn't get it to suspend and resume properly in Linux.

So I went out scouring the field of Linux laptops. Companies such as Emperor Linux buy retail laptops from people like Lenovo, test them for Linux, and sell them -- at a premium. These were too expensive to justify at the quantities we need them.

Then I stumbled across Linux Certified. I'd never heard of them before. I called them up and asked a few questions. They don't buy retail laptops, but instead have OEMs in Taiwan build laptops to their spec. They happen to use the same OEM that Fujitsu does, I believe. (No big company builds laptops in the USA these days). I asked them about wifi chipsets, video chipsets, whether they use stock kernels. I got clueful answers to all of these.

So we ordered one of their LC2100s models. They didn't offer Debian preinstalled, but did offer Ubuntu, so I selected that. The laptop arrived a couple of days (!!) later, configured with the particular CPU, etc. that I selected.

I was surprised at the thrill I felt at taking a brand new laptop out of its box, turning it on, and watching Grub appear before my eyes. Ubuntu proceeded to boot. I then of course installed our regular Debian image on the thing to check it out.

It needed a kernel and xserver-xorg-video-intel from lenny, as well as the ipw3945 driver for wifi, but otherwise worked with the exact same software as our HP nc4400 image. (In fact, it wasn't hard to support both laptops with that image, since both use a lot of Intel hardware.) The one trick was making hibernate call /etc/init.d/ipw3945d stop so that the ipw3945 module could be unloaded before suspend. (Why this particular chipset needs a daemon is beyond me, but oh well.)

The hardware is great. As far as I know, the ipw3945 was the only component that wasn't directly and automatically supported by DFSG-free software in lenny main. The screen is sharp and high-contrast (it's glossy, which I personally don't like, but I bet our users will). The device itself feels sturdy. It's small and dense. I haven't opened it up, but it looks like all you need is a screwdriver to do so.

The only downside is that they don't sell docking stations for it. Their standard answer on that is to buy a USB docking station. That's a partial answer, but can't handle power or video like a standard docking station will.

Also, the LC2100s is much cheaper than the HP laptop, even when configured when nicer specs in every way. That is no doubt partially due to the lack of the Windows tax.

I'm sending off an order for 4 more today, I believe.

Linux Hardware Support Better Than Windows

nospam@example.com (John Goerzen) — Fri, 17 Aug 2007 06:07:00 -0500

Something I often hear from people that talk about Linux on the desktop is this: people want to be able to go to the store, buy hardware, and be confident that it will Just Work.

I would like to point out that things are rarely this simple on Windows. And, in fact, things are often simpler on Linux these days.

Here's the example that prompted this post.

I have a computer that's about 4 years old. It's my main desktop machine at home. It was still fast enough for me, but has been developing all sorts of weird behaviors. Certain USB ports stopped working altogether a few months ago. Then it started hanging during POST whenever I'd try to reboot -- but would still boot OK about 80% of the time after a power cycle. Then it started randomly losing contact with my USB mouse until a reboot. And the last straw was when the display started randomly going out. I've told everyone that my machine has cancer and is slowly dying.

The case is a pretty nice full tower -- solid and sturdy. I have an 160GB IDE drive in it. So I figured I will upgrade the motherboard, CPU, RAM, and add a 500GB SATA drive since they're so cheap these days and I'm running out of space. I'd also have to buy a new video card since my old one was AGP and the new motherboard only has PCI Express for video. So about $700 later from Newegg (I got a Core 2 Duo E6750), the parts arrived.

I spent some time installing it all. The motherboard had only one IDE channel, and I didn't have any IDE cable long enough to connect both the IDE hard disk and the optical drive, so I popped in an old Maxtor/Promise PCI Ultra133 controller I had sitting around to use with the DVD burner.

Now, to recap, the hardware that the OS would see as new/different is: CPU, RAM, IDE controller, SATA controller, Promise IDE controller, integrated NIC, sound, video.

Then the magic smoke test.

I turned on the machine. Grub appeared. Linux started booting.

Even though I had switched from the default Debian "supports everything" kernel to a K7 kernel, it still booted.

And every single piece of hardware was supported immediately. There was no "add new hardware" wizard that popped up, no "I've found new hardware" boxes. It just worked, silently, with no need to tell me anything or have me click on anything.

Only one piece required configuration: the NIC, thanks to some udev design flaws (it got renamed from eth0 to eth1 by udev). That took 20 seconds. Debian saw the IDE HDD, the SATA drive, the Promise controller, the DVD burner, the video card, the sound, and it all worked automatically. And Debian is not even a distro that occurs to a lot of people when they think of great hardware support.

Now let's turn to Windows.

The Windows Nightmare

I have a legal copy of Windows XP Home that was preinstalled on the machine when I got it. I resized its partition down to about 20GB so that I could use 140GB for Linux. I use it rarely, primarily for gaming, and I've bought about 3 games in the last 4 years. I usually disconnect the network when I boot to Windows, though I do keep it current with updates.

I did some research on what Windows was going to do when I replace the hardware. The general consensus from people on the 'net is that you can't just replace a motherboard and expect everything to be happy. There were generally three different approaches suggested: 1) don't even try, just reinstall; 2) do a rescue install after you move over; and 3) use sysprep. The rescue install has to be done by booting from an XP install CD, then picking a rescue install option somewhere. It will overwrite your installed Windows with the version from the CD. That means that I'd have to re-apply SP2, though bits of it that didn't get overwritten would still be on the hard disk, and who knows what would happen to the registry.

Option #3 was to download sysprep (must have the Genuine Disadvantage ActiveX to get the free download from MS). Sysprep is designed to be used just prior to taking an image with ghost for replication. It removes the hardware-specific config (but not the drivers), as well as the product key, from the machine, but otherwise leaves it untouched. On the next boot, you get the "Welcome to XP" wizard.

One other strike against #2 is that Compaq "helpfully" didn't ship any install CDs with the machine. Under Windows, they did have a "create rescue CD" tool, which burned 7 CDs for me. But they are full Compaq-specific CDs, not one of them an XP CD, *AND* they check on boot to see if you're using the same Compaq motherboard, and exit if not. Highly useless.

So I went with sysprep. Before my new hardware even arrived, I downloaded the Windows drivers for all of it. I burned them to a CD, and installed as many as I could on the system in advance. About half of them refused to install since the new hardware wasn't there yet. I then took a raw image of the partition with dd, just in case. Finally, right before I swapped the hardware, I ran sysprep and let it shut down the machine.

So after the new hardware was installed came the adventure.

Windows booted to the "welcome to XP" thingy. The video, keyboard, mouse, and IDE HDD worked. That's about it.

I went through the "welcome to XP wizard". But the network didn't work yet, so I couldn't activate it. So I popped my handy driver CD in the drive. But what's this? Windows doesn't recognize the DVD drive because it doesn't have drivers for this Promise controller that came out in, what, 2001? Sigh. Downloaded the drivers with the imac, copy them to a CF card, plug the USB CF reader into Windows.

While I was doing that, about 6 "found new hardware" dialogs got queued up. Not one of them could actually find a driver for my hardware, but that didn't prevent Windows from making me click through them all.

So, install Promise driver from CF card, reboot. Click through new hardware dialogs again. Install network driver, reboot, click through dialogs. Install sound driver. Install Intel "chipset" driver, click through dialogs. Reboot. Install SATA driver. Reboot.

So the hardware appears to all be working by this point, though I have a Creative volume control (from the old hardware) and a Realtek one in the tray. Minor annoyance to deal with later.

Now I have to re-activate XP. I dutifully key in the magic string from the sticker on my case. Surprise surprise, the Internet-based activation fails because my hardware is different. So I have to call the 800 number. I have to read in 7 blocks of 6 digits, one block at a time. Then I answer some questions: have I activated Windows before, have I changed hardware, was the old hardware defective (yes, yes, and yes). Then I get 7 blocks of 6 digits read to me. Finally Windows is activated. PHEW! Why they couldn't ask those questions with the online tool is beyond me.

Anyhow. Linux took me 20 seconds to get working. Windows, about 2 hours, plus another 2 hours for prep and research.

I did zero prep for Linux. I made one config change (GUI users could have just configured their machine to use eth1).

Other cool Linux HW features

Say you buy a new printer and want to get it set up. On Windows, you insert the CD, let it install 200MB of print drivers plus ads plus crap plus add something to your taskbar plus who knows what else. Probably reboot. Then the printer might actually print.

On Debian, you plug in the printer to the USB port. You type printconf. 5 seconds later, your printer works.

I have been unpleasantly surprised lately by just how difficult hardware support in Windows really is, especially since everyone keeps saying how good it is. It's not good. Debian's is better, in my opinion.

Debian Developers 7 Years Ago

nospam@example.com (John Goerzen) — Wed, 23 May 2007 23:54:19 -0500

Today while looking for something else, I stumbled across a DVD with the "last archive" of my old personal website. On it were a number of photos from the 2000 Annual Linux Conference in Atlanta, and the Debian developers that were there. These were posted in public for several years.

I've now posted all of them on flickr, preserving the original captions.

Here's the obligatory sample:

That's Joey Hess, using what I think was his Vaio. Most acrobatic keyboardist ever. Probably the only person that could write Perl with one hand comfortably.

What else can you see? The best of show award that Debian won that is now in my basement due to a complicated series of events, the Debian machines that were being shown off at the show, Sean Perry and Manoj, the photo with long-term corrupted caption, and of course, numerous shots of Branden.

I know the size stinks. It was scanned at a web resolution for 2000. I do still have the negatives somewhere and will post the rest of them, in higher res, when I find them.

Click here to view the full set.

And we're off!

nospam@example.com (John Goerzen) — Fri, 13 Apr 2007 05:13:00 -0500

Yesterday afternoon, we started our information meetings with employees about our Linux on the desktop project. We're underway on our migration.

But before I talk about that, I need to back up and describe what the project is.

We are converting approximately 80% of our 150 or so PC users to Linux desktops. They're Debian etch (4.0) running Gnome, Firefox (Iceweasel), Evolution, NFSv4, and SystemImager. Over the coming days and weeks, I'll be writing about why we're doing this, how we're making it happen, things we've run into along the way, and the technology behind it.

Today I'd like to start with a high-level overview of the reasons we started investigating this option.

It became apparent that Vista was going to be a problem for us. Most of our desktop PCs are not very old, but Vista meant a significant degradation in performance from the Windows XP Pro that most people were running. A performance dip so significant, in fact, that it would have created a significant negative impact on employee productivity.

We tend to buy PCs with Windows licenses from the vendor (Windows preinstalled). As such, we knew it wouldn't be long before XP-based machines would be hard to find. If we stuck with Windows, we'd be running a mixed-OS network -- which we knew from experience we did NOT want to do. The other option would be to replace all those old PCs. The direct costs of doing that, with the associated Vista and Office licenses, would have been more than $200,000.

So we started to look at other options -- changing the way we license Windows, sticking with XP for awhile, or switching away from Windows. This last option sounded the most promising.

I took a spare desktop-class machine, representative of the hardware most end users would have, and installed etch (then testing) on it. I spent a bit of time tweaking the desktop settings, making things as transparent to the user as possible. We liked what we saw and started pursuing it a bit more. We knew we had some Windows apps we couldn't discard, so we tested running them off a Windows terminal server with the Linux rdesktop client. That worked well -- and the appropriate Server 2003 licenses plus CALs would still be far cheaper than a mass migration to Vista.

To make a long story short, we are getting quite a few benefits out of all this. One of the most important is a single unified system image. Excepting a few files like /etc/fstab, every system gets a bit-for-bit identical installation from the server, updated using rsync. /home is mounted from the network using NFS (v4). So our users can sit down at any PC, log in, and have all their programs, settings, email, etc. available. A side benefit is that hardware problems become minor annoyances rather than major inconveniences; if your hard disk dies, we can just bring up a different PC. We had tried numerous times to make roaming profiles work in Windows, but never really achieved a reliable setup there -- perhaps because it seemed virtually impossible to assure that each Windows PC had the exact same set of software, in the exact same versions, installed.

More to come.

Disk encryption support in Etch

nospam@example.com (John Goerzen) — Tue, 19 Sep 2006 21:30:30 -0500

Well, I got my new MacBook Pro 15" in yesterday. I'll write something about that shortly. The main OS for this machine is not Mac OS X, though, but Debian.

I decided that, being a laptop, I would like to run dm-crypt on here. Much to my delight, the etch installers support dm-crypt out of the box.

Not only that, but they supported this setup out of the box, too:

Two partitions for Debian -- one for /boot, everything else on the second one

The second partition is completely encrypted

Inside the encrypted container is an LVM physical volume

Inside the LVM physical volume are logical volumes for /, /home, /usr, /var, and swap

XFS is used for each filesystem

Not only that, but it set up proper boot sequence for all of this out of the box, too.

So I turn on the unit, enter the password for the encrypted partition, and then the system continues booting.

Nice. Very nice.

Kudos to the debian-installer and initramfs teams.

HP Officially Supports Debian

nospam@example.com (John Goerzen) — Mon, 14 Aug 2006 14:07:59 -0500

Yes, it's true.

I have two words for this: Woohoo! Finally.

The SPI election results are in

nospam@example.com (John Goerzen) — Fri, 28 Jul 2006 19:51:48 -0500

The results are in. Bruce was removed from the board, and Josh Berkus, Neil McGovern, and Michael Schultheiss were added. (Neither Mako nor I sought another term.)

Congratulations to the winners -- I'm sure you will go far. I'm glad to see enthusiastic people around SPI and I'm sure you'll do a great job.

An additional RedHat Gripe

nospam@example.com (John Goerzen) — Fri, 21 Jul 2006 08:56:40 -0500

Debian base install: about 150MB

RHEL base install: about 1GB

df showing 1% of disk used: priceless

How to solve "The following packages cannot be authenticated"

nospam@example.com (John Goerzen) — Thu, 15 Jun 2006 11:47:00 -0500

Users of Debian's testing or unstable distributions may be noticing messages from apt saying things like:

WARNING: The following packages cannot be authenticated!

  foo bar baz

Install these packages without verification [y/N]?

I noticed today that google doesn't turn up good hits for the fix. The fix is really simple:

apt-get install debian-archive-keyring

apt-get update

That's it. You now have secure packages from Debian. Nice, eh?

Debian From Scratch 0.99.0 Is Out

nospam@example.com (John Goerzen) — Thu, 20 Apr 2006 07:34:00 -0500

At long last, I've finally updated Debian From Scratch (DFS). For those of you not familiar with DFS, it's a single, full rescue CD capable of working with all major filesystems, LVM, software RAID, and even compiling a new kernel. The DFS ISO images also contain a small Debian mirror subset that lets you use cdebootstrap, along with the other utilities on the CD, to perform a manual, "Gentoo-like" installation. It also serves as an excellent rescue CD, with a full compliment of filesystem tools, backup/restore software, and a development environment complete enough to build your own kernels.

DFS also refers to dfsbuild, the tool that generates DFS images. dfsbuild is available as a Debian package. dfsbuild is designed to make it trivial to build your own custom DFS images. You can have your own set of Debian packages on your images, your own kernels, etc. Unlike many other systems, you can go from the example dfs.cfg to a customized DFS build in just a few minutes, even if you've never used dfsbuild before.

Version 0.99.0 is a from-scratch rewrite and port to Haskell. You can read the full list of new features in the announcement, but the biggest is that it now supports standard Debian initramfs kernels in addition to ones that have enough drivers statically linked to be able to read the CD-ROM.

You can also download my DFS images or browse the docs online.

Rats, I finally had to make an upload.

nospam@example.com (John Goerzen) — Sat, 03 Sep 2005 08:44:54 -0500

From the netmaze package tracking page:

DFS Installation Tutorial

nospam@example.com (John Goerzen) — Fri, 27 May 2005 07:01:29 -0500

Suramya Tomar has written a very nice tutorial on installing Debian from my Debian From Scratch images (or from DFS images you build yourself). Nice and thorough work.

Running a Homeless Non-Profit

nospam@example.com (John Goerzen) — Fri, 04 Mar 2005 06:44:17 -0600

Software in the Public Interest, Inc. (SPI) is a fairly unique organization. It was originally created to be the legal entity that holds Debian's assets and can receive donations for it, though today it also has several other member projects. SPI is New York corporation, and a 501(c)3 not-for-profit.

I call it "homeless" because, like Debian, SPI has no physical home. There is no SPI office. Discussions about SPI are held online. Even the SPI board meetings and annual meetings are held online. This is a confusing concept to many people, but it makes perfect sense to us geeks. We have board members from the USA, Canada, UK, and Germany, at least. SPI maintains PO boxes for receiving mail, and that's about as close as it gets to a real physical presence.

I've been on SPI's board of directors for the last two years, and have been the SPI president since July. Sometimes this is a surreal experience.

Over its 8-year lifetime, SPI has had quite a few problems. A few years ago, SPI's board had trouble meeting because so many members didn't bother showing up that quorum wasn't met. At one point, SPI was without both a president and a treasurer because both of them seemed to suddenly lose all interest in SPI, or returning e-mails. As you might imagine, most of my time on the board has been occupied, in one way or another, with trying to clean up things from the past while still keeping the present held together.

One main cause of this, and a problem still today, is lack of interest. Most of Debian's developers are content to just ignore SPI, prefering to code instead of worry about getting stuff from the PO box to the bank, preparing tax returns, and all the other annoying things that go along with running a non-profit. So we don't have many volunteers to do these things. That means the people that do volunteer burn out. And, to date, there hasn't been enough support to obtain paid help.

I'm sure this isn't a problem unique to SPI. I suspect that many non-profit organizations have had trouble finding people to handle all the details of running the organization. Our church, for instance, sometimes has trouble finding enough people to work on maintaining the building.

I wonder if being "homeless" hurts us, because it's easier to give up on a task when there's nobody looking at you in the face wondering why it's not done.

So, I'd like to end with two questions:

How do you think SPI could get more people interested in helping out? Or do you think that we have a different problem entirely?

Debian From Scratch

nospam@example.com (John Goerzen) — Mon, 17 Jan 2005 12:58:14 -0600

Newsforge has a nice article about Debian From Scratch, my Debian install-it-yourself CD, rescue CD, and CD builder package. I must say, Bruce Byfield's instructions are more complete than my own documentation for it.

I now use DFS for most of my new Debian installations. Best of all, porting it to new archs is trivial.