Here's a handy incantation I use with the Intel X.org graphics driver on my laptop.

Put this script somewhere convenient:

#!/bin/sh
if xrandr   grep '^VGA connected' >/dev/null
then
    #echo "VGA connected"
    xrandr --output VGA --above LVDS --auto
    xrandr --output LVDS --auto
else
    #echo "VGA not connected"
    xrandr --auto
fi 2>&1   logger -t xrandr-hotkey

and bind it to your "switch video mode" key, e.g. Fn+F7 on my Thinkpad X60s. For instance, I run xbindkeys, so I saved it as autoxrandr and put this in ~/xbindkeysrc:

"exec /home/smcv/bin/autoxrandr"
    XF86Display

Now if you press the "switch video mode" key with a monitor plugged in, you'll get the external monitor appearing above the laptop panel (my preferred configuration - I've balanced my monitor on an N800 box to get the bottom of the screen level with the top of my laptop's screen). If you press that key again after unplugging the VGA cable, the laptop will turn off the VGA output and pull all the windows onto the built-in screen.

Although I lot of people have been lauding the Kindle, I recently decided to go with the Sony PRS-505 instead. Yes, the Kindle has built-in EVDO access, and the ability to buy books without a computer, or even browse the web; and yes, the Sony has once again demonstrated it can’t create a compelling 21st century computer application to save its life. However, it had a few things that at least for me, made a better choice for me than the Kindle:

1. The Sony is thinner — I want to be able to slip it into my laptop case and have it take the absolute minimum amount of space.
2. The Sony simply looks much more elegant than the Kindle; steel with a leather cover simply looks a lot better than white, cheasy plastic.
3. I’m not interested in buying a lot of DRM’ed ebooks; ergo, I won’t be buying may books from either Sony or Amazon’s web sites. It is highly likely that within 2 years I will be buying a more advanced eBook reader, possibly one with color, and I don’t want to be locked into a single format where I have to go and repurchase all of my books just because some the latest and greatest eBook reader uses an incompatible DRM technology from whatever Sony or Amazon has used.
4. The Sony is $100 cheaper. Given that something better will be available within 2-3 years at the very most, and possibly sooner, I’m just not interested in spending $400 on a first generation prototype.
5. Perhaps the most important, the Sony has the really, really good open source support. Kovid Goyal’s libprs500 project supports the Sony PRS-500 and PRS-505, and has very good version tools, allowing people to convert eBooks previously stored in HTML, PDF, TXT, Microsoft Reader (.lit), IDPF/Open eBook (.epub) into Sony’s format. And with a little bit of work, it does a very, very good job with the conversion. Better yet, its ability to convert multiple HTML pages into a single eBook, with credible table of contents, means that libprs500 can pull down the New York Times, the Economist, etc., automatically format it into a single eBook which you can save onto your Sony Reader, and then read it while you are on the airplane. No muss, no fuss. I can also take various books that are available on the web as HTML and also convert them into an eBook which can be used by the Sony Reader very easily.

This last point is I believe one of the best reasons why the Sony Reader will be able to compete very successfully with the Kindle. The libprs500 software is written as a python application, and it will work on Windows, Linux, and MacOS — and its GUI user interface is far better than the truly pathetic Sony Connect software. Score one for Open Source! In my opinion, Sony should send a very nice gift certificate to Kovid as a thank you; his open source project has added an immeasurable amount of value to their product. The only thing that you can’t do using the libprs500 software is buy DRM’ed books which are locked to the Sony Reader — but that isn’t something that many people will be particularly interested in, I suspect. OK, I did buy Pillars of the Earth, which was available on the Sony site for $6 dollars — hmm, cheaper than Amazon’s $9.99 — but that was an investment I was willing to flush down the toilet when the PRS-505 becomes obsolete, mainly so I could test what buying a DRM’ed book would be like from the Sony web site. But I probably won’t be buying many books with DRM that way. On the other hand, I am quite willing to spend quite a bit more money on non-DRM’ed books from publishes such as Baen Books. Here’s to the hope to the publishing industry figures things out faster than RIAA’s member companies. In the meantime, I will be mostly pretending that the both the Sony and Amazon eBook stores with their proprietary DRM’ed books don’t exist…

Working!
I've decided to replace the previous post rather than leave it in place when there is a solution available.
Fixing the problem
I've been considering a new laptop for weeks - mainly to get more RAM, more space but without adding to the actual size of the machine (or weight). I know, I should have taken more time over the selection, I should have found out more about the hardware, etc.etc.
I've ended up with an HP Pavilion dv6000 (dv6615ea) for the 2Gb RAM, 15inch screen, 250Gb hard drive to replace my ageing iBook 12inch with 128Mb RAM and 30Gb hard drive - all for barely an inch extra depth and very similar weight (and it was cheaper than the original price of the iBook). I thought I'd made a good choice. Yes, it was "NVidia Graphics" according to the sticker and yes, I could have spent more time (and money) finding a pre-installed lappy but I was hasty. (Much the same way as you should never go food shopping whilst hungry). I've managed with NVidia graphics before without using the horrid proprietary rubbish and I was prepared to put up with less-than-perfect graphics (I never use 3D anyway) because the free driver is at least stable with the graphics that I actually need.
Updated
The ethernet card is not recognised by the Debian Etch installer - after a comment placed on this blog after my original post, I tried the Lenny installer for amd64 with signficant success. Selecting the vesa driver for the graphics provided a usable X setup (1024x768). I've still spent a lot more time on this than it should really have required but I do now have a genuine amd64 Debian installation with GNOME. The only thing not working is wireless (oh and sound). The wireless appears to be a bcm43xx issue - the driver appears to let the card work (the orange light turns blue) and the device is created but scanning fails.
I'm probably still going to have to leave this new lappy behind and take my existing iBook to Fosdem in a few weeks, but I'm now happier with HP in general.
I'll try to post a longer review somewhere soon.
So, thanks for the tip, Julian!

In an old post I dealt with the nice mod_chroot module to secure your multisite server. I also adopted recently vlogger in order to manage better apache logs for virtual hosts, when you have dozens or hundreds of them. Unfortunately the suggested way to use it (a simple piped command) does not work nicely with mod_chroot, because the piped command has to run in the chroot jail.

Of course, it is not a good idea installing the whole perl intepreter and all required modules in a minimized jail, so I adopted an oldish classic trick (the old things are always the best) to solve the issue: using a named pipe. You basically need to do something like the following:

mkfifo -m 600 /var/run/apache2/logger && chown www-logs /var/run/apache2/logger

cat /var/run/apache2/logger /usr/sbin/vlogger -u www-logs -g nogroup -s access.log /var/log/vlogger >/dev/null 2>&1 &

/etc/init.d/apache2 start

Of course your log directives will be something like:

LogFormat "%v %h %l %u %t \"%r\" %>s %b \"% Referer i\" \"% User-Agent i\"" vcombined
CustomLog "/var/run/apache2/logger" vcombined

You absolutely need to run the reader before the writer, else the init script would hang for ever. It is easy adding a simple init script to run vlogger before apache and it has also the big advantage of not requiring re-fork a perl intepreter at every damn log action. Piping rocks.

Debian Enhancement Proposals (DEPs): wanna comment? Ok, ok, you're right, I was late, but a good old rule of SPAM is: the more, the better. So, if you care about decision management (or, better, tracking) in Debian and you've always wondered why don't we have something like PEPs? please take part in this discussion: a nice "by product" of the Extremadura Debian QA meeting by Dato, Lars, and myself.

I’ve climbed up above the tagclouds and appear to be back in the “blogosphere” whatever that is. I hate that “blog” word. I also hate the word “prosumer.” Spent last weekend in Raleigh at FUDCon which was a lot of fun. I doff my fedora to the organizers. It was great to finally have the opportunity to meet a lot of my coworkers who I haven’t yet had a chance to run into at conferences. Poked a bit at btrfs in my idle cycles… managed to make it fall-over-go-boom on parisc64. Fixing that up should keep me busy in my spare time for the next little while… Oh. And if anyone would like to make me a new disembodied head^W^Whackergotchi, I’d very much appreciate it.

After the debacle last time I tried to grow the size of my existing RAID1 when I put new disks in daedalus, I thought this time I'd do my homework. I did some research, I found out the way I should have done it. I did a practice run on a USB key. I fully planned how I was going to do it:

mdadm /dev/md2 --fail /dev/sdb3
<delete /dev/sdb3, recreate at new full size>
reboot
mdadm /dev/md2 --add /dev/sdb3
<wait for sync>
mdadm /dev/md2 --fail /dev/sda3
<delete /dev/sda3, recreate at new full size>
reboot
mdadm /dev/md2 --add /dev/sda3
<wait for sync>
mdadm --grow /dev/md2
<wait for sync>
pvresize /dev/md2

Everything went as planned, until I went to grow the RAID1 volume. It still thought the underlying device was the same size. There was nothing to grow. So at this point, I decided to do something similar to what I did last time to get around the failing disk, and should have done last time anyway. I broke the mirror, created a new degraded RAID1 using the full size of the new partition on the half I pulled out of the mirror, and did a pvmove from the old non-full-sized degraded mirror to the new full-sized degraded mirror. All of that went swimmingly until the pvmove was around 50% complete, when the kernel decided to oops spectacularly. I had to power cycle daedalus to get it back under control, and even in single-user mode, without me doing anything, the kernel started oopsing again. Dammit. I had to boot into emergency-mode (insert standard gripe about Debian's single-user mode being far too non-singular here), then I could resume the pvmove without any further oopsing. After that completed, I was able to ditch the old non-full-sized degraded RAID1 device and resync the new one onto the old partition. There was still some minor filesystem corruption, more likely because I had everything mounted at the time of the crash. Yes, I still haven't learned not to do this kind of thing in multi-user mode. It seems every time I try to minimise the size and duration of an outage, it bites me in the arse. Even though I should have been able to move open logical volumes between physical volumes, the kernel oops seemed to be in the dm_mirror code. daedalus is running a fairly old kernel. The annoying thing is that getting some additional disk space on board was the dependency for doing a general upgrade of all of the software on it. Argh. Anyway, it's done. I hope not to have to go through this again. I just have to sit through a potentially nail-biting remote upgrade of Debian now, and I should be good for a couple more years hopefully.

Recently I bought a new desktop PC and rotated my existing machines around, leaving me with one spare. Last night I donated that PC to a local friend, (co-incidentally the same woman who had been out cat-sitter when I went to stay at Megan's parents for Christmas). I said "Its got Debian on it, that funny operating system that you used when you were looking after our kitten, remember?". She said "Linux ssems to be getting popular these days I might as well try it out". But seriously she used it. It had GNOME, it had firefox, she seemed happy. It isn't rocket science these days to point a technicalish user at a Debian Desktop and expect them to know what to do with it. The only minor complication was the lack of flash/java since it was etch/amd64 - but thats probably a plus with the amount of flash adverts! In other news I made a new release of asql last night. This now copes with both Apache's common and combined logformats by default. (Yet another tool of mine which is now being used at work, which motivated the change.) I've also started pushing commits to xen-tools last night, so there'll be a new release soon. Mostly I'm bored with that code though, it doesn't need significant updates to work any longer. All the interesting things have been done, so it's probably only a matter of time until I drift off. (To the extent that I've unsubscribed myself from xen-users & xen-devel mailing lists) Virtualisation is increasingly a commodity these days. If xen dies people probably won't care, there are enough other projects out there doing similar things. Being tied to one particular platform will probably come to be regarded as a mistake. (Talking of which I should try out this lguest thing; I just find it hard to be motivated...)

It is not uncommon to run a Linux system with a kernel that was compiled for another distribution. One reason for doing this is the difficulty in compiling and testing a kernel to make sure it will do what you require. It’s not THAT difficult for someone who knows what they are doing, but if someone else has already done the work then it seems like a waste to re-invent the wheel. Sometimes it’s an issue of a driver that one distribution supports but not another, copying the entire kernel package from another distribution may be easier than compiling a new kernel with the extra driver. Sometimes it’s a kernel bug, if distribution A has fixed the bug and distribution B hasn’t, then it’s often easier to install a kernel package from distribution A when running distribution B. Another reason for running different distributions with the same kernel is Xen. If you have a Dom0 which hosts instances for different distributions as DomU’s then running the same kernel on all of them can make it easier to manage. Unfortunately it’s not uncommon for different distributions to have different kernel feature sets. One example I’m currently dealing with is the fact that the Debian/Etch kernel is compiled with CONFIG_AUDITSYSCALL disabled while RHEL and CentOS require it. So if you run a RHEL or CentOS system with a Debian kernel (EG running a Debian Xen server with a RHEL or CentOS DomU) then you see messages such as the following in your logs. crond[7824]: pam_loginuid(crond:session): set_loginuid failed opening loginuid The loginuid feature allows login and equivalent programs (which includes xdm and other graphical login programs, cron and every other program that runs a program on behalf of another user) to set the loginuid. This loginuid will be stored by the kernel, inherited across fork() and exec, and not be changed by running setuid or setgid programs. Therefore if you see some strange entries in your audit log indicating an attempted attack you can determine the original login UID of the person responsible. In terms of security features it’s not a really high priority. But it is really annoying when programs that work on RHEL don’t work properly with a Debian kernel and put many unwanted messages in the log files. For people who have less background knowledge about these things it may be more than annoying, and may even force them to change their deployment plans to make the message go away (not everyone knows which messages can be ignored or where to ask about such things). The fact that Etch has no user-space support for the auditing features in question (auditing system calls or setting the loginuid) was never a good reason for not enabling this feature (IMHO). Using the auditing system calls was simply a matter of copying the auditctl program from a RHEL, Fedora, or CentOS system (for those who didn’t feel inclined to compile the source). The loginuid required changes to PAM to enable it, but is actually a small part of the auditing layer. As a general rule minimising the differences between distribution kernels is going to benefit most people. Some people complain about kernel bloat, but there are worse candidates for that accusation and given that it seems impossible to buy a machine with less than 512M of RAM and a 900MHz CPU (the specs of the ASUS EeePC) adding a few extra kernel features seems unlikely to hurt anyone. It is of course always possible to compile your own kernel for the smallest machines. Finally I am in the process of back-porting SE Linux code and related security features to Etch, and having this already enabled in the kernel would make my work easier. I won’t do a 7 year support cycle for it unless someone pays, but supporting Etch past the release of Lenny with the latest SE Linux features (and the current features working properly) is my aim.

Share This

I've been quietly coveting the Zonbu for a number of months now. I finally caved in and ordered one when we got back from Australia, with the intention of using it to replace minotaur, the computer that exports my RAID10 via ATA over Ethernet to my MythTV box. minotaur is the old daedalus, which I bought back around 2000. It's a VA Linux Pentium III. It's old, noisy, and has no idea what power management is. The Zonbu has more grunt than it (in terms of BogoMIPS), and it's a fraction of the size. Our linen cupboard is now significantly quieter (and hopefully cooler). Heck, hopefully the power bill will be lower as well. Anyway, I put the order in when we returned from Australia, with the expectation that it'd turn up some time while Sarah was in hospital, or shortly afterwards, and I could use the rest of the month that I was off work to play with it. Well, I got an email on the 31st of December, telling me they were out of stock, and unless I wanted to pay $29 more for one with built-in WiFi, I'd have to wait until mid-January. As I just couldn't see the point of having WiFi (or spending more money) and not needing the thing in a hurry anyway, because I had more important things to worry about in the meantime, I opted to wait. This morning, I emailed them to enquire about whether or not more stock had arrived, and they emailed back to say that they were still waiting, but they'd found one they could sell to me anyway. The company happens to be close by in Menlo Park, so I picked it up today in our travels. Let me just say that it is a very cool little computer, just if you use it for its intended purpose. It's running a customised Gentoo Linux, with a 2.6.22 kernel. I'm a bit surprised about their choice of Gentoo. I think they'd be better off partnering with Canonical, given that Mark Shuttleworth is trying to make a Linux distribution easy enough for his grandmother to use. That'd take the work of engineering the operating system out of the equation, then they could just focus on the hardware and a bit of integration with Amazon's S3. The thing I have to give them mad props for is documenting how to hack the tripe out of the box. They tell you how to enable root. They tell you how to enable PXE booting. So once I figured out that the front USB port seems to get treated slightly differently for a USB keyboard than the back ones, it was very easy to PXE boot it and install Debian. I initially started with trying to install Etch, but I kept getting missed interrupts on the CompactFlash device, which resulted in the filesystems panicking. So I gave up and went with Lenny, and presumably because it also uses 2.6.22, everything seemed to go fine. The box comes with a 4Gb CompactFlash card, which is ample for my needs. It's running the 686-optimised kernel, which is probably not ideal, but works. We'll see how things go. Interestingly, I blew another hard drive power supply, exactly like last time. I've no idea if it's the act of plugging everything back in again that's causing the problem, or they're generally flaky, and they don't fail until they're powered off and back on again. Maybe that IEC Y-cable wasn't such a good idea after all. I've now run out of spare power supplies, so I'm going to have to get some more for when these two inevitably fry themselves. Overall, I'm very pleased with this purchase, but it's a bit early to see how it's going to perform. I can't imagine it's going to perform worse than the computer it's replacing, but it was probably never intended for what I'm using it for either... Oh, and I discovered vblade-persist, which seems to be a very nice framework for managing ATA over Ethernet exports. Now I just need to get my hands on a big tub of Lego to build a nice chassis for the whole thing.

From Italian usenet (reported to me by Xelloss): While Italian politicians are discussing the German model or the Spanish model, the French president is fucking an Italian model.

Erich Schubert's two posts about embedding spamtraps in web pages got me wondering about trying to track the web crawlers that harvest such addresses. If the pages that had the embedded spamtraps could be dynamically generated, it'd be interesting to generate email addresses that encoded the time of the crawl (well the page load I guess) and the IP address of the remote host. I expect that most of the harvesting is done by botnets, so it possibly wouldn't tell you a lot, but it'd be kind of cool to maintain a central blacklist of known harvesting IP addresses, that sites like mailing list archives could use to try and block the harvesters with.

I've spent the evening poking at the panel display that seemed to ship on some of the Philips Freevent desktops (some sort of abortive rebadging exercise). It's a TriGem part with a USB vendor ID of 0x0aa8 and product ID of 0xa001. It has four 7-segment numbers, a volume display and miscellaneous legend indicators. There's also some bizarre spinning circle thing that seems to be under programmatic control, but I haven't figured that bit out yet. It takes bulk writes of 16 bytes to endpoint 1, and the following format seems to be enough to drive the informational display.

The lack of any real free-form text support means it doesn't really fit into the LCDProc model, so I'm not really sure what to do with this. I'm sure I'll come up with something at some point. All the Windows driver does is cycle between showing hard drive space, memory and cpu frequency, though the hardware's obviously designed for showing the time as well (oddly, there's a separate clock at the top of it that works without a driver - I really don't think I want to know how that works). If anyone's got a similar device with a larger array of functionality, I'd be interested to hear if the remaining bytes do anything.

Bytes 0-7	Don't seem to do anything - perhaps on systems with more lights?
Byte 8	Bits 0-4: Volume lights 3-7
Byte 9	Bit 0: GHz light Bit 1: CPU light Bit 2: HDD light Bit 3: Mem light Bit 4: Mute light Bit 5: "Vol" light Bit 6-7: Volume lights 1-2
Bytes 10-13	Bit 0: Lower horizontal bar Bit 1: Left lower vertical bar Bit 2: Right lower vertical bar Bit 3: Middle horizontal bar Bit 4: Left upper vertical bar Bit 5: Right upper vertical bar Bit 6: Upper horizontal bar Bit 7: GB light (byte 10), colon light (byte 11), decimal point (byte 12), MB light (byte 13)
Byte 14	Doesn't seem to do anything
Byte 15	Must be 0x01

Hm, time for some nostalgia. The original Sim City game is now GPL'd under the new name Micropolis, and currently being packaged for Debian. There goes my 3.7 minutes of spare time per day... If you're into such games, the Lincity clone has been around for some time now, too. And, as I found out yesterday, there's also Lincity-NG, which is a more recent clone with better (3D/isometric) graphics, sound, etc.

$ apt-get install lincity-ng

(run it as lincity-ng --sdl if you don't have 3D-accelerated drivers) Have fun!

First I want to say shame on you for plain out laying. I had the laptop in service once, not twice. That was for the battery. The HDD is fine and I never had hardware issues with it. Now I am writing from that laptop, is that proof good enough for you?

Now I understand how rumors start.

What I don't understand what would motivate anyone to do this?

Oh, and you're welcome for the free advertising.

I've been a bit behind with the ISC DHCP v3 package of late. I've had a package of 3.1.0 for a few months, but I'm becoming more and more reluctant to make uploads of this package without giving it some rudimentary testing. Real life has been demanding of late, so I haven't had a chance to do that testing. Nothing's gone wrong with the package to date, I just feel negligent not giving it some basic testing before throwing it out there. So I chucked a spare QFE card in my workstation brutus, put unstable on the second hard drive, installed Debian unstable on the spare 10G partition of Sarah's old PowerBook, and lashed the two together with a bit of CAT-5, and voila, instant DHCP client/server testbed. So now that I'd verified that version 3.1.0 wasn't blatantly broken, I could have a fiddle with the new support for option 119 (domain-search) that has people at work very excited. I spent a bit of time off on a wild goose chase trying to figure out how to configure the DHCP server for this new option before I realised it was as simple as option domain-search "foo bar baz"; and then made the necessary tweaks to dhclient-script. I'm figuring that since one of the blokes who wrote the RFC works at Apple, and since Leopard supports option 119, the way they're doing it in Leopard must be approximately correct, so I've altered the behaviour of the DHCP client accordingly. All of this assumes you're not using resolvconf. Prior to 3.1.0, if you had the domain-name option set, the /etc/resolv.conf created by dhclient-script would set the search directive to the domain name. With 3.1.0, I've decided to make this set the domain option instead. The resolver behaviour remains the same, as best as I can determine. With 3.1.0, if the domain-search option is set, then the search directive is set to this. If the domain-name option is set, this is prepended to the list of domains in the domain-search option. This is consistent with what MacOS X 10.5 (Leopard) does. I'm not sure what Windows does (nor what version started honouring the domain-search DHCP option)), and since it doesn't have an /etc/resolv.conf equivalent, it's a bit hard to test. I'm going to hazard a guess and hope that since the other bloke who wrote the RFC works for Microsoft, that maybe, just maybe, Windows and MacOS X at least behave the same way. Currently, if resolvconf is in use, you get the old behaviour whereby the search directive is populated with the contents of the domain-name option, and the domain-search option is ignored completely. I've filed #460609 with a patch to fix this. Interestingly, resolvconf itself internally collapses the domain and search directives into the search directive of the /etc/resolv.conf it generates, so I can't quite get the same /etc/resolv.conf generated as would be generated without resolvconf being used. No big deal, the behaviour should be the same. The domain directive is largely unnecessary as I understand it. I have unearthed what I consider to be a bug with the domain-search option handling code in the client. It seems to be largely benign, apart from causing the client to emit some errors when it's obtaining a lease that contains the domain-search option, and possibly not splitting the domains in the domain-search option correctly. There's also another (I think unrelated) warning that gets emitted as well. I'm waiting to hear back from upstream about both. I'm not going to package the recently released 4.0 DHCP until I've figured out a transition plan to go from the old DHCP v2 packages to the v3 ones.