Tomorrow, all being well, I'll receive a new computer. I've always run Debian unstable upon my desktop in the past, partly because I wanted to have "new stuff" and partly because I needed a Debian unstable system for building Debian packages with. However I'm strongly tempted to just install Lenny. I use that upon my work desktop and it does me just fine for surfing, building tools, and similar. I can use pbuilder, sbuildd, or similar to build packages for upload to Debian, and if I want to experiment with new-hotness I can use a KVM guest or two. Providing the hardware works with Lenny (and I have no reason to believe it won't) then there's no obvious downside I can think of. The only potential complication will be restoring my backups, it is possible that my firefox databases, and similar things, might not work on older version. Still we shall see. I plan to install software RAID, and run the system on LVM because quite frankly it rocks. Unless my current system fails in the next 24 hours I can use that to do the installation (My current desktop acts as a TFTP/DHCP/NFS server so I can use it to PXE-boot). Anyway now I need to go eat food, tidy my desk, and decide what to call the machine .. At the moment the choice is between "march.my.flat" and birthday.my.flat, as my 34th birthday is on March 10th. ObFilm: 300

Every year, at least one person asks me to run for DPL. I don't remember quite when this started, but it was more than five years ago. I have some standard responses: I don't have time to do a good job, and why commit if you know you can't do a good job? That's just irresponsible. Usually I get some feeble relativism back for that one. Oddly enough, this is the one year that I could actually make the time for it, but it is still not a good idea. Also I do not wish to self-nominate. I am told that everyone is too autistic to understand why, so I assume that by observing the timing of nominations (in specific, who stands at the beginning of the nomination period and who waits until close to the last minute), no moro-ethical conclusions will be drawn. To belabor this point: if the culture of self-nomination were fixed, I would actually nominate people I think would do a good job. At present, I cannot, and I resent that. Furthermore, you do not really want me as DPL. There are oodles and oodles of things I think are fundamentally flawed and I would try to fix them. I would not take advice from predecessors because I think that only perpetuates years of flawed DPL behavior. I would not entertain requests in private because there is far, far, far too much backroom discussion right now, and unfortunately it is actively encouraged and promoted by many people in power. Such departures would be extremely unpopular. I would be pleased if Stefano runs unopposed. I think that there is a good chance he will do a decent job.

Well my last post elicited a response from Mr Lougher the squashfs author. Just not one I was expecting. Apparently he did receive one of my emails (I sent five in total) to which he has not replied as I have accidentally come across as critical.

Temporarily disabling file caching Does it happen to you that you cp a big, big file (say, similar in order of magnitude to the amount of RAM) and the system becomes rather unusable? It looks like Linux is saying "let's cache this", and as you copy it will try to free more and more ram in order to cache the big file you're copying. In the end, all the RAM is full with file data that you are not going to need. This varies according to how /proc/sys/vm/swappiness is set. I learnt about posix_fadvise and I tried to play with it. The result is this preloadable library that hooks into open(2) and fadvises everything as POSIX_FADV_DONTNEED. It is all rather awkward. fadvise in that way will discard existing cache pages if the file is already cached, which is too much. Ideally one would like to say "don't cache this because of me" without stepping on the feet of other system activities. Also, I found I need to also hook into write(2) and run fadvise after every single write, because you can't fadvise a file to be written in its entirety, unless you pass fadvise the file size in advance. But the size of the output file cannot be known by the preloaded library, so meh. So, now I can run: nocache cp bigfile someplace/ without trashing the existing caches. I can also run nocache tar zxf foo.tar.gz and so on. I wish, of course, that there were no need to do so in the first place. Here is the nocache library source code, for reference:

/*
 * nocache - LD_PRELOAD library to fadvise written files to not be cached
 *
 * Copyright (C) 2009--2010 Enrico Zini <enrico@enricozini.org>
 *
 * This program is free software; you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation; either version 2 of the License, or
 * (at your option) any later version.
 *
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 * GNU General Public License for more details.
 *
 * You should have received a copy of the GNU General Public License
 * along with this program; if not, write to the Free Software
 * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
 */
#define _XOPEN_SOURCE 600
#include <fcntl.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <dlfcn.h>
#include <stdarg.h>
#include <errno.h>
#include <stdio.h>
typedef int (*open_t)(const char*, int, ...);
typedef int (*write_t)(int fd, const void *buf, size_t count);
int open(const char *pathname, int flags, ...)
 
    static open_t func = 0;
    int res;
    if (!func)
        func = (open_t)dlsym(RTLD_NEXT, "open");
    // Note: I wanted to add O_DIRECT, but it imposes restriction on buffer
    // alignment
    if (flags & O_CREAT)
     
        va_list ap;
        va_start(ap, flags);
        mode_t mode = va_arg(ap, mode_t);
        res = func(pathname, flags, mode);
        va_end(ap);
      else
        res = func(pathname, flags);
    if (res >= 0)
     
        int saved_errno = errno;
        int z = posix_fadvise(res, 0, 0, POSIX_FADV_DONTNEED);
        if (z != 0) fprintf(stderr, "Cannot fadvise on %s: %m\n", pathname);
        errno = saved_errno;
     
    return res;
 
int write(int fd, const void *buf, size_t count)
 
    static write_t func = 0;
    int res;
    if (!func)
        func = (write_t)dlsym(RTLD_NEXT, "write");
    res = func(fd, buf, count);
    if (res > 0)
     
        int saved_errno = errno;
        int z = posix_fadvise(fd, 0, 0, POSIX_FADV_DONTNEED);
        if (z != 0) fprintf(stderr, "Cannot fadvise during write: %m\n");
        errno = saved_errno;
     
    return res;
 

Updates Steve Schnepp writes:

Robert Love did a O_STREAMING patch for 2.4. It wasn't merged in 2.6 since POSIX_FADV_NOREUSE should be used instead. But unfortunatly it's currently mapped either as WILLNEED or as a noop. It seems that there is a google code project that has spawned to control this.

The Threat Bruce Schneier s blog post about the Mariposa Botnet has an interesting discussion in the comments about how to make a secure system [1]. Note that the threat is considered to be remote attackers, that means viruses and trojan horses which includes infected files run from USB devices (IE you aren t safe just because you aren t on the Internet). The threat we are considering is not people who can replace hardware in the computer (people who have physical access to it which includes people who have access to where it is located or who are employed to repair it). This is the most common case, the risk involved in stealing a typical PC is far greater than the whatever benefit might be obtained from the data on it a typical computer user is at risk of theft only for the resale value of a second-hand computer. So the question is, how do can we most effectively use free software to protect against such threats? The first restriction is that the hardware in common use is cheap and has little special functionality for security. Systems that have a TPM seem unlikely to provide a useful benefit due to the TPM being designed more for Digital Restrictions Management than for protecting the user and due to TPM not being widely enough used. The BIOS and the Bootloader It seems that the first thing that is needed is a BIOS that is reliable. If an attacker manages to replace the BIOS then it could do exciting things like modifying the code of the kernel at boot time. It seems quite plausible for the real-mode boot loader code to be run in a VM86 session and to then have it s memory modified before it starts switches to protected mode. Every BIOS update is a potential attack. Coreboot replaces the default PC BIOS, it initialises the basic hardware and then executes an OS kernel or boot loader [2] (the Coreboot Wikipedia page has a good summary). The hardest part of the system startup process is initialising the hardware, Coreboot has that solved for 213 different motherboards. If engineers were allowed to freely design hardware without interference then probably a significant portion of the computers in the market would have a little switch to disable the write line for the flash BIOS. I heard a rumor that in the days of 286 systems a vendor of a secure OS shipped a scalpel to disable the hardware ability to leave protected mode, cutting a track on the motherboard is probably still an option. Usually once a system is working you don t want to upgrade the BIOS. One of the payloads for Coreboot is GRUB. The Grub Feature Requests page has as it s first entry Option to check signatures of the bootchain up to the cryptsetup/luksOpen: MBR, grub partition, kernel, initramfs [3]. Presumably this would allow a GPG signature to be checked so that a kernel and initrd would only be used if they came from a known good source. With this feature we could only boot a known good kernel. How to run User Space The next issue is how to run the user-space. There has been no shortage of Linux kernel exploits and I think it s reasonable to assume that there will continue to be a large number of exploits. Some of the kernel flaws will be known by the bad guys for some time before there are patches, some of them will have patches which don t get applied as quickly as desired. I think we have to assume that the Linux kernel will be compromised. Therefore the regular user applications can t be run against a kernel that has direct hardware access. It seems to me that the best way to go is to have the Linux kernel run in a virtual environment such as Xen or KVM. That means you have a hypervisor (Xen+Linux or Linux+KVM+QEMU) that controls the hardware and creates the environment for the OS image that the user interacts with. The hypervisor could create multiple virtual machines for different levels of data in a similar manner to the NSA NetTop project, not that this is really a required part of solving the general secure Internet terminal problem but as it would be a tiny bit of extra work you might as well do it. One problem with using a hypervisor is that the video hardware tends to want to use features such as bus-mastering to give best performance. Apparently KVM has IOMMU support so it should be possible to grant a virtual machine enough hardware access to run 3D graphics at full speed without allowing it to break free. Maintaining the Virtual Machine Image Google has a good design for the ChromiumOS in terms of security [4]. They are using CGroups [5] to control access to device nodes in jails, RAM, CPU time, and other resources. They also have some intrusion detection which can prompt a user to perform a hardware reset. Some of the features would need to be implemented in a different manner for a full desktop system but most of the Google design features would work well. For an OS running in a virtual machine when an intrusion is detected it would be best to have the hypervisor receive a message by some defined interface (maybe a line of text printed on the console ) and then terminate and restart the virtual machine. Dumping the entire address space of the virtual machine would be a good idea too, with typical RAM sizes at around 4G for laptops and desktops and typical storage sizes at around 200G for laptops and 2T for new desktops it should be easy to store a few dumps in case they are needed. The amount of data received by a typical ADSL link is not that great. Apart from the occasional big thing (like downloading a movie or listening to Internet radio for a long time) most data transfers are from casual web browsing which doesn t involve that much data. A hypervisor could potentially store the last few gigabytes of data that were received which would then permit forensic analysis if the virtual machine was believed to be compromised. With cheap SATA disks in excess of 1TB it would be conceivable to store the last few years of data transfer (with downloaded movies excluded) but such long-term storage would probably involve risks that would outweigh the rewards, probably storing no more than 24 hours of data would be best. Finally in terms of applying updates and installing new software the only way to do this would be via the hypervisor as you don t want any part of the virtual machine to be able to write to it s data files or programs. So if the user selects to install a new application then the request please install application X would have to be passed to the hypervisor. After the application is installed a reboot of the virtual machine would be needed to apply the change. This is a common experience for mobile phones (where you even have to reboot if the telco changes some of their network settings) and it s something that MS-Windows users have become used to but it would get a negative reaction from the more skilled Linux users. Would this be Accepted? The question is, if we built this would people want to use it? The NetTop functionality of having two OSs interchangeable on the one desktop would attract some people. But most users don t desire greater security and would find some reason to avoid this. They would claim that it lowered the performance (even for aspects of performance where benchmarks revealed no difference) and claim that they don t need it. At this time it seems that computer security isn t regarded as a big enough problem for users. It seems that the same people who will avoid catching a train because one mugging made it to the TV news will happily keep using insecure computers in spite of the huge number of cases of fraud that are reported all the time.

• [1] http://www.schneier.com/blog/archives/2010/03/mariposa_botnet.html
• [2] http://www.coreboot.org/Welcome_to_coreboot
• [3] http://grub.enbug.org/FeatureRequests
• [4] http://sites.google.com/a/chromium.org/dev/chromium-os/chromiumos-design-docs/system-hardening
• [5] http://lxr.linux.no/linux+v2.6.30/Documentation/cgroups/

I've made a quick release of dh-make, now up to 0.52. Besides a minor dh_make.1 manual page fix this release will put the right value in the debian/source/format file. 0.51 will make it a native source package no matter what flags you use.

If you get weird lintian errors about native source formats and version numbers wrong on your brand-new Debian package you just made, you might of been bitten by this bug.

That leaves a few bugs left, there are two I need help with:

• Bug 328692 - If you have a plan ASCII name like me, then your name looks fine in the dh-make generated man pages. This bug requires converting names that aren't plain ASCII (e.g. that use UTF-8) into something groff understands. Someone suggested decomposed unicode but unicode and groff are pretty much a black art to me, let alone combining them.
• Bug 533117 - This one is all about making dh-make make your python packages. You'll need to understand the new debhelper v7 rules files. Again, python is not something I use so the bug is stuck here.
  

Related articles by Zemanta

• UTF-8: Bits, Bytes, and Benefits (research.swtch.com)

In a comment on my post Shared Objects and Big Applications about memlockd [1] mic said that they use memlockd to lock the entire root filesystem in RAM. Here is a table showing my history of desktop computers with the amounts of RAM, disk capacity, and CPU power available. All systems better than a 386-33 are laptops a laptop has been my primary desktop system for the last 12 years. The columns for the maximum RAM and disk are the amounts that I could reasonably afford if I used a desktop PC instead of a laptop and used the best available technology of the day I m basing disk capacity on having four hard drives (the maximum that can be installed in a typical PC without extra power cables and drive controller cards) and running RAID-5. For the machines before 2000 I base the maximum disk capacity on not using RAID as Linux software RAID used to not be that good (lack of online rebuild for starters) and hardware RAID options have always been too expensive or too lame for my use.

Year	CPU	RAM	Disk	Maximum RAM	Maximum Disk
1988	286-12	4M	70M	4M	70M
1993	386-33	16M	200M	16M	200M
1998	Pentium-M 233	96M	3G	128M	6G
1999	Pentium-2 400	256M	6G	512M	40G
2000	Pentium-2 600	384M	10G	512M	150G
2003	Pentium-M 1700	768M	60G	2048M	400G
2009	Pentium-M 1700	1536M	100G	8192M	4500G
2010	Core 2 Duo T7500 2200	5120M	100G	8192M	6000G

The above graph shows how the modern RAM capacities have overtaken older disk capacities. So it seems that a viable option on modern systems is to load everything that you need to run into RAM. Locking it there will save spinning up the hard drive on a laptop. With a modern laptop it should be possible to lock most of the hard drive contents that are regularly used (IE the applications) into RAM and run with /home on a SD flash storage device. Then the hard drive would only need to be used if something uncommon was accessed or if something large (like a movie) was needed. It also shows that there is potential to run diskless workstations that copy the entire contents of their root filesystem when they boot so that they can run independently of the server and only access the server for /home. Note that the size of the RAM doesn t need to be larger than the disk capacity of older machines (some of the disk was used for swap, /home, etc). But when it is larger it makes it clear that the disk doesn t need to be accessed for routine storage needs. I generated the graph with GnuPlot [2], the configuration files I used are in the directory that contains the images and the command used was gnuplot command.txt . I find the GnuPlot documentation to be difficult to use so I hope that this example will be useful for other people who need to produce basic graphs I m not using 1% of the GnuPlot functionality.

• [1] http://etbe.coker.com.au/2009/12/19/shared-objects-and-big-applications/
• [2] http://www.gnuplot.info/

I must confess I don't remember who I got this invitation from. Anyway, if you are in the right geographic area, you might be interested. I will try to participate: This is a year-long seminar that will be held the second Thursday every month at Fonoteca Nacional (a place I have wanted to visit for a long time!), in Barrio de Santa Catarina, Coyoac n. Among the organizers they have Creative Commons Mexico. Free entrance (but limited space - so they ask interested people to confirm their presence by mail to bvallarta@conaculta.gob.mx). [update] I went with Pooka to the first session. We arrived almost 1hr late (due to me mistaking the schedule :-/ ) but it was interesting. Of course, quite biased towards the Google viewpoints, but interesting. We got the program for the next sessions So, mostly for myself to keep handy, here it goes:

Date	Title	Speakers
2010-03-11	Google and copyright	Manuel Tamez, Hugo Contreras, Mar a Fernanda Mendoza
2010-04-08	Generalities about rights on intelectual property	Jes s Parets, Guillermo Sol rzano, Jorge Mier y Concha
2010-05-13	Copyright's nature and competent authorites	Carmen Arteaga, Luis Schmidt, C sar Callejas
2010-06-10	Moral and patrimonial rights	Guillermo Pous, Eduardo de la Parra, Ram n Ob n
2010-07-08	Reproduction rights for audible material	lvaro Hegewisch, scar Javier Solorio, Marco Antonio Morales, Jos Ram n C rdeno
2010-08-12	Licenses and patrimonial right transmission. Works for hire, works done under laboral relationship, or carried out in official service	Dolores Franco, Jes s Mej a, Ra l Pastor
2010-09-09	Limits to explotation rights and literary plagiarism	Carmen Arteaga, Juan Ram n Ob n, Jorge Mier y Concha, C sar Callejas
2010-10-14	Copyright in a digital setting	Jes s Parets, Gast n Esquivel
2010-11-11	Law-regulated intelectual property rights	Rosalba Elizalde, Salvador Ortega, Gast n Esquivel, Manrique Moheno
2010-12-09	International protection and collective gestive societies	Horacio Rangel, Luis Schmidt, Jes s Mej a

Before I forget: I have a bunch of files I mirror between Windows/NTFS and Linux/ext4 filesystems that include not only accented characters but curly quotes in the filenames. (I know: the easiest solution would be to just get rid of the extended characters). The curly quotes were created in Windows, so don t render properly in standard Linux character sets (UTF-8, iso8859-1, iso8859-15, etc.). This all came up because iTunes under Windows couldn t find curly-quote files when it was reading from the exported Samba share filesystem rather than an attached NTFS drive. The files showed up as missing because they had different filenames. The solution was not easily google-able, so for the record, in brief, add this to the [Global] section of /etc/samba/smb.conf:

unix charset = cp1252
display charset = cp1252

And reload Samba. Also, to make the characters render properly from a terminal on the Linux box, first create the relevant character set:

sudo localedef -f CP1252 -i en_US en_US.CP1252

Now you can use this charset on your Linux box, and, like magic, the curly characters will be back:

export LC_ALL='en_US.cp1252'

Contrary to what lucas announced (I don t know where he got this info), we plan to release Squeeze with eglibc 2.11. It is already packaged in experimental and is ready on all architectures except hppa where there are a few major regressions in the testsuite to fix. This is what prevent us to upload it to unstable.

Almost nothing interesting happened recently in X.org in Debian. But interesting things are coming soon.
First, radeon KMS and DRI2 will enter unstable soon. xserver-xorg-video-radeon 1:6.12.191-1 is currently in experimental. People seem to be happy with it so far, and upstream is taking very good care of bug reports as usual. The next 2.6.32 kernel will contain DRM from 2.6.33. It first means that the radeon KMS driver not in staging anymore. Once this new kernel is uploaded, I'll put the new xserver-xorg-video-radeon in unstable (6.13.0 is expected soon, but 6.12.191 already looks good so far). DRM from 2.6.33 will also brings nouveau support. It means that we will build libdrm-nouveau and upload a new xserver-xorg-video-nouveau. However, it also means that we need somebody to maintain this. And nobody in the team has a nvidia board to test packages so... If you want nouveau in Debian, please help.
While waiting for all these, we have been triaging the BTS a bit. Kibi is helping a lot by triaging recent intel bugs (many regressions fixed in recent kernels). I spent some time during the week-end triaging some old bugs. I closed more than a hundred of them, and pinged another hundred. We still have more than 1100 bugs open. It is not so bad compared to 1500-2000 when nobody maintains X (aka often), but still way too much. Some of my bug closing might look a bit rude. But we had so many bug reports a couple years ago that are irrelevant today. Keeping them open would be meaningless. For instance, many input problems are obsolete since a lot of the input code was rewritten, we switched to input-hotplug, and then hal to udev. Another example is intel lockups (we had a lot of them after driver 2.2 arrived). But XAA and EXA were dropped in favor of UXA, DRI1 was dropped for DRI2, and KMS arrived. So it's useless to keep these obsolete and irrelevant bugs that cannot be debugged nowadays.
As usual, the Debian X team needs a lot of help. Again, if you want nouveau in Debian, please help.

After a long time of testing and just plain other non-software writing stuff, I'm happy to announce Gjay 0.3.0 is released. This is my first release of Chuck Groom's code and hopefully it will work for you too.

The Debian packages will be out shortly after some building and testing. If you have a 64-bit computer it now works with 64 bits fine (ie on my amd64).

It still needs some work, I'd like it to interact with more than audacious as the sound player. Also if you know how to in one of the sound libraries stream wav, ogg or mp3 files correctly I'd like to hear from you. Currently gjay just uses the same old fork to mpg321 method, but idealy I'd like it to use the libraries directly.

I've decided to take part in the 2010 Seven Day Roguelike Challenge My entry will be written in JavaScript as a KDE4 plasmoid (thus simultaneously allowing me to take part in this competition) Unfortunately today had to be spent in RL family activities so I'm already behind. however I've done lots of research into Roguelike development and I have accomplished the first step finding a name. Candidates are:

• Descent into the No-No Area
• Going Rogue
• Battle For Quiznosth
• Tol-in-Gaurhoth

...and the winner is:

• A Lively Fisting

It will be a simple combat heavy coffeebreak game inspired by things such as Solo Dungeon Bash and Pocket Dungeon though as time permits I will add as many more roguelike features as I can.

I finally got a few hours free this morning to check an item off my home system administration checklist: upgrading the wireless router's firmware to OpenWRT. There were a couple motivations for this, including the fact that my SoundBridge Radio couldn't maintain a connection to my firefly server using the built-in firmware, and I had read that OpenWRT would work better. Since this is posted on Planet Debian, I should mention why I didn't use DebianWRT. The basic answer is this text at the top of the DebianWRT homepage:

Currently the most common methods used to run Debian on these systems is to install OpenWRT or a similar firmware, add disk space either by USB storage or NFS, create a debian chroot by either running cdebootstrap from inside OpenWRT or debootstrap --foreign on a PC, and running Debian from this chroot. For example, instructions for the WLHDD.

I'm not sure whether this is because DebianWRT is experimental, or because its goal is to use routers as cheap general computers. Either way, it sounds way too complicated and/or fragile for what I'm interested in (i.e., a wireless router with better software). The goal here is to get something that does a better job than the built-in WRT firmware, but doesn't require too much tinkering to get working or to maintain. I have plenty of outlets for my tinkering urges already. Nothing here was exactly difficult, but it was hard to find all the information I needed to get things working. Hopefully documenting the steps I went through here will save someone else some time. Step 1: acquire the firmware This was trickier than you might think. If you click on the download link at the OpenWRT web site, you end up at the top of an FTP server populated with a vast quantity of stuff. Worse, when you find the actual firmware images, you'll quickly discover that there are piles and piles of them divided between sixteen directories, and no guidance as to which one to pick. And picking the wrong one will turn your beautiful router into a doorstop. Luckily, the OpenWRT documentation contains a section called "Getting Started". Unluckily, that section consists of the following text:

1.1 Getting started 1.1.1 Installation 1.1.2 Initial configuration 1.1.3 Failsafe mode

Whoops, someone forgot to execute on a TODO. Undeterred, I consulted the usual fallback reference, Google. It pointed me at several references, some of which were hidden on other parts of the OpenWRT site. Armed with these, I was able to determine that:

1. My WRT54GL v1.1 probably uses a Broadcom 5352 chipset.
2. The correct firmware, according to multiple sources, is probably in the kamikaze top-level director, the latest version's subdirectory, and the bcrm-2.4 directory under the version (the link is to 8.09.2, which is current as of March 6, 2010). Apparently the bcrm47xx directory doesn't have wireless support; it helpfully contains a file called NO-BROADCOM-WIRELESS to warn you off, but unhelpfully doesn't include any additional information in that file (like what exactly is broken or that you can find a working firmware in a sibling directory) ... oh well.
3. The firmware file that you want is openwrt-wrt54g-squashfs.bin, even though it doesn't match the model number of the router. This directory could use a README file explaining which hardware is supported by each of the dozen or so firmware files it contains.

Step 2: install the firmware After Step 1, this was a real relief. I just used the built-in Linksys firmware installer, pointed it at the .bin file, and it went. Step 3: configure the router The installation guide I followed was pretty much silent about what to do after I got the firmware on. Luckily, this is just a software problem, meaning it's much more familiar territory for me.

1. First things first: I checked that I could still get a DHCP lease. It worked.
2. Armed with that, I tried telneting to the router. I used the resulting root prompt to set a password on the root account.
3. I logged out and tried telneting in. Apparently the router is configured to disallow root logins over telnet if you don't have a password. Good for them (although why allow telnet at all?); oops for me.
4. Luckily, an ssh server was installed by default. I like using keys to log in, so I tracked down the documentation on configuring the server to use public-key authentication; it turns out there's a single global key file named /etc/dropbear/authorized_keys that's exactly like OpenSSH's per-user authorized_keys file. No idea what would happen if I had multiple users, but I won't.
5. The next obstacle: I didn't have an Internet connection. For some reason, my cable modem didn't want to give the router a DHCP lease. On the off-chance that it was remembering too much, I rebooted it and ran ifup wan. That fixed the problem. I still don't know why.
6. Not a step, but a useful note: in the process of figuring the above out, I found readlog. It's basically dmesg for syslog files; it shows the most recent lines written to syslog. This is useful because there isn't a real syslog file, due to the fact that there would be no room to store it on the 54GL.
7. Finally, I had to get wireless working. The documentation is very helpful when it comes to describing the syntax of the wireless configuration. Unfortunately, I read the list of encryption options and missed the section right below where their meanings are explained (although, to be honest, I might not have understood the implications of the explanation without the research I did anyway).

   option encryption none, wep, psk, psk2, wpa, wpa2

   I wanted WPA2 encryption, so I entered wpa2. And nothing worked. After a good hour of trying different options on the client, swapping software components in and out on the router, experimenting with the encryption key syntax, and crawling Google, I finally found my answer. If you just want WPA2 encryption, you must not use wpa2 as the encryption type. Instead, use psk2. It turns out out that wpa2 actually means use WPA2 and also use an external RADIUS server for authentication. psk2 is the system you're familiar with from a typical consumer wireless router.

Step 4: enjoy And with that, it works. Unfortunately, contrary to what I wrote here originally, my Roku still doesn't work. On the other hand, having a real Linux installation is helpful for debugging it. Currently my suspicion is that the router isn't passing multicast packets between the wired and wireless interfaces (broadcast works fine, multicast doesn't). That said, it seems like if I restart Firefly just before I start playing music, I can play reasonably reliably -- as long as I don't stop, because if I do, the Roku forgets that the music server is there. Either way, I've spent about as much time fighting this as I can afford. One lingering worry I have is security; unlike Debian, which has both a security mailing list and tools to inform me when I need to install a security update, the OpenWRT firmware doesn't seem to have any mechanism for distributing security notices. True, there is an openwrt-security-announce list, but it appears to be entirely unused, as is openwrt-announce. Something to keep an eye on, then. Also (file under note to self), I need to remember to verify that the router isn't exposing services to the outside world. The default iptables configuration is hideously complex; with just a quick glance, it could be setting up a floral shop for all I can tell. I'll need to test this empirically and maybe analyze the rules in more depth.

Quite surprisingly, I ll attend the Chemnitzer Linuxtage 2010 in Eastern Germany. This is a happenstance, I managed to get fast transportation (via my boss) and accomodation (in a hotel). I will try to help staffing the booth of Debian this time (so I cannot be called Traitor any longer). Schedule, due to the spontaneousness of this, no, though. I may not even be there on Sunday, dunno No RCBD (or night) though, some real life and a new release (with fix of an FTBFS-on-hurd-i386 bug) though:
RMD160 (/MirOS/dist/mir/makefs/makefs-20100306.tar.gz) = f65bd8ef5cf3306a9112587dd4915b6255e479fe
This version pulls in NetBSD changes (Acorn Archimedes support, for one), but I ve also coded support for boot-info-table (J rg compatible), as well as setting the PVD dates (used by GNU GRUB 2 for UUID s). On MirBSD, cdio(1) can now be used to burn (TAO) and blank (quick) CD-RW media (I backported some OpenBSD changes) too.

I've got a few fixes to go into drivel 3.0.1 but I've been trying to decide on whether to re-factor the underlying code - libsoup specifically. Drivel has it's own way of handling xmlrpc messages and this method doesn't work well with the libsoup2.4 changes, so currently it backports some code from libsoup2.2. This isn't ideal for all the usual reasons and I've been waiting for time to sort it out.

Time is lacking. My change of career has dramatically changed the amount of time I have for upstream code and as long as drivel continues working for most people, I'm not sure how much time it deserves.

I've done a lot of refactoring in drivel already, for the GTK3 transition mainly, but this libsoup stuff is much more awkward because it raises new bugs with each blog engine that drivel tries to support. It's not helped when some blog engines retain broken XML practices that mean that the standard libsoup2.4 support simply fails to post a message with properties. (I'm looking at you livejournal.com).

Anyone fancy helping out with a branch where the old xmlrpc code can be replaced by soup_value_hash_insert? I've made an SVN branch for soup24 changes at SourceForge. There's a mailing list too (v.quiet).

I'm going to update a few screenshots, complete a few more tests and then release 3.0.1.

OCaml Batteries Included 1.1.0 has arrived in Debian I've just uploaded the Debian package of OCaml Batteries Included 1.1.0 to the Debian unstable archive; hopefully, it will quickly enter testing to be released with the next Debian stable release. This is the first release in Debian of the "new generation" of Batteries Included, which has followed a strict diet, and now has Camomile as its only external dependency. It took me a while to package it due to an intertwining transition to OCaml 3.11.2 (during which we have fleshed out the last remaining few bits of transition to our new dependency system). Also, I had to fix some typical build issue with upstream, which kindly coordinated with me to have the fixes included in 1.1.0. So go, enjoy Batteries 1.1.0, and let me know your feedback:

    # apt-get install ocaml-batteries-included

(check that it will install 1.1.0 though, it might take a few days to hit your favorite architecture and mirror) Tip: starting from this version you will need the following to use Batteries in place of the legacy standard library in your sources:

    open Batteries_uni

for multi-threaded programs you should rather use open Batteries. Check the FAQ file installed under /usr/share/doc/libbatteries-ocaml-dev/ for more quick start information.

You have a gitolite install on host $MASTER, and you want a mirror on $SLAVE. Here is one way to do that. $CLIENT is your workstation, that need not be the same as $MASTER or $SLAVE.

1. On $CLIENT, install gitolite on $SLAVE. It is ok to re-use your gitolite admin key here, but make sure you have both public and private key in .ssh, or confusion ensues. Note that when gitolite asks you to double check the "host gitolite" ssh stanza, you probably want to change hostname to $SLAVE, at least temporarily (if not, at least the checkout of the gitolite-admin repo will fail) You may want to copy .gitolite.rc from $MASTER when gitolite fires up an editor.
2. On $CLIENT copy the "gitolite" stanza of .ssh/config to gitolite-mirror to a stanza called e.g. gitolite-slave fix the hostname of the gitolite stanza so it points to $MASTER again.
3. On $MASTER, as gitolite user, make passphraseless ssh-key. Probably you should call it something like 'mirror'
4. Still on $MASTER. Add a stanza like the following to $gitolite_user/.ssh/config

    host gitolite-mirror
      hostname $SLAVE
      identityfile ~/.ssh/mirror
   

   run ssh gitolite-mirror at least once to test and set up any "know_hosts" file.
5. On $CLIENT change directory to a checkout of gitolite admin from $MASTER. Make sure it is up to date with respect origin

   git pull
   

6. Edit .git/config (or, in very recent git, use git remote seturl --push --add) so that remote origin looks like

   fetch = +refs/heads/*:refs/remotes/origin/*
   url = gitolite:gitolite-admin
   pushurl = gitolite:gitolite-admin
   pushurl = gitolite-slave:gitolite-admin
   

7. Add a stanza

   repo @all
     RW+     = mirror
   

   to the bottom of your gitolite.conf Add mirror.pub to keydir.
8. Now overwrite the gitolite-admin repo on $SLAVE git push -f Note that empty repos will be created on $SLAVE for every repo on $MASTER.
9. The following one line post-update hook to any repos you want mirrored (see the gitolite documentation for how to automate this) You should not modify the post update hook of the gitolite-admin repo. git push --mirror gitolite-mirror:$GL_REPO.git
10. Create repos as per normal in the gitolite-admin/conf/gitolite.conf. If you have set the auto post-update hook installation, then each repo will be mirrored. You should only push to $MASTER; any changes pushed to $SLAVE will be overwritten.

Yay! The ticket is ready, and the long trip is getting closer. Long trip? Won't most Debianers have a longer trip than me this time? Nope, not by far My University will be on vacations starting July 3, and it is three weeks before DebConf... So I will be travelling Southwards before :-) Details will follow later. Suffice to say that I am more than happy to announce that... I am definitively going to DebConf10!

(Cross-posted from the OpenHatch blog.) I remember working on my first big group programming project back in college. The project involved some web scraping work; I enthusiastically took charge of that part. But a few weeks in, my code just wasn t working. I felt frustrated and helpless I m supposed to be the scraping expert, so why couldn t I fix the problems? I retreated into hiding and didn t want to think about the group of people or the project. A week later, I feebly ran svn update to see how the project had progressed. Oh! I exclaimed to myself. Someone made the data importer work! I felt a rush of relief. (While writing this paragraph, I sighed again remembering it.) When I talked to my teammate George, he mentioned off-handedly that he had fixed it. He didn t feel any of the anguish I felt or assign me the blame I thought I deserved. I guess if I had just asked for help earlier, I could have skipped the feelings of inadequacy entirely and George would have just fixed the bug. Half a decade later, I feel the same dread about the lack of Maildir support in Alpine. The bug is three years old! Ugh. This time, I m going to ask for help. So I listed the issue on the Alpine project page on OpenHatch. To put it there, here s what I did:

• I logged into OpenHatch and added Alpine to my list of projects.
• I followed the link on my profile to the Alpine project page.
• I answered the last question, What is a bug or issue with Alpine that you ve been putting off, neglecting, or just plain avoiding?

For those of you who work on Free Software projects, what are the issues that drain you the same way? No bug tracker I ve seen has a field that says, I m avoiding working on this, and that sucks. To say that, list the issue on your project s OpenHatch page. So join in! What are the issues you don t want to think about? Once you share them, maybe a fellow developer or a new contributor will come by and help you out. Head to OpenHatch and let the world know. P.S. Do you have any ideas about how we can make these project pages more useful? Let us know! P.P.S. Dear Joey Hess and everyone else, sorry that Alpine still doesn t have Maildir support.