FOSDEM is a 2-day weekend of insanity. 218 talks this year; if you want to understand exactly how insane that is, have a look at the schedule grid. There are 19 rooms where events are held; possibly more, since I understand not every devroom has sent in its schedule yet. Might be hard for people to make a choice that way, I guess. Now there're supposed to be abstracts of each talk on the FOSDEM website, but reading them all can be quite tedius. In an effort to help, at least for the Debian devroom, here's the schedule for our devroom with a bit of explanation of what it's about. Note that this is mainly aimed at people not familiar with Debian; those who are should probably understand it enough by looking at the titles. Saturday: 13:00 - 14:00: 'Outside broadcast on a budget - the DebConf video team and DVswitch'. DVswitch is the software used to create those excellent Debian videos. The best ones yet, IMO, are the ones of Debconf8. Check them out. There's nothing Debian-specific about DVswitch, except that it was written by Debian people. It's a great way to do live Internet .ogg streaming by using nothing more than DV cams, Firewire, and plain old Ethernet. 14:00 - 15:00: 'Ultimate Debian Database: datamining Debian made easy!'. UDD is a SQL database containing a shitload of data related to Debian, and which should allow easy datamining. Hence the title. This probably won't be of any interest to people who are not either a Debian Developer or a statistician, but I might be mistaken. 15:00 - 16:00: 'Introducing DDE, Debian Data Export'. This is a new project Enrico came up with, and which is related to the same subject as the previous talk. I don't know much more beyond what's in the abstract. However, given the fact that Enrico is going to be doing this talk, it can't be bad. Seriously. 16:00 - 17:00: 'The Debian status quo on the Openmoko Neo Freerunner'. Yup, Debian runs on the OpenMoko, and has done so since Debconf8, last august. This talk should give some more insight; if you have an OpenMoko, this definately is for you. 17:00 - 17:30: 'Running Debian on Inexpensive Network Storage Devices'. I've been running Debian on a Thecus N2100 for a few years now, and it's great. There are more options, however, and Martin does most of the hard work related to these devices. He's done a similar talk on the two previous FOSDEMs (go check out the videos), and this one will mainly be an update on what's going to be new in Lenny. 17:30 - 18:15: 'Grid Computing with Debian, Globus and ARC'. These guys are a group of academics from three different universities who've been doing grid computing (i.e., something like 'SETI@Home', but then somewhat different) with Debian and some other technologies. They'll be explaining how, exactly. I don't know much about this talk; it could be great, or it could fail miserably. I guess we'll see. 18:15 - 19:00: 'What does the DPL do?'. This is really firmly targetted at Debian people. If you're not in the least interested in how Debian does things, you'll be bored. Sunday 09:15 - 10:00: 'The state of Virtualization in Debian'. If you're a Debian user interested in virtualization, this talk is for you. Henning will explain what virtualization options exist in the upcoming 'Lenny' release, and how to use them. 10:00 - 11:00: 'TDebs'. This might not be too interesting to you unless you happen to be involved in Debian infrastructure. TDebs don't exist yet, but will sometime soon; Neil will be explaining how, why, and what. 11:00 - 12:00: 'Internationalization in Debian: How to improve further?' If you're interested in i18n, this is probably for you. 12:00 - 13:00: 'The Common Debian Build System (CDBS)'. CDBS is one way to build a Debian package. This is probably only of interest to Debian people. 13:00 - 14:00: 'Release management in Debian - can we do better?'. Frans isn't a member of the release team, but has some criticism on how they function. He intends to present his arguments in order to start a discussion. This is Debian internal kitchery, really. 14:00 - 15:00: 'Lenny - the road to release'. Neil is a member of the release team, and is going to explain how we got to the current state. I hope he'll also explain why we still haven't released. I guess we'll see :-) 15:00 - 16:00: 'The long road to KDE4 in Debian'. Um, yeah. I'm not a KDE guy, but I understand some other people are. In any case, might be an interesting talk even if you don't use Debian, since I understand it will look at some of the new features in KDE (and how they relate to packaging). 16:00 - 17:00: 'Debian and Google Summer of Code 2008: wrap-up and insights'. I guess Leslie will be there. The speaker was a student working on Debian during this year's SoC, and he will present what's been accomplished. There, that's it. Now my only hope is that there'll be many people attending. If previous editions are any indication, however, that won't be a problem.

Bernhard comes up with a few arguments in support of multiple filesystems which, in my arrogant opinion, make no sense. The first argument (about hardlinking a file to your homedirectory until something bad is discovered in one of the binaries) has been sufficiently debunked by Joey Hess. The second and third arguments are the same, really. Repeating your argument won't buy you any beer, sorry. Finally, all your arguments talk about server. I was talking about laptop. I don't know about you, but me, I'm not in the habit of loaning out my laptop to someone I don't trust. I'm not even in the habit of loaning out my laptop to someone I do trust, come to think of it. I do run some servers on my laptop, but I also have a firewall on my laptop that refuses incoming connections. This is a laptop. Not a machine in a data center. As such, the only person with access to my machine is me. Now I don't say I trust each and every bit of software that I run on my laptop, but I do trust myself. I won't start scanning my laptop's hard disk for rogue SetUID hardlinks in another user's home directory, because there isn't another user, stupid! Paranoid security is nice and dandy and totally useless. Security is all about trade-offs. Even Bruce says so: if the cost of a security measure (having to deal with with 73 filesystems) does not outweigh its benefit (protection against cosmic rays changing not only my firewall configuration, but also writing a suid CGI binary and installing that in /usr/lib/cgi-bin), then it's just not worth it. Now of course you might argue that 'having to deal with 73 filesystems' is no cost at all, in which case it would be worth it. But to me, it certainly is a cost, and one I'm not willing to take even if it did protect me against a real-life problem. And if someone were to break into my system, I'll just reformat it and recover from back-ups. I won't even have to revoke my GPG key, this time, since it's no longer on the disk.

I'm managing to do enough work on Lintian each week that it's still making sense to stick with a weekly release cycle. So a new Saturday, a new Lintian release. This one was mostly a set of random bug fixes and a few new, easy tests, cleaning up some false positives and lowering the bug count. We're now firmly under 100 bugs, which always makes me happy. The new test suite is also taking further shape, although I didn't do quite as much work on it this week. I expect the next release to be 2.2.0 and incorporate support for a --pedantic option, contributed by Raphael Geissert. This will be a new tag severity less even than wishlist. It's for style checks, checks that are highly likely to have false positives, things that might be cleaner but are unimportant, etc. People should only use --pendantic if they're willing to see tags that are inaccurate or don't fit their personal style and take them with a grain of salt. There are a bunch of long-standing bugs requesting checks of that sort that are often easy to implement, just not things we've implemented in the past because even at the info level they'd annoy too many people. I'm hoping to do a few more infrastructure changes and library changes for the next release as well, but I'll see how much time I have.

It s been quite the day. This evening, Jacob had a new first. He requested I read him an owner s manual for his bedtime story. Yes, I m sure years from now, he will still remember how to operate a Motorola W376g cell phone. He had found the manual in its box and had been carrying it around, reading it to himself for days already. I can feel him following in my footsteps - I remember pulling the car manual out of the glove box on long trips and reading it. For fun. So yes, Jacob chose an owner s manual over nice children s bedtime books involving caterpillars. This morning, I set out on what would be a 43-mile bike ride - home to Wichita. It was about 28F when I left. I had been wanting to ride from home to Wichita for some time now, and finally found the right day. The wind was at my back (mostly), the sun was shining (I even got burned a bit), and the ride was fun. It took me about 4.5 hours, including the 1.5 hours I spent for lunch and other breaks. I didn t take a completely direct route, but that was intentional. This is my second-farthest ride in a day, behind the time I rode 55 miles in a day for charity. But it is the farthest I ve gone in winter. I was taking the bike to the bike shop for its free 6-month tuneup. So I even had the perfect excuse to ride it. I hope to ride it back home if the weather is cooperative. As for the third milestone, while I was riding to Wichita, Barack Obama and Joe Biden were riding a train to Washington. I recorded it, and have been watching it this evening. Remembering all they said during the campaign, seeing how they act it really does give me some hope in this country s government, some hope that some important things will be accomplished in the future. One TV commentator pointed out that the Bush administration carefully avoided using the word recession as long as they possibly could, while Obama is trying as hard he can to be straight and direct with people about the situation. I appreciate that. What a milestone the next few days represent for the country.

Situation You have a bunch of Flash videos, FLV files. Every once in a while you dump new files on your publicly accessible Apache directory. You would like to give your users the ability to play those FLVs within a webpage you provide, instead of just serving them the files for a direct download. Maybe you want this for all FLVs, not only an specific directory. Solution Apache2::EmbedFLV!

<Files ~ "\.flv$">
  SetHandler modperl
  PerlResponseHandler Apache2::EmbedFLV
</Files>

So now, all your FLV files will be served through Apache2::EmbedFLV on mod_perl with a neat interface you can define yourself, and using the very nice and GPL ed Flowplayer. Apache2::EmbedFLV uses a default template, but you can define your own with:

<Files ~ "\.flv$">
  SetHandler modperl
  PerlSetVar template /path/to/your/template.tt
  PerlResponseHandler Apache2::EmbedFLV
</Files>

Also, Apache2::EmbedFLV expects to find Flowplayer (flowplayer.swf and flowplayer.controls.swf) on http://your.server.com/flowplayer.swf, the root of your server. So you can do something like this to make it work:

Alias /flowplayer.swf /home/web/flowplayer/flowplayer.swf
Alias /flowplayer.controls.swf /home/web/flowplayer/flowplayer.controls.swf

Or, you just define the flowplayer variable:

<Files ~ "\.flv$">
  SetHandler modperl
  # relative to the document root
  PerlSetVar flowplayer /swf/flowplayer.swf
  # or absolute:
  PerlSetVar flowplayer http://my.other.server/was/hacked/flowplayer.swf
  PerlResponseHandler Apache2::EmbedFLV
</Files>

Action! You can see it in action at http://axiombox.com/apache2-embedflv/flv. This Radiohead video is particularly cool Getting it

• More information at its homepage, http://axiombox.com/apache2-embedflv
• CPAN module.
• Git repository, as usual, on GitHub.

UPDATE: Oops! Fixed link to Flowplayer s website! flowplayer.org. Thanks to those who noticed and let me knew.

Various people have been taken in by a pretend Debian installer/bootloader for the android G1 phone. What is it, really? Well, it's a 200+ mb zip file, containing a filesystem image of a Debian installation. About 100 mb of that is cached .debs in /var. A few minor changes have been made, and /root/.bash_history helpfully shows what was done. None of it seems to be malicious, but I did not check every file. Also included is a hilarious "boot loader" script that contains literally the following code:

echo "Custom Linux Pseudo Bootstrapper V1.0 - by Mark Walker"
echo "WEB: http://www.androidfanatic.com/"
echo "EML: admin@androidfanatic.com"
echo " "
sleep 1
echo "Starting init process"
sleep 1
echo "INIT: Debian booting....."
sleep 1
echo "Running Linux Kernel"
sysctl -w net.ipv4.ip_forward=1
sleep 1
echo "AutoMounter started"
sleep 1
echo "Type EXIT to end session"
echo "Make sure you do a proper EXIT for a clean kill of Debian!"
echo " "
chroot $mnt /bin/bash

That's worth the price of admission right there! I especially like how "init" is "started" before the "kernel". You can't make stuff like this up. So, in summary, this is a way to get a prebuilt Debian chroot at the expends of wasting bandwidth and space on your phone with unncessary bits. Running debootstrap on the phone is the correct way to accomplish the same thing. It's sad that there's such interest for Debian on the G1, and general lack of clue, that people will actually probably use this. And, like it or not, this "is" the Debian install for the G1 -- no further efforts are likely to get this kind of press. Sorta like that badly pressed CD back in the day stole the thunder of Debian 1.0. More generally, it's a pity that when people want to get Debian on a new device, be it the G1 phone or the EEE or OpenMoko or what have you; only about half of them seem to do it right, by modifying d-i and sending the modifications back to the installer team. For this rest, this kind of hand-built, unverifyable chroot gimmeckery is the de facto standard. This also shows you the kind of fact checking that slashdot and random blogs tend to do -- ie, none. (My own blog, of course, is rigorously fact-checked and edited by armies of lolcats.) (Sorry, this seems to be my week for posting corrections to other people's posts to Planet Debian. I don't mean to pick on you guys.)

Continuing with my mission to control the power to some dumb USB-powered lights... Dann Frazier confirmed my theory that a USB hub would indeed do the job. I'd already found the hub-ctrl.c program he mentioned, but couldn't get it to work with my built-in USB ports of my laptop. It seems it all depends on whether the hub will support per-port power switching or not. (lsusb -v will tell you). So off to the mighty institution that is Fry's Electronics I went. The first two attempts failed, as did a borrowed hub. It seems most (at least the cheap one) use a Genesys Logic chipset, which does not support per-port power control. Fortunately I chose products that weren't in blister packs, so I was able to return them to Fry's in as-new condition and try again. Now that I knew USB hubs would do the trick, I did some more targeted searching, and found this thread where someone had been messing around with hubs to do what sounded like what I wanted. (Incidentally, this email in the thread also provided a nice looking Python program. I'm going to look at refitting it to use the "real" Python USB module.) I emailed the poster to ask him what brand of hub he was using. The answer was the Linksys 4-port hub So I managed to track down one of them last night. Yes, it works, but the downside is the hub itself requires external power, which is a bit unfortunate. Not only do I need to use a hub to make these lights software controllable, I have to plug the hub into a power outlet. Bleh.

I ve migrated pommed to git yesterday. The public URLs for the git repository are: git://git.debian.org/git/pommed/pommed.git
http://git.debian.org/git/pommed/pommed.git The SVN repository will disappear shortly.

The phrase on this title is often attributed to Pancho Villa (1878-1923), Mexican Revolution leader. He had a fame of cruelty, killing suspects before even questioning them.
Today, it started as a very nice day. I had even time in the morning to find, fix, upload and send upstream a trivial bug in libgruff-ruby... At 11:00, I left the Institute as my father came to the city to do some paperwork... We sat having a cup of coffee in a restaurant near the office we had went to at around 12:00, and my phone rang.
And it was from work. That's never a good sign. My boss told me he was facing a massive virus infection, and decided to disconnect the firewall. I corrected him - that will do no good once the virus is in our system, if you want to disconnect anything, disconnect all of our switches.
Came back, and found him and my coworker stunned and not knowing what to do. He says, the antivirus alarm went off almost simultaneously on the two computers he had on his desk, and in few minutes over 15 computers all over the Institute were ill. The symptoms? Programs not showing up in the taskbar, copy/paste functionality b0rken, many programs misbehaved or just didn't open... They were grimly facing a complete recovery operation they have grown used to: The whole OS has become corrupted or destroyed, we will have to open the computer, extract the HD, install it elsewhere, back it up, reinstall OS and applications, restore the backup. Yes, I know too many extra steps are included here, but I have come to accept their ways of dealing with Windows. Nobody says dealing with Windows is fun. I like my work to be fun, so I stay clear of theirs.
I insisted on turning back one one of the switches, the one for the servers and my machine (and some more in the same physical area). OK'd. But they didn't want to switch on any other switch, so a traffic capture (tcpdump / wireshark) led nowhere - but at least it gave my my Google back.
They have configured the antivirus software we deploy to all of the Windows machines in such a way that it deletes upon sight any malware - And when they manually scan, they blindly hit Delete whenever anything is found as well. Of course, no infected binary was left alive for me to inspect, and the machines were dead. But I was able to glimpse at the name of the deleted file: rpcss.dll.
After googling a bit - Bliss! Joy! I found the answer. So here is the set of interactions, and how they led to this killing spree. Please remember I am a Windows newbie and speak just out of guesswork.

1. This is a fast-spreading virus. My friend Rub n at DGSCA suggest it might be related to this report submitted today; at Barrapunto there is a thread about another virus that appeared four days ago, infected 1.1 million Windows machines on its first day, and so far is around the ninth million. Update: Equivalent thread at Slashdot, for the Spanish-impaired.
2. The virus infects at least two copies of a system binary: %system32%\rpcss.dll and \Windows\ServicePackFiles\i386\rpcss.dll. Windows uses the second one to restore the first one in case it is damaged, if I understood correctly.
3. The antivirus does not detect the infection when the library files are written, but when they are linked, so it only spots it the next time %system32%\rpcss.dll is brought into memory.
4. This is a very common library - It takes care of, well, RPC. So, quite probably, this file will be linked again on the next program launch - or accessed when a running program requires anything not currently in RAM? Dunno. The thing is, the library gets linked.
5. The antivirus will happily tell you it has killed a threat! Your nice RPC library is now defunct. M talo, luego virig as!
6. So, of course, notifying the taskbar of a new window appearing, or clipboard actions, or whatnot will refuse to work.
7. Machine restart, full system scan requested. The antivirus finds de second copy of this library in the master directory (\Windows\ServicePackFiles\i386). The virus used this location so that Windows won't restore a clean version over it. But yes, it will fall again under the claws of the antivirus... I guess. Anyway, the antivirus offers to delete this file as well, and does so.
8. User is desperate. My coworkers are desperate. I am... mildly annoyed?

Once I found this line of thought... I went to a working machine, inserted my flash memory, and copied %system32%\rpcss.dll to it. Went back to a sick machine, and ran cmd. Then, it was just matter of copy f:\rpcss.dll c:\windows\system32, a simple reboot (it never hurts to reboot in Windows!), and problem solved!
Oh, as a side rant: I find it extremely annoying and sad that many people I know, sometimes with more experience as a computer operator/supporter than what I have of experience as a living human being, are so scared of using a command-line interface. They were dismayed at seeing no drag-and-drop and no copy/paste functionality were available! copy is not an option.
Anyway... Today was an experience on how a simple, mostly-harmless and quite-fertile virus is able to be terribly magnified by the presence of a trigger-happy antivirus.
Why won't they give themselves a chance to try something else? Say, GNU/Linux? :-/

From: Christoph Berg <myon@debian.org>
To: Debian Bugs Submit <submit@bugs.debian.org>
Subject: Bug#512072: RFH: mutt -- text-based mailreader supporting MIME, GPG, PGP and threading
Package: wnpp

Hi, the Debian Mutt package needs more maintainers. There are almost 200 open bugs. Some of these are already forwarded upstream and might just need some triaging/poking. Some need forwarding. Some might be fixed with a trivial patch. Others are Debian specific, mostly for the extra patches we include. There's duplicates and sub-wishlist items. We are using bts-link to link to dev.mutt.org's trac, but that also needs more tweaking. There's a new upstream version 1.5.19 pending, we need people to check which bugs still apply. The (in?)famous mutt-patched package needs love to get the sidebar patch updated to the new version, and to get some of mutt-ng's extra gimmicks and add-ons integrated. I've moved packaging to git since that seems to be the least scary choice nowadays: http://git.debian.org/?p=pkg-mutt/mutt.git The repository has been updated to 1.5.19. The mutt-patched build is disabled for now, as the patch doesn't apply. Testers welcome :) If you are interested in helping out, please get in contact with me. To get started, subscribe to mutt's PTS feed. There's no extra maintainer mailinglist, mailing mutt@packages.debian.org will work for PTS subscribers. If you prefer IRC, join #mutt on irc.freenode.net. Thanks,
Christoph

After another week, new Gammu testing version is out. The biggest change is integration of python-gammu into Gammu. This makes easier to test everything together and new tests revealed lot of bugs and memory leaks which were immediately fixed. Besides these changes, Windows Service support has been fixed and added possibility to run more SMSD instances.

• Fixed setting remote number for SMS in some cases.
• Fixed compilation under cygwin.
• Externalize eventlog support to ease Cygwin compilation.
• Integrate python-gammu into Gammu, they are anyway bound quite tightly together.
• Python C module is now gammu._gammu and not gammu.Core.
• Introduce testing for python module.
• Fixed decoding of formatted EMS messages.
• Fixed reading of RTTL ringtones.
• Fixed crash with too many animation frames.
• Fixed possible crash in LMB writer.
• Fixed several memory leaks.
• Better support for Samsung phones (bug #790).
• Fixed Windows Service Startup (bug #451).
• New possibility to run more instances of Windows Service (bug #451).

You can download from usual place: http://cihar.com/gammu/, Debian users will find packages in experimental soon.

I am happy to announce general availability of darcs 2.2.0. Getting the release For this release, we have decided to provide two flavours, depending on the build system used:

1. The source tarball, http://www.darcs.net/darcs-2.2.0.tar.gz, which can be built using the traditional autoconf-based system. This is the fully supported version. After downloading and unpacking, you can issue:

   $ ./configure
   $ make
   

   and possibly

   # make install
   

   More detailed instructions inside the tarball (file README). Please note that we had at least one report of build failure, with quickcheck-related message. The currently best workaround, if this happens to you, is to use the cabal version of the package instead, see below.
2. Cabalised source. You can either download a tarball from http://hackage.haskell.org/packages/archive/darcs/2.2.0/darcs-2.2.0.tar.gz and build manually (see the build instructions in README inside the tarball), or, alternatively, you can use cabal-install to obtain a copy:

   $ cabal update
   $ cabal install darcs
   

   This will give you a darcs binary in ~/.cabal/bin you should probably add that to your PATH.

In addition to source tarballs, we expect binary packages for various UNIX platforms will be available in due time. For Windows users, Salvatore Insalaco has prepared a binary build, available from http://homepage.mac.com/kirby81_it/darcs/darcs-2.2.0-win1.zip. You just need to unpack the directory somewhere and add it to your path (if you like). Moreover, an experimental TortoiseDarcs release for darcs 2 has been made available by Kari Hoijarvi and is looking for home. It can be found at http://datafed.net/darcs (unfortunately, at the time of this writing, the site seemed unreachable If you can help with hosting, please mail Kari.) What s New The summary of changes since version 2.1.2 (released last November) follows:

• In interactive record, it is now possible to get a list of currently selected hunks (command l). (Christian Kellermann)
• It is now possible to specify --in-reply-to when using darcs send, to generate correct references in the mail header. (Pavel Shramov)
• New repositories with --no-pristine-tree can no longer be created. This only has effect on legacy darcs-1 repositories.
• Improvements in Windows support. (Salvatore Insalaco)
• Performance improvements in darcs repair and robustness improvements in darcs check. (Petr Ro kai)
• Extensive manual and online help improvements. (Trent W. Buck)
• Support for GHC 6.10.
• Overhaul of the make-based build system. (Trent W. Buck)
• Cabal is now supported as a build method for darcs. (Duncan Coutts, Petr Ro kai, Gwern Branwen)
• First stab at libdarcs when building through Cabal, all of darcs implementation is now exposed in modules. No API guarantees whatsoever. (Eric Kow)
• Additions to Haddock documentation of the existing darcs modules for improved development experience.
• Improvements in the testing infrastructure. (Christian Kellermann, Gwern Branwen)
• Low-level optimisations in filesystem code. (Ganesh Sittampalam)
• Numerous major and minor bug fixes, refactorings and cleanups by David Roundy, Eric Kow, Jason Dagit, Dmitry Kurochkin, Thorkil Naur, Salvatore Insalaco, Christian Kellerman, Florent Becker, Duncan Coutts, Reinier Lamers, Ganesh Sittampalam, Petr Ro kai.

And a summary of issues that have been fixed in darcs since version 2.1.2 (compiled by Thorkil Naur): 525 amend-record => darcs patches show duplicate additions
971 darcs check fails (case sensitivity on filenames)
1006 darcs check and repair do not look for adds
1043 pull => mergeAfterConflicting failed in geteff (2.0.2+)
1101 darcs send cc recipient not included in success message
1117 Whatsnew should warn on non-recorded files
1144 Add darcs send in-reply-to or header In-Reply-To: x@y.z
1165 get should print last gotten tag
1196 Asking for changes in /. of directory that doesn t exist gives changes in entire repo
1198 Reproducible mergeConflictingNons failed in geteff with ix
1199 Backup files darcs added after external merge
1223 sporadic init.sh test failure (2.1.1rc2+472)
1238 wish: darcs help setpref should list all prefs
1247 make TAGS is broken
1249 2.1.2 (+ 342 patches) local drive detection on Windows error
1272 amend-record not the same as unrecord + record
1273 renameFile: does not exist (No such file or directory)
1223 sporadic init.sh test failure (2.1.1rc2+472) I would like to thank all contributors for making this release possible. Future The next release will be 2.2.1, fixing low-risk issues found in 2.2.0, or those that have been excluded for 2.2.0 due to freeze. This release will appear in two or three weeks time, depending on circumstances. The next major release will be 2.3, due in June or July this year. The focus of this release will be new features and further work on performance. Moreover, we expect that it will use Cabal as its default build system and will make first steps towards sustainable libdarcs API.

Given the current discussion on planet.debian.org about having only one or multiple file-systems, I just wanted to add a plea for having multiple filesystems. In my (perhaps a bit overly paranoid) eyes, having multiple filesystems is mainly a security measure. I prefer having enough partitions so that the following properties hold:

• No unpriviledged user has write access to a directory on the same filesystem as system programs are. Otherwise someone could just hardlink all suid programs and wait. There are high chances that some might have a security problem some day. Security and normal updates will install newer versions, fixing some bugs before enough people know it enough to exploit it or even before anyone at all knows they are there. To protect against this one, one could do scans for suid-root files in user-writeable directories, or one just removes the possibility for this attack-vector.
• No unpriviledged user has write access anywhere that is not mounted nodev and nosuid. In theory that should make no difference, because the user cannot create anything evil anyway. But in practise there were enough exploits with core files and other stuff leading to an suid-root executable suddenly around.
• No unpriviledged user has write access anywhere that is not mounted nodev and nosuid. In theory that should make no difference, because the user cannot create anything evil anyway. But in practise there were enough exploits with core files and other stuff leading to an suid-root executable suddenly around. (And do not forget /proc, /sys, /lib/init/rw, /proc/bus/usb, ...).
• If it is a server that interacts with untrusted users, there should be no place those daemons can write to that is not mounted noexec. While noexec is only a weak defense (scripts could still be executed by calling the interpreter with the script as argument), it gives a little bit more protection and has no real downsizes. The only noticeable one is that apt's preconfiguring of debconf using packages will not work but they will have to ask their questions when being configured. Again, it does not help much when not used consequently: Do not forget /var/tmp and all the little tmpfs the system adds somewhere.

Admittedly, those arguments may not be as convincing for a laptop as for a server. But I personally like to have paranoia enacted everywhere. Uniformness makes live much easier sometimes. Update: If having paranoid in the title was not enough to hint you that I do not claim a system losing a significant amount of security compared to more important measures, let it be told to you know. It's all about thinking about even the little things and taking measures where they do not otherwise harm. To get the warm fuzzy fealing I got when e.g. CVE-2006-3626 was found and my computers had nosuid for /proc already set. ;->

As I move to having more and more machines on my internal LAN, I felt the time had finally come that I sit down, and rebuild my network to take advantage of things such as gigabyte networking, LDAP, single-user sign on, and so forth. I'm doing partially for fun, and partially because its an interesting experiment to see how Linux from an IS environment compares to a Windows 200x IS environment (one of my former jobs was a 2000/XP/2003/Vista sysadmin position).

So, here's my current network setup
blacksteel <- *wireless* ---------------------------------------------- cerberus <-> Internet
/
dawn <------ *wired*-----------------------------------------------------
/
360 <---- *wired* -----------------------------------------------------

Online machines:
cerberus - WRT51GS
backsteel - My laptop
dawn - Development machine
360 - Xbox 360, used to play media from blacksteel

Offline machines (aka, machines I have, but haven't fired up since moving:
helios (PowerMac G4)
apollo (old Dell P3)
junker (RS/6000 rescued from the dumpster, might be dead)
alexandria (NSLU2; gave up its plug for dawn)
coldfusion (Coldfire Board, might be dead; ethernet controller is faulty, but might be able to use a USB based one to breath some life into it; can't autoreboot due to built in bootloader not supporting it; and no JTAG to sanely change the default bootloader).
siren (old MacBook Pro, has a dead internal HDD, but runs fine from an external hard drive. Was my Debian test box until its HDD went to dawn)
exodius - second WRT54GS used to be part of a WDS bridge.
unnamed dev box (not here yet, but likely soon).

Of all these machines, only apollo has a wireless card which ATM is non-functional. In addition, the wired bits of my network are 100Mbps, with a g based wireless hotspot (WPA secured). Futhermore, blacksteel, helios, and siren have gigabyte ethernet. apollo has 100MBps ethernet card. alexandria and dawn have 10MBps, which is painful, especially for NFS root.

I'll drop another 1Gbps NIC into apollo, replacing its wireless card, and give dawn, alexandria, and maybe coldfusion USB based NICs once I get around to resurrecting systems (alexandria and coldfusion don't have hard drives at the moment)

What I would like to do is use an Linux-based router and replace Cerberus. Helios has two gigabyte NICs, so it will take up this duty, as well as provide DHCPv4, and radvd (for IPv6) for the internal network. It's an old computer, and has an onboard model, and its position in my apartment will be close to a phone jack; maybe I'll set it up so I can dial in from outside the LAN in case something goes down (although my phones here are VoIP based so I dunno how useful that's going to be :-)).

Another box (I might task this to apollo, or helios) will run LDAP and NFS services, providing both a netboot based installation with preseed for fast re-installation, and NFS home folders for all machines except blacksteel (unless someone knows a great solution for having a laptop sync NFS and local home folders. helios will run mail, news, and any other untrusted net facing services, with everything else shielded behind it. All machines will run IPv4 and 6.

Anyway, this is the start of my plan in a nutshell, and I intend to continue discussion as I slowly build and implement this updated setup. Wish me luck :-).

Asheesh Laroia explained how to use ssh as a SOCKS proxy if you re behind a firewall that allows you to ssh to some machine not restricted by it: ssh -D. (I don t know how common such firewall setups would be, but the one at my Uni does indeed allow ssh to the outside over authenticated wireless.) With -D, ssh will listen in a local port, and behave as a SOCKS proxy. Set it up like this:

  % ssh -N -f -D localhost:4444 external-machine.example.com

And then you can point your SOCKS-capable application at localhost:4444. Chances are, however, that the application you want to use doesn t support SOCKS (like, in my case, Git). You can use tsocks then, which LD_PRELOADS a library that will divert an app s TCP traffic through the SOCKS proxy. To use it:

  % cat >~/.tsocks.conf
  server = 127.0.0.1
  server_type = 5
  server_port = 4444
  % tsocks git pull

AIUI, this is better than setting -L forwarding because you don t need a forward for each host whose port you want to access. If you re interested in starting ssh in SOCKS mode from .ssh/config, the configuration item is DynamicForward.

Stuff happens quietly on the GForge front, but after some time we decided we're getting bored with not releasing. Since we seem to have run out of major problems in the codebase, the long-awaited GForge 4.7 release is probably round the corner. And so, since GForge migrated from its own in-house translation system to the more conventional gettext API, I'd like to take the opportunity to issue a call for translations, knowing that potential translators won't be too disturbed by unusual tools and formats. You can grab the current state of the translations from the GForge repository browser. Or, for more long-term involvement, checkout the code through Subversion or through Bzr (my gateway branch is available from bzr.debian.org. Current statistics are as follows:

• bg.po: 382 translated messages, 174 fuzzy translations, 1813 untranslated messages.
• ca.po: 1592 translated messages, 281 fuzzy translations, 496 untranslated messages.
• de.po: 1627 translated messages, 272 fuzzy translations, 470 untranslated messages.
• el.po: 0 translated messages, 2369 untranslated messages.
• eo.po: 0 translated messages, 2369 untranslated messages.
• es.po: 1600 translated messages, 236 fuzzy translations, 533 untranslated messages.
• eu.po: 1392 translated messages, 272 fuzzy translations, 705 untranslated messages.
• fr.po: 2368 translated messages, 1 untranslated message.
• he.po: 0 translated messages, 2369 untranslated messages.
• id.po: 0 translated messages, 2369 untranslated messages.
• it.po: 1781 translated messages, 303 fuzzy translations, 285 untranslated messages.
• ja.po: 246 translated messages, 118 fuzzy translations, 2005 untranslated messages.
• ko.po: 1292 translated messages, 264 fuzzy translations, 813 untranslated messages.
• la.po: 0 translated messages, 2369 untranslated messages.
• nb.po: 0 translated messages, 2369 untranslated messages.
• nl.po: 1621 translated messages, 287 fuzzy translations, 461 untranslated messages.
• pl.po: 0 translated messages, 2369 untranslated messages.
• pt_BR.po: 1292 translated messages, 262 fuzzy translations, 815 untranslated messages.
• pt.po: 0 translated messages, 2369 untranslated messages.
• ru.po: 302 translated messages, 142 fuzzy translations, 1925 untranslated messages.
• sv.po: 1289 translated messages, 261 fuzzy translations, 819 untranslated messages.
• th.po: 0 translated messages, 2369 untranslated messages.
• zh_CN.po: 1691 translated messages, 300 fuzzy translations, 378 untranslated messages.
• zh_TW.po: 1664 translated messages, 289 fuzzy translations, 416 untranslated messages.

Results as patches to our patch tracker or the gforge-devel ML please. (Note to Debian-related readers: this translation work will be directly useful on Alioth when we upgrade it.)

fakechroot, or any similar tool that uses a facility such as LD_PRELOAD, is not suitable for use in a security context. Such tools are way cool, but can be trivially broken out of by the attacker. Kapil Paranjape suggests using fakechroot for locking down ssh authorized keys for unison. The idea being unison will run in a (fake)chroot, set up by a regular, non-root user, and will thus be limited to the files you want it to access. First problem is, any statically linked executable on the system (unison can be used to upload one too) is immune to the fakechroot.

joey@gnu:~>FAKECHROOT_EXCLUDE_PATH=/bin fakeroot fakechroot chroot /tmp/empty /bin/sh
sh-3.2# ls
sh-3.2# ls /
sh-3.2# cd ..
sh-3.2# ls
sh-3.2# sash
Stand-alone shell (version 3.7)
> cd ..
> ls
empty  gconfd-joey  gpg-XhukMB  keyring-ZxSuTB  orbit-joey
> cd ..
> ls
bin    etc         lib     opt   selinux  usr

Getting unison to run a static executable in a setup such as Kapil describes is left as an exercise for the more determined attacker than I. Here, though, is an easier way.

sh-3.2# ls /
sh-3.2# ls /bin/..
bin    etc         lib     opt   selinux  usr

To understand why this works, notice that I left /bin excluded when I ran fakechroot. (Still .. Is this a bug in fakechroot?) Or, you could use unison to upload a symlink:

joey@gnu:~>ln -s / /tmp/empty/root
joey@gnu:~>FAKECHROOT_EXCLUDE_PATH=/bin fakeroot fakechroot chroot /tmp/empty /bin/sh
sh-3.2# ls root
bin    etc         lib     opt   selinux  usr

---

Moral: Taking a program, be it fakechroot or unison, that was never designed with security in mind, and trying to use it as a security barrier, is an open invitation to pain.

Since about 2002 I have been using a iPaQ [1] for taking notes while on the move. I have a pair of H3950 iPaQs that were given to me for the purpose of some software development work. As modern mobile phones have telephony as a small part of their feature set I think it s worth comparing a 2002 iPaQ with a 2009 mobile phone in terms of the note taking functionality. I have just got myself an LG U990 Viewty mobile phone [2]. It has a screen resolution of 240*320 which is the highest resolution that is remotely common for a mobile phone - and the same resolution as my 2002 model iPaQ. The LG KC910 Renoir has a resolution of 240*400 and seems to be the only phone that my carrier provides which has a higher resolution. The iPhone [3] has a resolution of 480*320. So it seems that the most expensive modern mobile phone that is available in Australia has a screen resolution that is only twice that of a 2002 PDA. I believe that in Japan you could buy a PDA with a higher resolution than 240*320 in 2002. My iPaQ is running Linux, so I can do whatever I want with it. I have a bar at the bottom of the screen with icons to launch, I configure it with the programs that I need most often and they are always one click away. While with my mobile phone I always have two large icons for paid services from my telco and I can t add icons for the things that I want. My iPaQ has a virtual keyboard that can be displayed in portrait or landscape mode. The above pictures show it in the portrait mode which allows the greatest area of screen space for text. The landscape mode is good for entering long lines of text even though the total number of words that can be displayed on screen is smaller. The size of my iPaQ is 134mm in height, between 77 and 84mm in width (it tapers) and 15.9mm thick without it s protective sleeve. The protective sleeve (shown in the second picture) adds about another 5mm to the width and thickness. My iPaQ is 1.76* the volume of my Viewty phone and at 184g vs 112g is 1.64* the mass. With it s sleeve on it is about 2.4* the volume. It s larger but with the sleeve it s a lot more solid, a touch-screen is very fragile so putting a touch-screen device in your back pocket without a sleeve is not a viable option. So I now own a mobile phone that has more storage, RAM, and CPU power than my iPaQ, but is less useful for the basic task of writing small documents and seems to have no facility for drawing diagrams. Most recent mobile phones have the ability to record voice (my Viewty can store 34 hours on it s internal storage and supports mini-SD cards for extra storage). But my Viewty lacks the ability to pause voice recording so if I wanted a series of notes during a meeting I would get a series of short voice recordings rather than a single file with many items. The todo list is also fairly poor in the Viewty, so even disregarding the poor keyboard on the touch-screen it would compare badly to the iPaQ. So it seems that an iPaQ that is almost seven years old when running Linux and the GPE Palmtop Environment [4] with with default configuration handily beats one of the latest and greatest mobile phones for all areas of common functionality. If the Viewty had it s source code available I would be tempted to contribute some patches (even if it was not free software). Finally, before someone suggests an Android [5], Greenphone [6] or other phone that s relatively open and programmable, I wanted a phone that had a good camera (by phone standards) and came essentially for free on an affordable contract. Maybe in two years time (when my current contract ends) there will be such a phone on offer. Mobile phones aren t THAT important to me, so while I would like to encourage the development of open telephony platforms it s a much lower priority than about a dozen free software projects. I expect that in the future something like an Android will become a great mobile phone with great PDA functionality. But for the moment I ll use an iPaQ and a Viewty.

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


• [2] http://en.wikipedia.org/wiki/Viewty


• [3] http://en.wikipedia.org/wiki/Iphone


• [4] http://gpe.handhelds.org/


• [5] http://en.wikipedia.org/wiki/Android_(operating_system)


• [6] http://en.wikipedia.org/wiki/Greenphone

There are a number of documents about how to permit ssh access to run rsync or unison for remote synchronisation by an appropriate configuration of the authorized_keys file. Of these the best two are probably those by St phane Kattoor and Christian 'Greek0' Aichinger. Joey Hess also explains some of the pitfalls. The problem is the familiar one: to limit the file-system hierarchy accessible. The humble chroot is a natural way to implement such restrictions which is probably what led "Greek0" to suggest the use of dchroot. This is indeed a fine solution ... except, how does one implement it if one is not root on the server machine? WARNING: The rest of this entry is wrong as was pointed out by Joey Hess. See the update at the bottom. The package fakechroot by Piotr Roszatycki provides a way out. The problem I had was as follows:

• I want to share a certain sub-tree of $HOME using unison.
• I am OK with sharing whatever access I give to /bin, /lib and /usr in the process.
• I do not have root access to the machine.

A recent enough version of fakechroot (version 2.8 worked) allows one to do make use of environment variables as follows:

LD_PRELOAD=libfakechroot.so
LD_LIBRARY_PATH=/usr/lib/fakechroot:/usr/lib64/fakechroot:/usr/lib32/fakechroot:/usr/lib:/lib
FAKECHROOT=true
FAKECHROOT_VERSION=2.8
FAKECHROOT_EXCLUDE_PATH=/bin:/lib:/usr
export LD_LIBRARY_PATH LD_PRELOAD
export FAKECHROOT_EXCLUDE_PATH FAKECHROOT FAKECHROOT_VERSION

After this setup one can run

HOME=/ chroot $HOME/some/dir /usr/bin/unison -server

and the unison server¹ will only be able to view /bin, /lib, /usr and $HOME/some/dir; the latter will be mapped to /. (One needs to set the $HOME variable to something sensible for unison to function.) One should not be tempted to create subdirectories of $HOME/some/dir containing only the "relevant" portions of the system directories for unison. The reason is that those files will be created as me and so could be overwritten by unison. The creation of a suitable entry in authorized_keys to use this is an easy exercise! UPDATE: As Joey Hess has noted:

Taking a program, be it fakechroot or unison, that was never designed with security in mind, and trying to use it as a security barrier, is an open invitation to pain.

I had thought about the problem of uploading static-linked binaries and had imagined that it had been overcome. However, the basic facts in this case are:

• unison -server does not have an option to limit its view of the directory heirarchy. The upstream authors are aware of this but it is not clear whether they perceive it as a bug.
• fakechroot is meant to give a different view of the directory heirarchy to programs that use standard libc calls. It does not block access to part of the tree as the real chroot does; again, this is not necessarily a bug.

For a few weeks Laurent Vivier, Blue Swirl and myself have been working on getting QEMU PowerPC working correctly with recent distributions. QEMU used to rely on OpenHackWare for the OpenFirmware implementation on PowerPC. It is a very limited implementation (for example it as no Forth support), which is unable to boot most 2.6.x kernels with the OldWorld emulation. It is able to boot recent kernels with the PReP emulation, but things like the PCI bus emulation are not working correctly. Moreover the PReP kernels are gone with the removal of the arch/ppc tree. OpenBIOS was already used for the OpenFirmware implementation of Sparc 32 and Sparc 64 targets. It now supports PowerPC for the OldWorld emulation. As a result it is now possible to use Debian PowerPC under QEMU emulating an OldWorld machine. What works?

• Display (partly), keyboard, hard disk, network;
• Booting from CD-ROM or from disk using Quik;
• Installation of Debian Etch or Lenny (but due to a bug in debian-installer quik.conf has to be fixed manually);
• Standard Debian kernels;
• G3 CPU emulation: the testsuite results of the GNU libc 2.7 and of GCC 4.3 (Debian packages) are the same than on a real machine.
• virtio devices

What doesn t work / has to be done?

• A few devices part of the MacIO chipset are not emulated and/or are replaced by other devices: IDE, SCSI, Ethernet and sound;
• The red and green colors are reversed, in some modes only (in debian-installer for example);
• X only outputs some strange images;
• PCI devices using I/O ports don t work (like the RTL8029 card, or the RTL8139 card with the 8139too driver).

For those who want to test, an Etch image is available. You will need to compile QEMU by manually given that the version in Debian is too old and that openbios-ppc is still in the NEW queue.