Dutch log

I keep hitting a bug in make-kpkg when building recent kernels, and I always forget the fix. So, blogging it here for ease of reference

Original post was found at http://lkml.org/lkml/2006/7/16/109

Miro, formerly known as Democracy TV, made its first public release a few days ago.  It’s available at http://www.getmiro.com/. Miro is like a blog aggregator for video sources such as YouTube and Google Video, as well as provider content such as various news  and science tv channels, The Onion.

Installing it was trivial under Ubuntu, although it conflicts with the blackdown JRE. You can install the sun jre instead to get around this.

Debian Etch (4.0) was released on Monday, and I have to say I wasn’t at all prepared. I’ve got about 70 machines that will probably need to be upgraded to Etch at some point in the near future. I could leave some of them running sarge, but I’ll definitely have to upgrade most of these servers.

We use an apt-proxy internally, to improve apt performance. It works well, aside from a couple of bugs that cause it to lock up every now and then. While running some upgrades on out of the way servers today, I discovered that the version of apt in sarge really doesn’t play very nicely with an etch repository served by apt-proxy running on an etch server. It seems that Ubuntu is fine, and trying to update a sarge server via an apt-proxy running on an etch server is ok too.

Once the etch client has been upgraded, the etch apt-proxy works fine. So, looks like a key issue. The version of apt in sarge doesn’t have the archive security stuff in it, and has no way of checking whether the keys are intact - BUT, it still seems to care, and will timeout and eventually fail.

It turns out that installing a copy of apt from the sarge backports solves this. You’ll also need the gnupg package, but the one from sarge is OK

It turns out there’s a race condition in Feisty Fawn, which can cause software RAID sets to not be set up on boot. This is problematic if you have your root partition on software RAID

Bug #75681 discusses this in some detail, although there are several suggestions on how to fix it.

I first hit this bug on a local machine, then had to the same upgrade on a machine in a different country. Needless to say I wanted to get it right. I’m archiving my notes here as I’m sure I’ll need them eventually. This race condition has probably already been fixed in Feisty, but it’s not worth risking on a remote machine.

First of all, there is some new management involved in setting up software RAID under feisty, so you need to make sure you read the documentation for the mdadm package. Every time an initramfs is generated it will generate a warning:

Following those instructions, you are told to check the configuration in /etc/mdadm/mdadm.conf and compare with the output of /usr/share/mdadm/mkconf. Once you’ve done that, you can remove /var/lib/mdadm/CONF-UNCHECKED and re-run update-initramfs -u -k all to regenerate your initramfs images.

The particular race condition that I mentioned above occurs because udev hasn’t had time to stabilise before mdadm tries to create the array, which means mdadm can’t find the devices and fails. The fix suggested in the bug report is to insert udevsettle into the initramfs at an appropriate point, and recreate the initramfs images:

This works, at least as of today. I don’t know if the bug is actually still a problem or not - I didn’t want to risk it./

As part of my upgrade to Edgy the other day, Firefox was upgraded to 2.0. It’s been upgraded every day since then, and is I think finally running a real 2.0 build
$ apt-cache show firefox | grep Version
Version: 2.0+0dfsg-0ubuntu3
The biggest interface changes I’ve noticed to Firefox 2 so far include some cosmetic changes to the tab panel layout, which I’m mostly used to, and the ‘backspace’ button now no longer steps backwards in your history.
This behaviour is controllable via about:config however. Setting the following will revert to the old behaviour.
browser.backspace_action = 0

After seeing this announcement for the Edgy Eft RC1 release, I decided to upgrade my Dapper laptop to Edgy. Thanks to the NZ mirror already being up to date, it didn’t take long to download the 700MB of packages that I needed.
I’d like to say the upgrade went smoothly, but it didn’t. Part of that is my own fault - I accidentally used apt-get instead of aptitude to handle the upgrade, and so a lot of packages were missed, and some dependency resolution was fumbled which meant the upgrade process broke hard along the way.
After manually removing a bunch of packages then getting the upgrade to restart, then repeating “aptitude dist-upgrade” about 6 times after it thought it’d finished, each time installing a couple of new packages, and then finally rebooting one more time because I couldn’t get X to start again, it all looked good.
Except that when I logged in, GNOME didn’t appear to start. I killed X and added a new user, then logged in as them - worked fine. Tried my user - no go. I spent a long time trying to move various GNOME configs out of the way, and eventually resorted to creating a new blank homedir for myself - still wouldn’t work. So I rebooted one more time and it started working after that. Very strange.
I’d suggest waiting for the final release to upgrade, but if you do go ahead, make absolutely sure you use aptitude and not apt-get. It may also work better if you use the CD and boot into an upgrade mode, I can’t comment.
I would file a bug, but I’m not sure it’ll help. I can’t pin down what was wrong because I used the wrong tool to upgrade. I have a Dapper install on my desktop at home, and I’ll try upgrading that next week when I get some free time, however it’ll probably “just work” by then anyway.
New things noticed in Edgy Eft so far:

Firefox 2
Network-manager-applet has a dialup account plugin.

Yeah. It looks the same. Edgy does have new features under the hood, but I haven’t looked into those yet.
Update: Yeah, it’s called Edgy Eft, not Efty Edge.

I saw a couple of blog posts about puppet recently. I’ve been meaning to investigate cfengine for a while now, and puppet was a new angle on the same problem. From the intro:
Puppet is a system configuration tool. It has a library for managing the system, a language for specifying the configuration you want, and a set of clients and servers for communicating the configuration and other information.
The library is entirely responsible for all action, and the language is entirely responsible for expressing configuration choices. Everything is developed so that the language operations can take place centrally on a single server (or bank of servers), and all library operations will take place on each individual client. Thus, there is a clear demarcation between language operations and library operations, as this document will mention.
It’s very new still, and is under active development. It seems to have been designed with fixing some of the hassles of cfengine in mind. It is written in ruby and has a reasonably powerful config language, and you can use embedded ruby templates for dynamically building up content to deploy. I have no particular preference for ruby - in fact, this is the first time I’ve used the language. Configuration is stored in a manifest on the puppetmaster server, and is based on the notions of classes and nodes. A node can inherit from multiple classes, or can merely include a specific class if certain criteria are met. Subclasses can override specific details of a parent class.
It makes use of a library called facter (also written by reductive labs), to pull information ‘facts’ from the client hosts, and these can be used in the manifests to control configuration. For example, it will work out the linux distribution you are running and store this in a variable, and you can use this to determine which classes to run.  It is fairly easy to extend facter to support additional facts - so I added support for working out the Debian and Ubuntu release number and codename - eg, 3.1 and sarge, or 6.10 and edgy.
There is a dependancy system in place, so that you can specify a rule to ensure that a service is running, which depends on the package being installed. If you use puppet to manage the config file for the service, you can set a subscription on the file for the service, so that if a change to that file is pushed out via puppet, it will restart the server for you as well.
Installing packages is handled well, with the option for seeding debconf if appropriate. Puppet understands several package management formats, including apt, rpm and yum.
I’m by no means an expert with cfengine, but this feels a lot nicer to use. After my initial testing, I see no reason so far to not deploy this at work. I’ll test try a test deployment on some systems, and if that works out I’ll push it the whole way out.

I’ve been following the Xensource Xen Enterprise product for a couple of months at work. The current release ships with an install CD which preps a barebones server. It installs linux with a Xen kernel and the Xen toolset, but doesn’t ask you many questions - the dom0 is really only there to support the hypervisor after all. There are no options for software raid in the installer, but that might be because software raid isn’t considered an “enterprise” tool by some people.
Once it’s installed, you can run a JAVA based console from your desktop. This will connect to the XenEnterprise server and let you run some of the hypervisor commands as well as provision and configure domU.  XE ships with support for installing a debian server from a template, and for installing RHEL from a network install server. Apparently  it’s fairly straight forward to modify the templates or to create your own, I haven’t looked into that yet.
The console provides some monitoring of the dom0 and the domUs - network, cpu, disk and memory utilisation. The
console will connect to multiple XE hosts, letting you monitor and configure your domUs across your entire network.
One other neat tool that ships with XE is a P2V migration tool. That’s Physical to Virtual migration - you run a program on your existing physical machine, and XE will create a domU suitable for it and migrate the filesystem into the new host. However, I’ve yet to use this to see how well it works.
The kicker is, of course, the pricing. XE’s pricing is available online, and it starts at $750 + $150 annual maintainance for a 2 cpu server. The big benefits of XE come in when you have multiple servers in use, so start to scale that price up accordingly.   XE is also a bit limited in that you can’t do anything outside of the box yet. Which means that if you want, for example, pass a PCI device (eg, network card or SCSI controller) through to a specific domU, you are out of luck. This may not happen very often or at all, but it does make it somewhat less useful.
Overall, it’s a nice enough tool. If you are looking at managing a large number of densely packed Xen servers and want to be able to quickly provision new servers, clone existing servers, and migrate guests easily between hosts, it’s probably spot on.

Matt Brown asked if I could think of any way to allow a certain group of users to scp into a host and use a password, while requiring a valid key pair for most other users. Perry suggested a solution to this a while ago, so I sat down and had a quick look at it, and got it working.
I configured sshd such that:
PasswordAuthentication no
ChallengeResponseAuthentication yes
UsePAM yes
This bypasses direct /etc/passwd auth, but allows standard PAM based auth via the ChallengeResponseAuthentication mechanism. This will allow everyone to login with a password if possible, so we need to configure pam. For this, I used the pam_listfile module, checking that the user had a particular shell, /usr/bin/scponly, as their shell:
cat “/usr/bin/scponly” > /etc/scpshells
I then edited /etc/pam.d/sshd:
auth required pam_env.so
auth required pam_listfile.so item=shell sense=allow file=/etc/scpshells onerr=fail
auth sufficient pam_unix.so likeauth nullok
auth required pam_deny.so
auth required pam_nologin.so
session required pam_limits.so
session required pam_unix.so
account required pam_unix.so
password required pam_cracklib.so difok=2 minlen=8 dcredit=2 ocredit=2 retry=3
password sufficient pam_unix.so nullok md5 shadow use_authtok
password required pam_deny.so
I probably don’t need all of that in the sshd pam snippet, but I just dumped the contents of the included files into to to make editing it easier.
To test this I added /bin/bash to /etc/scpshells, and verified that I could ssh in by using a pasword. I then removed it, and verified that I could no longer ssh in with a password. Combine this with a suitable shell (/usr/bin/scponly), and I can create users that can scp in with a password - or with a key if they care - but cannot get a local shell; all other users cannot authenticate via PAM, and so must provide a valid key.