Ooops. When a room full of computer equipment gains a strong smell, there are a couple of possibilities (!) but the characteristic odour of singed electronics and lack of video output on one box is fairly indicative and all I could do was turn off the power on the UPS.

Definite smell associated with one box, smell gets worse when that box opened up, smell seems concentrated around the graphics card. Most weird is that the computer affected seems to restart ok at which point the smell reappears so knock the power off again - fast. Smell stays with the graphics card when card removed - it's surprising how long that smell hangs around. Remove graphics card, retest the machine - hang on - this sounds like a normal boot. Hmm - plugin the network cable, bingo - everything else appears to work - sans smell. Graphics card still has a strong odour even just sitting on the desk.

I've just suffered a graphics card burn out. Damn damn and double damn.

The machine itself is now running fine, just without a graphics card and thereby monitor. Accessing via ssh, dmesg shows the inevitable fsck but no other signs of harm except:
$ ps af
PID TTY STAT TIME COMMAND
3388 pts/0 Ss 0:00 -bash
3410 pts/0 R+ 0:00 \_ ps af
3256 tty7 Ss+ 0:00 /bin/sh /etc/gdm/XKeepsCrashing -noopen
3297 tty7 S+ 0:00 \_ /usr/bin/dialog --yesno Failed to start the X ser

$ sudo invoke-rc.d gdm stop



Why would an archive rebuild cause a graphics card to burn out? (I was running an autobuilder script but I don't run any screensaver on that box.)

Ah well, gives me an excuse to test the whiptail mode of emrecent and see if I can upload the packages that were built before the failure to Emdebian target. Another unexpected expense - 2008 is getting expensive!

After many long months of planning and work, I have completed another peer-to-peer downloader for Debian. If you've been keeping track, that makes 2 now. This one is called apt-p2p, and as of yesterday it is available in unstable. The functionality is very similar to the first one I wrote, DebTorrent, so if you've used that one you should feel very comfortable. After installation you just add a localhost:9977 to the start of your sources.list entries (see the man page). The only difference is the port number (DebTorrent uses 9988 by default) and that you can use it on all your sources.list entries, whether they be deb, deb-src, official Debian archive, or any other archive. Then an apt-get update gets it started, and you can begin installing packages. Point your web browser to http://localhost:9977 to see what's going on. IMPORTANT: as with any P2P program, it works much better if you open a port through your NAT or firewall. Without this crucial step, you won't be able to share with any peers, and your lookup of peers to download from may take longer. Make sure to forward both TCP and UDP ports 9977, or whichever port you set in the config file. For more details, see the port forwarding section of the FAQ. The similarities with DebTorrent are all external, so let's look at how it differs from DebTorrent internally:

• it's very general, it doesn't matter what you're trying to download, a source package or a Packages file, from constantly-updated unstable or a year-old stable, for i386 or hppa architectures (DebTorrent only works for .deb files, is only supported for the official archive, and breaks downloaders into groups by architectures)
• it doesn't require anything other than what's available to apt (DebTorrent uses piece hashes of large files, and ordering information, both of which are downloaded separately)
• it can be very fast when downloading from mirrors (mirror downloads with DebTorrent are not so fast)
• the code is simple, and makes use of available code, such as Twisted, Khashmir, and python-apt, which should make future enhancements and maintenance easier (DebTorrent is large and monolithic)
• requires less memory and CPU power (50% to 75% less memory than DebTorrent)

Here's some technical details for those interested:

• makes use of hashes to uniquely identify files
• uses a Distributed Hash Table (DHT) to find peers
• also stores piece hashes in the DHT for efficient downloading
• uses HTTP/1.1 requests to download from peers
• no peers available causes it to fallback to a download from the mirror

Though I know it can be fast, I'm not yet sure if the peer lookup in the DHT will be quick enough to keep up with the downloading. All my tests so far show that it is, but until there are a number of peers out there trying it, I can't be sure. Also, I have some improvements in mind to enhance the speed, in particular the wait for a timeout to occur, so this may improve in the future. If you see a delay in downloading where apt seems to be stalled saying 'Waiting for headers', for now be patient and see what happens. It may be that apt-p2p is downloading in the background (it does this sometimes), or that it's waiting for a lookup in the DHT to complete. If it hangs for more than a minute, or there's errors in the log file, please file a bug so that I can look into it. Finally, for you DebTorrent fans don't worry, I haven't given up on it. Stay tuned for more info on it coming soon.

Please note: Until your email address is validated, your email is NOT viewed
by any human and will not be read. I’m currentlty getting a bit of backscatter - a lot of bounces - and also quite a few of these challenge/response messages. I am especially tired of those challenge/response sender verification thingies and I so often considering actually responding just to annoy the implementers of such systems. But … what do you do ?

After months battling with the reverse cross build of gcc-4.3 to provide libgcc1 (1:4.3.0-3em1) arm , it's finally been uploaded, lintian clean. (emdebian-tools (>= 1.0.0) provides cross-building support in lintian.)

To handle this transition, previous Emdebian target packages have been migrated to Emdebian testing (the first time the target repository has had any testing packages) - the packages in testing are usable but the
perl 5.10 transition means that the root filesystem itself cannot be built from either set of packages. I'm taking advantage of this situation to allow temporary breakage of Emdebian-Target unstable as there are so many packages to be updated. I've now got a busy Bank Holiday uploading as many updated packages as possible, improving the emdebian-tools autobuilder em_autobuild, leading to the release of emdebian-tools 1.1.0.

Once done, I want to start preparing emdebian-tools 1.2.0 with a few 1.1.x releases aimed at extending autobuilder support to armel and i386 (i.e. native).

As part of the upload, I've also been able to fix the locale upload support and architecture-dependent TDebs are now available. See also http://www.emdebian.org/emdebian/langupdate.html and the locale search page.

People rarely ask me about my amazing ability to remove fruitfly ovaries in under 10 seconds. "This skill makes me strangely attracted to you" they then inevitably fail to add, thus giving the lie to claims that a PhD in biology is a great way to impress women. In order to avoid future social embarrassment I have therefore decided to provide a step-by-step guide to removing ovaries from any fruitflies you may have to hand.

• Feed your fruitflies. Fruitflies like yeast, so give them a pile to munch on. A well-fed fruitfly is a happy fruitfly.
• A happy fruitfly is a fertile fruitfly, and has bigger ovaries. Since fruitflies are small, this makes your job easier.
• Knock your fruitflies out with carbon dioxide. When doing this, ensure that you don't knock yourself out with carbon dioxide.
• Separate your fruitflies into male and female flies. Female flies have larger abdomens and striped posteriors - male ones are thinner and have solid black markings.
• Dispose of the males. They don't have ovaries. Local laws may make it awkward for you to release animals from laboratory environments, so dump them into a bottle of ethanol. They'll probably die happy, to the extent that fruitflies can really be happy.
• Etherise the female flies. When identifying ether, try not to do so by smelling it.
• Once the female flies are thoroughly dead, transfer one to a small watchglass containing a quantity of phosphate buffered saline with a small quantity of detergent in it. Place this under a low magnification microscope.
• Grip the neck of the fly with a set of needle-nosed tweezers. Grip the very rear of the fly with another set of needle-nosed tweezers.
• Slowly move the tweezers apart. If you are lucky, the abdomen will split and you'll start pulling out internal organs. If you're unlucky, the head will come off. In this case you should move the first set of tweezers further down the body and try again.
• Continue pulling out internal organs until you find two objects that look like bunches of bananas. These are the ovaries, with each "banana" being an egg chamber containing an egg and associated support cells.
• (If your fruitfly contains no ovaries, it's not a female. Try again)
• Carefully separate the ovaries from the other chunks of tissue that are stuck to them, and transfer the ovaries to a tube containing phosphate buffered saline.
• Repeat until you run out of flies. Note that towards the end, it will become tempting to just tear the flies into small pieces rather than removing their ovaries. Bear in mind that the aim is to obtain fruitfly ovaries, not to kill flies. There are much easier ways of doing the latter.
• Dispose of the remaining bits of flies in accordance with any relevant legislation. Do not throw remaining bits of flies at coworkers.
• Fix the ovaries in formaldehyde and suspend in methanol. Freeze at -20 C.

See? It's all very easy.

(Note: This protocol involves chemicals known by the state of California to cause cancer, birth defects and general fucked-upness. Do not ingest methanol unless you want to demonstrate competitive inhibition in the form of a bottle of vodka. Value of fruitfly ovaries may go up as well as down. Do not taunt fruitfly ovaries)

I made an emergency release of the chronicle blog compiler yesterday, after noticing that it was truncating titles containing periods. That was a bit of a mea-culpea moment, but I guess mistakes happen. The new release is in perfect shape for Lenny, and now includes two new scripts installed into the examples/ directory:

• The RSS-feed importer I mentioned prviously.
• A quick hack to detect duplicate post/entry titles.

The latter was applied to my own blog, and I discovered several duplicates. I guess my film quotes having only a limited source collection to work from could also include duplicates - so I've updated my Makefile to only build and rysnc my blog if there are none detected. (In many ways that films site is the precursor to this blog; it uses a collection of text files, one per film, and generates a cross-linked HTML output of film entries. Sadly it is out of date, because entering titles is a real pain..) Chronicle Comments

I'm pleased with the comment process now though, the CGI comment submission script simply archives each submitted comment into a "comments/" directory on the webserver. There a cron-job passes each one through a bayasian filter and moves the file(s) to either "comments/good/", "comments/bad/" or "comments/unsure/". When I come to rebuild the blog I rsync the "comments/good" directory to my local machine, rebuild and then rsync the output back to my remote webserver. (On a single machine this would be much simpler process!) I've imported my blog source into a mercurial repository, so the client-side is consistent. I have a bad habit of making new postings from wherever I happen to be and having a central repository will make that less prone to diaster. Just running "make steve" against the Makefile is sufficient to rebuild everything and sync it to my live system.

ObQuote: Kalifornia

As some of you might have noticed, I have uploaded a bunch of new packages to my experimental repository, all of them related to digital photographic workflow. Most of them are based on existing packages, but built from a VCS snapshot to benefit from newly supported hardware and new features.

• ufraw was updated to support my Sony DSLR-A700 camera - packaged based on the latest release available in sid.
• hugin package in unstable is outdated - I have based my package on Debian PhotoTools member Cyril Brulebois’s work. It seems that some legal questions have been raised, preventing the package to be updated in the official archive.
• autopano-sift fixes FTBS and other bugs in Christian Marillat’s package and proves working well with hugin. I will e-mail him a patch with the amendments I have worked on.
• enblend needs to be built from VCS to work with current hugin snapshots. The package is fully based on the package available in sid.

Though I use these packages on a regular basis, they haven’t been thoroughly tested as official packages would be, and might still contain bugs or errors. Please report any problem you might have. I will try and update these packages when time allows it. VCS snapshots might be unstable, or even non-usable. As usual, use these non-official packages on your own risk. Also note that these packages are currently only available for amd64. I will eventually build i386 packages if requested.

This Thursday, we did the largest part of the final phase of Stanford's Kerberos v5 migration. Our account services database system has now moved from Solaris to Debian, from Oracle to MySQL, and from Kerberos v4 to Kerberos v5. This has a lot to do with why I've been exhausted this week (I've worked over 50 hours and will probably do some more work this weekend). We're at the very end of a project that's been ten years in the making. Stanford first deployed Kerberos v4 in 1992 using the Transarc AFS kaserver as the KDC, with the full intention that it would be temporary until we moved to some Kerberos v5 implementation, probably Transarc DFS. Sixteen years later, we're finally turning off the OpenAFS kaservers and going to Kerberos v5 exclusively on May 15th. Various people at Stanford have been working on this project fairly continuously since the late 1990s, particularly Booker Bense and Roland Schemers (Roland has now moved on to other things). I started taking responsibility for it about five years ago and it became my major project three years ago when we finally got funding to finish it. It's the biggest project of my career to date. When we finally got funding and I was able to start working on it for a substantial percentage of my time, I went into the project with the intention to solve the large problem and do it right whenever possible. That meant trying to enhance the software where it was deficient rather than working around it, solving the large problem, and trying to improve the world and not just Stanford. Stanford University has been extremely supportive of that goal, and as a result, what's come out of the last three years is a bit staggering to look back on. I was feeling rather down earlier tonight, mostly because I'm exhausted. It's been a very intense past six months, a very tiring week, and I've not had the energy and attention for other things that are important to me. But I started thinking about everything that we've been able to do as part of this project and realizing just how big this is and managed to cheer myself up a lot. Five years from now, ten years from now, thirty years from now, this is still something that I'm going to be proud of. That's a great feeling. I was going to write up more specific details of how to tackle a project like this and do it right, listing some of the concrete results as examples, but yeah. Exhausted and low energy. Maybe I'll just do it over the next two weeks as a lead-up to May 15th. Immediately after that I'm going to the AFS and Kerberos Best Practices Workshop in part to talk about many of the things that we've written. And then, for the first time in three years, all of my major projects will be cleared and I'll have several months to catch up on everything else, recover, and gather my thoughts before deciding what the next big project will be.

Lets go on your nerves again with a ftpmaster post about work I’ve done in the recent past.

• The already mentioned move of britney. And it seems that this did help, so something that should have been done way earlier already… Oh well.
• Enabled a few triggers for the qa user on merkel. While I already mentioned them in my first post, there is a third one now. The qa user now gets notified at the beginning of the dinstall run, so the pages can show why packages might not be visible in the archive and in incoming right now.
• Split up the insanely huge mbox files we had as the ftpmaster mail archive. They got that big because the monthly cronjob rotating them got disabled when the ftp-master archive went away from raff, and noone bothered to reenable that job. Done now, so we are back to a manageable size. (Even if 90% of the content is spam, no matter how much greylisting and blacklists are activated :( ).
• Just committed a largish change thats nothing more than a cleanup. Someone in the past did love to not care about tab versus spaces for the indentation, so dak code ended up with a mess of tab/space mix for indentation. Which is not nice, one style is way better. Fixed that with the help of reindent.py, which one can find in Pythons examples.
• Got the code on security.debian.org to use the latest dak revision from ftpmaster. It was a few commits behind, but worse - it did have one dak tool changed in a way that it only worked on security, no longer on ftpmaster. Also some files that clearly have been copied by scp -r or rsync, but not using the VCS that should be used for it. Args. Brrrr. The “fix” was a simple check if that value the code wants to use from the config file actually exists, instead of blindly assuming it will always be there.
• Generally looked around on security.debian.org, to get more familiar with the setup there, so I can work on a request I got from some members of the security teams: Run a queue daemon that manages the upload of the packages from the security archive to the normal archive (so they end up in proposed-updates). Currently it is done with some lftp calls within the script that does the security install, and that seems to break every now and then. Which means security uploads to proposed-updates randomly go MIA. Using a queue daemon and then only locally copy files into its dir should make that way more reliable.
• Used a tool from Dato and enabled bzr commit mails for the ftpmaster dak tree, they are now going to the dak list.
• Modified the cronjobs that are expected to have output to log that into files in a new logdir. Also modified the cron.daily AKA dinstall cronjob to be more verbose about the actions done. The directory is synced to merkel too (log/cron in the ftp.debian.org tree), so every DD who wants to can look at them now.
• I also merged a small patch from Thomas, fixing/unifying some wording in reject messages.

Comments: 3

It has been a long time since i posted an entry. Many things have happened. Many things have changed. Let’s summarize them. I no longer live in Finland. I moved out on January the 29th, almost exactly by the day 8 and half years after I moved there. Right now I am in Dublin, Ireland, but you never know for how long. In any case I am enjoying quite much. Not as dark as Finland in winter, not as rainy as people think it is. Yeah, it rains, but it was rainy in Finland too. And here in not as cold. I no longer work for Nokia. My employer has changed and I am enjoying every single bit of it. I have not resigned from Debian, although I have not been active for the last months. If you add the new job (hiring process), moving and settling down, you could understand the lack of time. At least I can. Now things are getting stable (I got my ADSL connected only last weekend, and my server at home with all the mail redirected only yesterday) so I am ready to restart with my commitments. Also my employer will allow me to do some Debian work, so I only need my GPG key to be reinstated in the keyring (there is a ticket for it, so I just have to wait). And finally, if you want to follow where I have been spending some of my time, follow my flickr photostream.

Recently I had to deal with POST requests on mod_perl 2 on a custom XML-RPC webservice server we have been developing and maintaining over the last year (we are actually moving it to REST some time in the middle future). It was time to move some of our base modules from a couple of CGIs to the power and muscle of mod_perl. So, while dealing with POST requests (like XML-RPC is actually specified) I faced the issue that I wasn t being able to get the POST data on the PerlResponseHandler phase. I was probably not reading it correctly, I got deeply into it and even read some libapreq source code. All I was getting was some nifty message like not supported . After reading some documentation (and, to my own shame, the Apache2::Request front page pod) I found out that the usual:

    use Apache2::Request;
    $req = Apache2::Request->new($r);
    @foo = $req->param("foo");
    $bar = $req->args("bar");

will not work on your POST if the content type is different than application/x-www-form-urlencoded or multipart/form-data. For example, say, XML-RPC! So, in case you actually need to read POST data on your mod_perl 2 handler where it s not a form or a file upload, you can read the data manually (I didn t find a simpler way to read the data, actually):

sub handler  
my $r = shift;

return Apache2::Const::HTTP_BAD_REQUEST unless
		$r->method eq "POST" and
		$r->headers_in-> 'Content-Type'  eq 'text/xml' and
		$r->headers_in-> 'Content-Length' ;

my $length = $r->headers_in-> 'Content-Length' ;

my $xml;

while ($length)  
		$r->read($xml, ($length [less than symbol] 2048) ? $length : 2048);
		$length -= length($xml);
 

	...

And you are ready for booze.

So I wrote an entry on my tumblelog about what s going on with my life currently. Since Tumblr s feed doesn t get pushed immediately, I showed the post to my co-worker and friend Chris, before it hit the planets: - So, yeah I have my blog since it s syndicated on Planet Debian and other small feed aggregators -I said. - But do they really care about your bike, your chess games or you attending that conference? -he asked-, I mean, I do care, but people? - Well -I replied after a quick thought-, I think that s how personal blogs work. After a deeper thought I just realized that indeed no one cares and deleted the entry before it was pushed to the feed, updating it on FeedBurner, etc. It was a nice awakening.

---

But on a bit more interesting (for people) things, The Perl Foundation is currently requesting comments on the projects they received for grant requests. My proposal is there, Solidifying and Extending the Blog Normalize project . I do think there are some other more deeper projects, of course, but I think B::N is also an interesting one and the amount requested is not as big for other projects, so it d be nice to give it a try. I believe B::N is a good idea that could be enhanced nicely. I proposed the idea to the TextMotion developers yesterday on IRC (since that s one of the CMS there would be a connector for -as of the grant proposal-). After deeper discussion, CMSs will not make translators for a lot of projects into theirs, but B::N would, so maybe we could make some sort of webservice that CMSs could call on their installation phases. That, or the user at the end could actually do the conversion himself locally. Having the proper information, one could be able to get from TextMotion to Wordpress, to Blogger, to Joomla, to Tumblr, to MovableType and to TextMotion again, making a transparent circular transformation. Some of this is currently possible with the few code I ve written for it, currently in CPAN (and a bit deeper proof of concept); if you are interested, please leave your comments on the Perl Foundation blog entry. And review others too. At the end, I might end up doing the project myself, but if some money is granted to do so, why not apply to it, that d just speed it up.

I’m currently in Xen hell. My Thinkpad (which I won’t replace any time soon) has a Pentium-M CPU without PAE support. I think that Debian might re-introduce Xen support for CPUs without PAE in Lenny, but at the moment I have the choice of running without Xen or running an ancient kernel on my laptop. Due to this I’ve removed Xen from my laptop (I’m doing most of my development which needs Xen on servers anyway). Now I’ve just replaced my main home server. It was a Pentium-D 2.8GHz machine with 1.5G of RAM and a couple of 300G SATA disks in a RAID-1. Now it’s a Pentium E2160 1.8Ghz machine with 3G of RAM with the same disks. Incidentally Intel suck badly, they are producing CPUs with names that have no meaning, and most of their chipsets don’t support more than 4G of physical address space [1]. I wanted 4G of RAM but the machine I was offered only supported addressing 4G and 700M of that was used for PCI devices. For computation tasks it’s about the same speed as the old Pentium-D, but it has faster RAM access, more RAM, uses less power, and makes less noise. If I was going to a shop to buy something I probably would have chosen something different to get support for more than 4G of RAM, but as I got the replacement machine for free as a favor I’m not complaining! I expected that I could just install the new server and have things just work. There were some minor issues such as configuring X for the different video hardware (and installing the 915resolution package (which is only needed in Etch) to get the desired 1650×1400 resolution. But for the core server tasks I expected that I could just move the hard drives across and have it work. After the initial install the system crashed whenever I did any serious hard drive access from Dom0, the Dom0 kernel Oopsed and network access was cut off from the DomU’s (I’m not sure whether the DomU’s died but without any way of accessing them it doesn’t really matter much). As a test I installed the version of the Xen hypervisor from Unstable and it worked. But the Xen hypervisor from Unstable required the Xen tools from Unstable which also required the latest libc6, and therefore the entire Dom0 had to be upgraded. Then in an unfortunate accident unrelated to Xen (cryptsetup in Debian/Unstable warns you if you try to use a non-LUKS option on a device which has been used for LUKS and would have saved me) I lost the root filesystem before I finished the upgrade. So I did a fresh install of Debian/Unstable, this time it didn’t crash on heavy disk IO, instead it would lock up randomly when under no load. I’ve now booted a non-Xen kernel and it’s working well. But this situation is not acceptable long-term, a large part of the purpose of the machine is to run virtualisation so that I can test various programs under multiple distributions. I think that I will have to try some other virtualisation technologies. The idea of running KVM on real servers (ones that serve data to the Internet) doesn’t thrill me, Tavis Ormandy’s paper about potential ways of exploiting virtual machine technologies [2] is a compelling argument for para-virtualisation. Fortunately however my old Pentium-3 machines running Xen seem quite reliable (replacing both software and hardware is a lot of pain that I don’t want). In the near future I will rename the Xen category on my blog to Virtualisation. For older machines Xen is still working reasonably well, but for all new machines I expect that I will have to use something else - and I’ll be blogging about the new machines not the old. I expect that an increasing number of people will be moving away from Xen in the near future. It doesn’t seem to have the potential to give systems that are reliable when running on common hardware. Ulrich Drepper doesn’t have a high opinion of Xen [3], the more I learn about it the more I agree with Ulrich.

• [1] http://en.wikipedia.org/wiki/List_of_Intel_chipsets


• [2] http://taviso.decsystem.org/virtsec.pdf


• [3] http://udrepper.livejournal.com/tag/virtualization

Share This

I've learnt a lot about building MSI files during the last days. In a way, it is very similar to building Debian packages -- you hand some magic tool a directory with files and a directory with meta-information. The main difference is that MSI files cannot call arbitrary commands in their installation sequence, which serves an useful purpose: as long as they make do with the standard actions provided with the base installer, it is guaranteed that you can undo all changes, and you can get a full overview what the installation will do, without running any untrusted code. If the standard actions aren't enough (for example, they don't cover driver installation), you can ship a DLL that can be loaded into the installer. You lose a bit of the audit functionality there, but that is not a problem in practice as these plug-ins are signed separately from the package, so for every genuine problem, there is already a plug-in that you can simply "merge" to your package.

May 1st is a holiday in many countries around the world - It is, at least, here in Mexico. So, what's a man to do when faced with really-crappy network connectivity at home?
Yesterday I had dinner with Gigio, and among many other things, we talked about the Ciclot n, which I've only done twice. And on my way back home, I crossed (twice) the path of a group of ~100 cyclist going over Colonia Roma.
Anyway, whatever the reason, I woke up very well in the mood for a nice 20km ride:

Now, lets get the day started!
[update] I was told about a worldwide nudist cycling activity, the World Naked Bike Ride. Their page states their main motivator:

We face automobile traffic with our naked bodies as the best way of defending our dignit and exposing the unique dangers faced by cyclists and pedestrians as well as the negative consequences we all face due to dependence on oil, and other forms of non-renewable energy.

Of course, Mexican groups take part in this interesting activity - Ciclomarcha nudista.
Will I be there? I don't know - Quite probably, yes. I first thought of it as a joke, and as a dangerous activity. But, come think of it, I am a move-by-bicycle-in-the-largest-city-in-the-world activist. I have been knocked over or shit-scared (and fortunately not more than that) by careless drivers, but than won't force me back into driving my car when not needed. And this kind of activities, which do get their good share of exposure, need all the participants - I hope to be there, June 7 12:00PM, at the beginning of Mexico City Ciclopista (FFCC de Cuernavaca esq. Ej rcito nacional, Polanco) Chapultepec's Lions' entrance, at the crossing of Lieja and Reforma.

Share the awareness. There are very good promotional pictures. And collective nudist activities are quite fun, experiences to remember for life.

Audit your debian uploads My bank is sending me an e-mail every time I log into the home banking system, so that I can spot malicious logins. My credit card is sending me a SMS message every time it gets charged, so that I can spot mailicious charges. Can I get a notification of every Debian upload done with my key, so that I can spot if my key has been stolen? Let's work on that. As a start, thanks to Ganneff, here is how to do a one-off audit:

# go to merkel to access projectb, which is the postgresql database
# with all dak information
$ ssh merkel
merkel$ psql projectb
# look up the database id of my fingerprint
projectb=> select id, fingerprint from fingerprint where fingerprint like '%797EBFAB';
 id                  fingerprint                
    -----+------------------------------------------
     394   66B4DFB68CB24EBBD8650BC4F4B4B0CC797EBFAB
    (1 row)
# get a list of all uploads done with my key, sorted by date
projectb=> select * from source where sig_fpr=394 order by install_date desc;

First you get to do it (done); then you document it (done); then you automate it. It's quite trivial at this point, so enjoy the new Debian upload monitor. It's got search as you type to find your full fingerprint, then you get an HTML page with the log of your uploads in the last 2 months, and the page has an RSS feed that you can use to track your own uploads. Also, generating all this static content is acceptably fast:

merkel$ time ./deb-key-audit 
real    0m7.145s
user    0m4.244s
sys 0m0.384s

If you want to see the code, you can git clone http://merkel.debian.org/~enrico/keylog.git Currently it wrongly encodes UTF-8 characters: I suppose the strings come out of the database as ASCII instead of UTF-8. A patch would be welcome to fix that. I will now contact QA to see what we can do with it; if it ends up fitting in some bigger picture then it may be that the RSS links will change, but I'll post about it in that case.

As I just had the need to split up two huge mbox files by date and did not find a tool that does that easily, I thought I share what I used. Careful, it isn’t very clever, so if you use it: It comes with NO WARRANTY at all. If it eats your mail, you lost. Not my fault, you have been warned. The task it should solve reads

• split files of size 1.8Gb and 3.2Gb, all together nearly a million mails in them,
• do not use lots of memory for this,
• no need to interactively do anything,
• split based on Date: header.

There are various ways to do it, one would be to use mutt, with something similar to the following in a muttrc file somewhere

 unset confirmcreate
 set delete=yes
 set folder=/dev/null

and then a lot of lines looking similar to the following, just replacing the dates;

folder-hook . 'push "T~d01/03/2008-31/03/2008\n;s2008-03.mbox\n$%q"'

If you then start mutt using mutt -F theabovemuttrc -f themboxfiletosplit it will go and split it into the YEAR-MONTH based files. I got this way from Gerfried Fuchs, as I am no mutt user and wouldn’t have found the way to do it with mutt myself. Drawback: Mutt needs exact date entries in the push lines. Means you have to write 29/02 if you mean “last day of Februar”, a plain stupid 31/02 will be converted to 02/03. And I was way too lazy to list all the dates for the timeframe those mboxes cover. So, other solution. Ruby to the rescue! The following code does split the mbox into the files I want, based on the date header:

#!/usr/bin/ruby -w
# Split a mbox file into $year-$month files
# Copyright (C) 2008 Joerg Jaspert 
# BSD style license, on Debian see /usr/share/common-licenses/BSD
require 'pathname'
require 'rmail'
count = 0
File.open(Pathname.new(ARGV[0]), 'r') do  mbox 
  RMail::Mailbox.parse_mbox(mbox) do  raw 
    count += 1
    print "# count  mails\n"
    begin
      File.open(RMail::Parser.read(raw).header.date.strftime("split/mail-%y%m"), 'a') do  out 
        out.print(raw)
      end
    rescue NoMethodError
      print "Couldn't parse date header, ignoring broken spam mail\n"
    end
  end
end

This will go through the whole mbox and store them in split/mail-$year$ month files. It has a few things you should keep in mind, if you really want to use it:

• Spam mails often have a very broken Date header. Sometimes broken enough that it can’t be parsed. I discard the “can’t be parsed” ones, as I havent seen a valid mail with that. You might want to store it in a different file, so change the part within rescue.
• Again, Spam mails often have a very broken Date header. So you will get files for years way in the past or future. In my case I could simply delete all of them, as all of those had been spam, and I knew in which timeframe the good mails got into the mbox.

The above script took, niced down with nice -15 on an otherwise used server, about 25 minutes to split around one million mails from the above mentioned large files, with no noticable memory usage (only one mail at a time in memory). Comments: 5

There are situations where you might want to redirect some audio you're playing on your local computer to another computer's speakers, potentially in a different room, or even anywhere on the Internet. One of many possibilities to do that is to use the Enlightened Sound Daemon (EsoundD, or esd). It ships with a program called esddsp (apt-get install esound-clients) which can redirect various audio sources. First, you have to start the esd daemon on a console on the remote host (the one which should output the audio on some speaker, for example 192.168.0.xxx) e.g. like this:

  $ esd -public -nobeeps -tcp

You can do this as regular user (no need to be root) if you have the proper permissions. You also need to allow connections on port 16001 in your firewall settings. Then you can redirect audio to that daemon from another computer. In this example I'm redirecting some music using various players:

  $ esddsp -s 192.168.0.xxx:16001 mpg321 -o esd foo.mp3
  $ esddsp -s 192.168.0.xxx:16001 mplayer -ao esd foo.mp3
  $ esddsp -s 192.168.0.xxx:16001 ogg123 -d esd foo.ogg

This also works fine for videos, in which case you can redirect the audio (but not video):

  $ esddsp -s 192.168.0.xxx:16001 mplayer -ao esd foo.mp4

For the video player Miro, I've recently documented this in the Debian package's README.Debian file. Basically you have to edit ~/.xine/config and enable audio.driver:esd there, then start Miro with

  $ esddsp -s 192.168.0.xxx:16001 miro

Audio will be emitted on the remote host, video remains on your local PC. Some programs may also support esd natively, in which case esddsp is not required, e.g.

  $ ogg123 -d esd -o host:192.168.0.14:16001 foo.ogg

Boston offers slim pickings for vegetarian fine-dining options in the financial district. Most nice places have some sort of pasta dish and not much else. I have forgotten several times, but now write this blog entry to permanently remember, that Radius at 8 High Street is an excellent choice for vegetarians. Although almost nothing vegetarian appears on the menu, you can just tell the waiter that you are vegetarian (along with any other restrictions), and the chef will prepare a plate of three unique fancy concoctions. I’ve had lunch with other vegetarians, and each of us got three entirely different creative and delicious dishes. They were complex enough that I won’t attempt to describe them here. I’m not sure how they chose who got what, but we were all pleased. Of course, dessert is always vegetarian: Excuse the quality; this is a low-light low-resolution image taken by cell phone. It was called “Butter Cake” but went well beyond the humble title. Those specks around the outside are dried grapefruit. Technorati Tags: Vegetarian, Boston, Restaurants, Radius

Share This