So, the last day of my class on hacking, we are going to spend some time on geeky comics and talking about this pictorial genre. I have started collecting a set of examples that I think are particularly strong and funny reflections of geek/hacker life but I am looking for more. So what are some of your all-time favorite episodes/examples from a comic strip? I am looking for stuff that someone who is not necessarily technically oriented will understand but who will be armed with a fairly broad sense of this world too. Any suggestions would be really appreciated.

The first step is to copy /images/xen/vmlinuz and /images/xen/initrd.img from the Fedora (or RHEL or CentOS) DVD somewhere convenient, I use /boot/OS/ (where OS is the name of the image) but other locations will do. Now choose a suitable Ethernet MAC address for the interface (see my previous post on how I choose them [1]). Create a temporary block device for the install, I use /dev/VG0/OS-install (where OS is replaced by the name of the distribution, “f8” or “cent5“), it’s a logical volume in an LVM volume group named VG0. The device should be at least 2G in size for a basic Fedora install (512M for swap, 1G for files, and 512M free after the install). It is of course possible to use DOS partitions for the Xen block devices, but this would be unreasonably difficult to manage. An option for people who don’t like LVM would be to use files on an XFS filesystem (Ext3 performs poorly when creating and removing large files). When configuring Xen on Debian systems I generally use /dev/hda type device names. The device name seems quite arbitrary and /dev/hda is a familiar name for hard drives that many people have been used to for 15+ years. But the Fedora install process doesn’t like it and I’m forced to use /dev/xvda etc. I often install Fedora on a machine that only has 256M of RAM spare for the DomU. For recent versions of Fedora 256M of RAM is about the minimum for an install at the best of times, and a HTTP install takes even more because the root filesystem used for the install is copied via HTTP and stored in a RAM disk. It might be possible to use less RAM with a CD or DVD install or even a NFS install, but I couldn’t get CD/DVD installation working and I generally don’t give Xen DomU’s NFS access if I can avoid it. So I had to create a swap space (an attempt to do an install with 256M of RAM and no swap aborted when installing the kernel package). I expect that most serious use of Xen will have 256M of RAM or less for the DomU, part of the problem here is that Xen allocates RAM not virtual memory. VMWare allocates virtual memory so the total memory for virtual machines can be greater than physical RAM and thus this problem will be less common with VMWare. I believe that the best way of configuring virtual machine images is to have the virtual machine manager (Xen in this case) provide block devices to the virtual machine and have the virtual machine implement no partitioning (no LVM or anything equivalent). The main reason is that DOS partition tables and LVM configuration on a block device used by Xen can not be used easily in the host environment (the Dom0 for Xen). I am not aware of how to access DOS partition tables (although I’m sure it’s possible somehow) and while LVM can be used it’s a bad idea due to the fact that there is no way to deactivate a LVM volume group that is active, and the fact that there is no support for having multiple volume groups of the same name. The lack of support for multiple volume groups of the same name is a reasonable limitation, but an insurmountable problem when using a virtual machine environment. It’s quite reasonable to create several cloned instances of a virtual machine and renaming an LVM volume group would require more changes inside the virtual machine than you would want. Also using snap-shots of old versions of the virtual machine data is difficult if the same volume group name is used. So for ease of management I want to have filesystems on block devices (such as /dev/xvda) instead of partitions (such as /dev/xvda1). Unfortunately Anaconda (the Fedora installer) doesn’t support this. So I had to do the initial install with DOS partitions and then fix it afterwards. So use the manual option and create a primary partition for the root filesystem and then create a non-primary partition for swap (when using small amounts of RAM such as 256M) so that swap can be used during the install. The root filesystem needs to be at the start of the disk to make it easier to sort this out later. After installing Fedora and shutting the virtual machine down the next step is to copy the block device to the desired configuration (filesystem on an unpartitioned device). If the root filesystem is the first partition then the first 63 sectors will be the partition table and reserved space so dd can be used to copy the data with the following commands: dd if=/dev/VG0/OS-install of=/dev/VG0/OS bs=512 skip=63
e2fsck -f /dev/VG0/OS
resize2fs /dev/VG0/OS The next step is to mount the device /dev/VG0/OS in the Dom0 to change /etc/fstab, I use /dev/xvda for the root device and /dev/xvdb for swap. Now to remove the cruft:
Avahi is a network service discovery system, mainly used for laptops and isn’t needed on a server, it is installed by default on all recent Fedora, RHEL and CentOS releases but it is not useful in a DomU (any unused network service is a security risk if you don’t disable or remove it). Smartmontools is for detecting impending failure of a hard drive and does not do any good when using a virtual block device (you run it on the Dom0). It might be considered a bug that smartd doesn’t exit on startup when it sees a device such as /dev/xvda. The pcsc-lite package for managing smart cards is of no use to me and all the other people who don’t own readers for smart-cards, and it can therefore be removed. Bluetooth networking support (in the package bluez-utils) is also only usable in a Dom0 (AFAIK), and the only bluetooth device I own is my mobile phone so I can’t use it on my computer. The command “yum remove avahi smartmontools pcsc-lite bluez-utils” removes them. For almost all of my DomU’s I don’t use NFS or do any printing, so I remove the packages related to them. Also autofs is in most cases only useful for servers when mounting NFS filesystems. I remove them with the command “yum remove nfs-utils portmap cups autofs“. The GPM daemon (which supports cut/paste operations with a mouse on virtual consoles) is of no use on a Xen DomU, unfortunately the vim-enhanced package depends on it. I could just disable the daemon, but as I like to run small images I remove it with “yum remove gpm“. I may have to reinstall it on some images as some of my clients like the extra VIM functionality. It’s unfortunate that debootstrap doesn’t work on CentOS (and presumably Fedora) so installing a Debian DomU on a CentOS/Fedora Dom0 requires creating an image on a Debian machine or downloading an image from www.jailtime.org . Sample Xen Config for the install: kernel = “/boot/OS/vmlinuz”
ramdisk = “/boot/OS/initrd.img”
memory = 256
name = “OS”
vif = [ 'mac=00:16:3e:66:66:68, bridge=xenbr0' ]
disk = [ 'phy:/dev/VG0/OS-install,xvda,w' ]
extra=”askmethod text” Sample Xen Config for operation: kernel = “/boot/cent5/vmlinuz-2.6.18-53.el5xen”
ramdisk = “/boot/cent5/initrd-2.6.18-53.el5xen.img”
memory = 256
name = “cent5″
vif = [ 'mac=00:16:3e:66:66:68, bridge=xenbr0' ]
disk = [ 'phy:/dev/VG0/cent5,xvda,w', 'phy:/dev/VG0/cent5-swap,xvdb,w' ]
root = “/dev/xvda ro”

• [1] http://etbe.coker.com.au/2007/03/27/xen-and-eth-device-renaming/

Share This

I finally closed my cooperative's annual accounts for the year to 5 April 2008 yesterday. We wrote off one project (not bad for a year) and now we can start on the annual reports. For day-to-day entries, we're still using my simple scheme/web app called SQL-Journal and I should make a new release real soon now. I've added some features since 1.3 and there's a few more I want to add, but I'm no accountant, so it will remain simple and stupid, but good enough for me. Bristol Wireless's accountant has written some comments on GNUcash which is an interesting view: "not quite there yet" which could help finance software developers. Better searching is one thing I will add to SQL-Journal some time, but it will probably never have features like reporting (I either use an SQL-based report package or export to a spreadsheet) and I know it's no better at handling VAT, mainly because TTLLP isn't VAT-registered yet. I also spotted Finance software in Emdebian, by Neil Williams recently. I wonder if the bursts of accounting interest are connected to the end of the financial year?

The CIO and the Office For Technology of New York State (USA) just released a new report on electronic records strategy, titled A Strategy for Openness: Enhancing E-Records Access in New York State. I submitted my own comments during the call for public comments earlier this year -- apparently there were only 114 comments submitted by the public (you can see the call for comments and an overview/analysis of the responses). I wish there'd been more, since it looks like the 59 individual commenters were overwhelmingly supportive of a requirement for the Gov't to use ODF. The rest of the comments were from governments, NGOs, and businesses, and they don't seem as unanimous as the individual commenters. Looking at the metadata for the executive summary shows just how far we have to go:

[0 dkg@squeak doc]$ pdfinfo PartIerecordsStudy.pdf    egrep '^Title Producer Creator'
Title:          Microsoft Word - PartIerecordsStudy.doc
Creator:        PScript5.dll Version 5.2.2
Producer:       Acrobat Distiller 8.1.0 (Windows)
[0 dkg@squeak doc]$ 

And in a message sent to commenters announcing the report, they seem to be aware that they're not quite doing their best at interoperability:

(Please note this is the first time any of NYS government's agencies has ever published a document in ODF format. We ran into problems this morning not caused by the format, but rather with some controls on our systems which were not prepared to encounter such documents. So the website links to ODF versions are not working at the moment, but will be repaired soon).

What web server are they running that is having trouble "encountering" ODF? No surprise:

[0 dkg@squeak doc]$ wget -S -O/dev/null 'http://www.oft.state.ny.us/policy/esra/erecords-study.htm' 2>&1   grep Server
  Server: Microsoft-IIS/6.0
[0 dkg@squeak doc]$ 

Sigh. My initial reaction to the report (i've only read the executive summary, not the supporting documentation) is disappointment. While they claim that "openness" is an important feature, they fall far short of taking a strong stand for free and open formats. The main thrust of the executive summary seems to be (paraphrasing here, i welcome corrections):

• it's a bad idea to mandate a single particular technology because technologies will change faster than law.
• we need an Electronic Records Committee (ERC) to provide regular, executive guidance on electronic record storage and maintenance
• "openness" is good, but needs to be weighed against (ill-specified, at least in the executive summary) "other features"
• we're not going to make any concrete recommendations about what to do next

While these are unsurprising conclusions, they don't take the strong stand i'd like them to take. They seem aware of the "chicken and egg" problem of wide adoption and vendor support, and aware of the anti-democratic effects of proprietary formats. But they don't seem to be willing to act as a catalyst to push free formats explicitly. If they did, they could break the chicken/egg vendor lock-in cycle and facilitate better open government practices while simultaneously encouraging a healthy information ecosystem. At this point, i suppose my biggest hope from the process is that the proposed ERC forms pilot groups with long-term goals modeled after Munich, but i'm not holding my breath. If there are any advocates or participants in the Munich process who want to share what's been working for you (and what hasn't), i'd be interested in hearing about it.Tags: government, odf, policy

Although it's not particularly clear, a neat feature of xtightvnc is the ability to modify the pop-up menu that appears when you press F8 to send arbitrary keystrokes. The trick is overriding some of the X11 resources of the file. If you have a look in /etc/X11/app-defaults/Vncviewer (make sure you have a recent package) you can see the default keybindings for the popup menu, which are a good template. Assuming you want to keep them all, you can add your own buttons by starting at button 9 and re-defining the total button count in your ~/.Xresources: Make sure you merge this with xrdb -merge ~/.Xresources if you don't want to bother logging out and in. This way I can easily send Alt-F1, etc. through to the other side; useful for things like switching virtual terminals in VMware workstation running remotely. I imagine if you were insane you could do all sorts of other tricks too!

The way Xen works is that the RAM used by a virtual machine is not swappable, so the only swapping that happens is to the swap device used by the virtual machine. I wondered whether I could improve swap performance by using a tmpfs for that swap space. The idea is that as only one out of several virtual machines might be using swap space, a tmpfs storage could cache the most recently used data and result in the virtual machine which is swapping heavily taking less time to complete the memory-hungry job. I decided to test this on Debian/Etch (both DomU and Dom0). Above is a graph of the time taken in seconds (on the Y axis) to complete the command “apt-get -y install psmisc openssh-client openssh-server linux-modules-2.6.18-5-xen-686 file less binutils strace ltrace bzip2 make m4 gcc g++“, while the X axis has the amount of RAM assigned to the DomU in megabytes. The four graphs are for using a real disk (in this case an LVM logical volume) and for using tmpfs with different amounts of RAM backing it. The numbers 128000, 196000, and 256000 and the numbers of kilobytes of RAM assigned to the Dom0 (which manages the tmpfs). As you can see it’s only below about 20M of RAM that tmpfs provides a benefit. I don’t know why it didn’t provide a benefit with larger amounts of RAM, below 48M the amount of time taken started increasing exponentially and I expected that there was the potential for a significant performance boost. After finding that the benefits for a single active DomU were not that great I did some tests with three DomU’s running the same APT command. With 16M of RAM and swap on the hard drive it took an average of 408 seconds, but with swap on the tmpfs it took an average of 373 seconds - an improvement of 8.5%. With 32M of RAM the times were 225 and 221 seconds - a 1.8% improvement. Incidentally to make the DomU boot successfully with less than 30M of RAM I had to use “MODULES=dep” in /etc/initramfs-tools/initramfs.conf. To get it to boot with less than 14M I had to manually hack the initramfs to remove LVM support (I create my initramfs in the Dom0 so it gets drivers that aren’t needed in the DomU). I was unable to get a DomU with 12M of RAM to boot with any reasonable amount of effort (I expect that compiling the kernel without an initramfs would have worked but couldn’t be bothered). Future tests will have to be on another machine as the machine used for these tests caught on fire - this is really annoying, if someone suggests an extra test I can’t run it. To plot the data I put the following in a file named “command” and then ran “gnuplot command“:
unset autoscale x
set autoscale xmax
unset autoscale y
set autoscale ymax
set xlabel “MB”
set ylabel “seconds”
plot “128000″
replot “196000″
replot “256000″
set terminal png
set output “xen-cache.png”
replot “disk” In future when doing such tests I will use “time -p ” (for POSIX format) which means that it displays a count of seconds rather than minutes and seconds (and saves me from running sed and bc to fix things up). I am idly considering writing a program to exercise virtual memory for the purpose of benchmarking swap on virtual machines. My raw data is below:

time apt-get -y install psmisc openssh-client openssh-server linux-modules-2.6.18-5-xen-686 file less binutils strace ltrace bzip2 make m4 gcc g++ 96M: 0m37.416s
64M: 0m47.607s
48M: 0m55.050s
32M: 1m8.200s
30M: 1m15.010s
28M: OOM process 2 with default initrd, needed MODULES=dep to make it boot
28M: 1m18.694s
24M: 1m25.517s
20M: 1m38.376s
16M: 2m15.594s
14M: 3m14.777s
13M: OOM when the initrd is not hacked to remove LVM stuff and drivers for Dom0 stuff
13M: 4m15.930s
12M: really won’t boot 128000K of RAM in Dom0 for caching (18M cache and 70M free), 256M swap per DomU on tmpfs. 96M: 0m40.121s
64M: 0m48.207s
32M: 1m12.394s
24M: 1m21.929s
16M: 1m59.042s
14M: 2m48.517s
13M: 3m29.391s 196000K of RAM in Dom0 for caching: 64M: 0m47.871s
32M: 1m12.078s
24M: 1m22.360s
16M: 2m0.336s
14M: 2m36.459s 256000K of RAM in Dom0 for caching: 64M: 0m47.949s
32M: 1m11.435s
24M: 1m21.402s
16M: 1m58.884s
14M: 2m39.081s 256000: of RAM in Dom0, three DomU’s: 32M: 3m41.583s 3m40.737s 3m41.071s
16M: 6m16.430s 6m14.832s 6m7.569s hard drive, three DomU’s: 32M: 3m42.100s 3m47.516s 3m46.333s
16M: 6m41.587s 6m50.837s 6m51.795s

Share This

Recently I have mostly been "behind". I've caught up a little on what I wanted to do though over the past couple of days, so I won't feel too bad. I've:

made a new release of the chronicle blog compiler, after recieving more great feedback from MJ Ray. un-stalled the Planet Debian. updated the weblogs hosted by Debian Administration, after help and suggestions from Daniel Kahn Gillmor. stripped, cleaned, and tested a new steam engine. Nearly dying in the process. discovered a beautiful XSS attack against a popular social networking site, then exploited that en masse to collect hundreds of username/password pairs - all because the site admins said "Prove it" when I reported the hole. Decisions decisions .. what to do with the list... released a couple of woefully late DSAs. started learning British Sign Language.

Anyway I've been bad and not writing much recently on the Debian Administration site, partly because I'm just sick of the trolling comments that have been building up, and partly due to general lack of time. I know I should ignore them, and I guess by mentioning them here I've kinda already lost, but I find it hard to care when random folk are being snipy. Still I've remembed that some people are just great to hear from. I know if I see mail from XX they will offer an incisive, valid, criticism or a fully tested and working patch. Sometimes both at the same time. In conclusion I need my pending holiday in the worst way; and I must find time to write another letter... ObQuote: Dungeons & Dragons

After catching a glimpse of John McCain on Saturday Night Live (SNL) I decided to watch a full show to see if is good enough to add to my daily US news lineup (which currently consists of The Daily Show, The Colbert Report and NBC Daily News). From the very start the comedy level is pathetic with fake laughter gushing out over something that is apparently was supposed to be funny. Combined with the pretense of “smart comedy” that says - “If you don’t laugh when we laugh, you just don’t get it.” which is pure old brainwashing aimed to make people stop thinking. Very far from anything I would call good TV. BIG INTRO WITH BIG VOICE. Useless Americanisms. And then Steve Carell does the most stupid and idiotic ‘6 RedBulls’ routine that I’ve ever seen. Are the writers still on strike? “There can be only one Democratic nominee” was a bit better, bit still rather simplistic. “Deal or no deal” was an even dumber one. “Two assholes do karaoke” actually was even worse. “Japanese Office” was nothing but a cheap pun of the *American* version of the Office with a few Japanese words. I think it went on for 5 minutes, which was 4 minutes and 55 seconds too long for something of such horrible production value. Another John McCain appearance, while misreading the teleprompter (not on purpose), was actually the highlight of the show. That shows two things: John McCain is so desperate that he feels it is acceptable to appear on such a low quality show and that SNL is overrated - even a politician can do a better job at comedy then the SNL staff. That Usher guy song was on the same level as the jokes of the show, so no hard done there. News were almost ok. Not nearly as good as The Daily Show, but better then the rest of the show. Not a single item was chosen to make people think, just the opposite. “FitTV” bit was .. well .. pointless. So was CPR bit. And the ‘Bless this child’ bit. In summary, I’ve never seen a more pointless and badly made show. That thing could pass for good in 60s or maybe even 70s, but to consider that show good nowadays in any country with reasonably developed TV would be just insanely dumb.

When recording changes in some software there are basically three approaches, with their different advantages and disadvantages.

• One approach is just record modifications chronologically. Each modification is just a little diff (or some glorified variant of diff, or if you insist something that is no diff but just has some similarity). Advantages are:
  • It keeps itself out of the way. You just do modifications and store them somehow one after the other.
  • You can reconstruct all past points, so can regain missing documentation by looking at the evolution in time.
  So it is no surprise that essential every tool (i.e. all the VCSes) to handle non-packaging work on software essentially uses this way. If you have an canonical other source for the software (like an upstream for an package), it has quite some severe drawbacks:
  • Reviewablity does not scale. While every single diff can easily be reviewed, the mass is not. Most changes are relative to past versions of the software. If something introduces a problem or and upstream change introduces a problem with that, the fix might only show up years later, separated by tons of other changes in between. (The effect especially with changing upstream always depends a bit on the later merging, but the worst case is still the same).
  • For the same reason changes cannot be easily extracted. Single commits usually are fine, but what of those past changes is needed to make some specific change in the functionality is easily lost after some time, some improvements and updates to new upstream versions. The whole approach degenerates to having a single large .diff.gz file of the package. (Except one has a bit of history recorded, so when sorting out the stuff in that diff one can better guess what effect a single unattributable line has).
• The next possibility is to store modifications sorted by topic and against upstream (either as .diff files relative to the upstream source, as topic branches, or or or). Advantages:
  • As you have to send the patch upstream anyway, you have to create such an patch initially, anyway. Also each is in a format that if upstreams wants to apply a single one, each is in the correct format for this.
  • Branches relative to a (relatively) fix point are usually use to store in VCSes.
  • When other people want to pick a subset of those patches, they only have to do the merging, and not dismerging with the missing ones first.
  On the other hand, there are some disadvantages with this:
  • As the differences are relative to the upstream code, multiple patches are in general not applicable without additional merging.
  • Because of this, those patches cannot be used to generate the source to build the Debian package.
  • Thus those patches by itself are never directly used, unless the maintainer regularly tests them, they are essentially untested and will see bitrot.
  • As those are not the changes to the package because of the missing merge, they are nice for a cursory review, but if you want the review the actual changes, you need to review the merged variants.
• Last but not least, there are stacked patches, i.e. patches that are supposed to be applied in a specific sequence. Advantages:
  • The patches itself are actually used. Thus they get wide testing and bitrot cannot happen that easily.
  • Equally, reviewing the actual changes can be separated into the different patches, as connected changes are next to each other and the files describe the changes without pitfalls in merges.
  • If someone else wants to use multiple patches from the start of the sequence, no merging is necessary. They can directly be applied.
  Given these advantages, it is no big surprise that all Debian specific patch management tools (like dbs) and other programs to deal deal with multiple patches against other people's code (like quilt) use this approach. Though there are also some disadvantages:
  • Ordering patches is not important. Only unrelated patches can be skipped to have later patches applied cleanly, so ordering needs to predict what patches are more likely to be used by other people.
  • Testing only happens for the whole stack. If some match modifies parts that a later patch removes, bitrot can still happen.
  • Extracting those patches from the currently available VCSes is not trivial.

So the format most suitable to Debian packages (stacked patches) is the total opposite of a format most suitable when you are upstream yourself and nothing is suitable for everything. There are many different thinkable ways to combine the different things to get more of the advantages, though many are a bit lacking (like storing quilt series in a VCS as text files), not yet possible or non-trivial with the current tools. Hopefully the future will improve that.

I just wrote about the system administration issues related to the recent Debian SSL/SSH security flaw [1]. The next thing we need to consider is how we can change things to reduce the incidence of such problems. The problem we just had was due to the most important part of the entropy supply for the random number generator not being used due to a mistake in commenting out some code. The only entropy that was used was the PID number of the process which uses the SSL library code which gives us 15 bits of entropy. It seems to me that if we had zero bits of entropy the problem would have been discovered a lot sooner (almost certainly before the code was released in a stable version). Therefore it seems that using a second-rate source of entropy (which was never required) masked the problem that the primary source of entropy was not working. Would it make sense to have a practice of not using such second-rate sources of entropy to reduce the risk of such problems being undetected for any length of time? Is this a general issue or just a corner case? Joss makes some suggestions for process improvements [2]. He suggests that having a single .diff.gz file (the traditional method for maintaining Debian packages) that directly contains all patches can obscure some patches. The other extreme is when you have a patch management system with several dozen small patches and the reader has to try and discover what each of them does. For an example of this see the 43 patches which are included in the Debian PAM package for Etch, also note that the PAM system is comprised of many separate shared objects (modules), this means that the patching system lends itself to having one patch per module and thus 43 patches for PAM isn’t as difficult to manage as 43 patches for a complex package which is not comprised of multiple separate components might be. That said I think that there is some potential for separating out patches. Having a distinction between different types of patches might help. For example we could have a patch for Makefiles etc (including autoconf etc), a patch for adding features, and a patch for fixing bugs. Then people reviewing the source for potential bugs could pay a lot of attention to bug fixes, a moderate amount of attention to new features, and casually skim the Makefile stuff. The problem began with this mailing list discussion [3]. Kurt’s first message starts with “When debbuging applications” and ends with “What do you people think about removing those 2 lines of code?“. The reply he received from Ulf (a member of the OpenSSL development team) is “If it helps with debugging, I’m in favor of removing them“. It seems to me that there might have been a miscommunication there, Ulf may have believed that the discussion only concerned a debugging built and not a build that would eventually end up on millions of machines. It seems possible that the reaction would have been different if Kurt had mentioned that he wanted to have a single source tree for both debugging and for regular use. It also seems likely that his proposed change may have received more inspection if he had clearly stated that he was doing to include it in Debian where it would be used by millions of people. When I am doing Debian development I generally don’t mention all the time “this code will be used by millions of people so it’s important that we get it right“, although I do sometimes make such statements if I feel that my questions are not getting the amount of consideration from upstream that a binary package destined for use by millions of people deserves. Maybe it would be a good practice to clarify such things in the case of important packages. For a package that is relevant to the security of the entire distribution (and possibly to other machines around the net - as demonstrated in this case) it doesn’t seem unreasonable to include a post-script mentioning the scope of the code use (it could be done with an alternate SIG if using a MUA that allows selecting from multiple SIGs in a convenient manner). In the response from the OpenSSL upstream [4] it is claimed that the mailing list used was not the correct one. Branden points out that the openssl-team mailing list address seems not to be documented anywhere [5]. One thing to be learned from this is that distribution developers need to be proactive in making contact with upstream developers. You might think that building packages for a major distribution and asking questions about it on the mailing list would result in someone from the team noticing and mentioning any other things that you might need to do. But maybe it would make sense to send private mail to one of the core developers, introduce yourself, and ask for advice on the best way to manage communication to avoid this type of confusion. I think that it is ideal for distribution developers to have the phone numbers of some of the upstream developers. If the upstream work is sponsored by the employer of one of the upstream developers then it seems reasonable to ask for their office phone number. Sometimes it’s easier to sort things out by phone than by email. Gunnar Wolf describes how the way this bug was discovered and handled shows that the Debian processes work [6]. A similar bug in proprietary software would probably not be discovered nearly as quickly and would almost certainly not be fixed in such a responsible manner. Update: According to the OpenSSL project about page [7], Ulf is actually not a “core” member, just a team member. I had used the term “core” in a slang manner based on the fact that Ulf has an official @openssl.org email address.

• [1] http://etbe.coker.com.au/2008/05/18/debian-ssh-problems/


• [2] http://np237.livejournal.com/17981.html


• [3] http://marc.info/?t=114651088900003&r=1&w=2


• [4] http://www.links.org/?p=328


• [5] http://advogato.org/person/branden/diary/5.html


• [6] http://gwolf.org/node/1743


• [7] http://www.openssl.org/about/

Share This

At the time of writing, I've not seen an announcement (again), but there's an agenda for an Software in the Public Interest IRC meeting at 19:00 GMT tonight (Wednesday 21st). It doesn't include any reports, motions or items for discussion. This is particularly surprising because Michael Schultheiss declared in the last meeting that there would "definitely" be a complete treasurer report before this meeting (see 20:07:48 in the meeting log http://lists.spi-inc.org/pipermail/spi-general/2008-April/002571.html I sent to spi-general after last month's meeting). But why are there no motions or items? Are we that short of work to do? I may not be at this meeting (library event in Bristol instead) but I'll post a log to spi-general later if I have one.

Today was a good day — at least if I average all the things happened today. And since Twitter.com is currently down and there’s no way all those things fit in 140 characters, I decided to pack them in a “short” blog post:

• This afternoon one backplane of our newest backup server caught fire. :-( No collateral damages though. :-) The machine is currently at the manufacturer and should be back on Monday.
• My EeePC (more about it in an upcoming blog post) recently overheated and switched off. It looked as if it since then didn’t turn off correctly anymore, but power and the fan stayed on although the operating system was shut down. Today I found out with help of the debian-eeepc-devel mailing list that my EeePC wasn’t damaged but the snd_hda_intel driver caused the machine to not shut down correctly. One rmmod line into /etc/default/halt and it shuts down perfectly and fast again. :-) See also the hint in the Debian Wiki.
• Even more: I’m sure that it not even has been turned by being hit by something through its neopren bag inside my backpack as I initially expected. It turned out that I must have not noticed that it wasn’t properly shut down and put it in the neopren case in that condition :-( since the power button simply doesn’t work when the lid is close. The good news: It doesn’t seem to have carried away any damage. :-)
• I had the same problem as Beat had: I couldn’t import certificates into my Nokia E51 mobile phone. I already tried to import the PEM and the DER versions of the CAcert root certificates but it just didn’t work. After Beat found out (Kudos to maol who pointed me to Beat’s blog posting), which certificate format is necessary, I found out that while the CAcert PEM certificates have the correct Content-Type header (application/x-x509-ca-cert) the DER certificates have not — they are served as text/plain. Downloading them to my server, adding the right content type to the config and downloading them from there again with the mobile phone worked fine and I now don’t need to acknowledge anymore the certificate of my IMAP server each time I want to read my e-mails on the mobile phone. :-)
• One more EeePC thing. During a discussion on the debian-eeepc-devel mailing list, I noted that the maximum summed up resolution of the internal and external display seems to be 800×800, but it turned out that you can configure that in your xorg.conf. :-) The screen section of my xorg.conf now looks like this:

  Section "Screen"
          Identifier      "Default Screen"
          Monitor         "Configured Monitor"
          SubSection "Display"
                  Virtual         2048 2048
          EndSubSection
  EndSection
  

  See also the xorg.conf in the Debian Wiki.

So if I sum up the smileys in this blog posting, I get 5 happy ones and only 2 sad ones. I think being happy outrun being unhappy today. ;-) Now I want to dive into my bath tub to get this smell of burning servers off me and my cloths. ;-)

An interesting thread on openssh-unix-dev points out a way that a compromised remote ssh account or host could potentially trick users into divulging the passphrase for their local secret key. Given that we're all dealing with the potential for compromised ssh hosts lately, i think this is an important consideration. (this has apparently been raised on openssh-unix-dev as far back as 8 years ago). Unfortunately, a couple messages with mangled headers seem to have broken the thread into two chunks in the archive, severing the start of the thread from the part where it starts getting really good: In particular, Damien Miller's suggestion is to forbid in-terminal key-based authentication entirely, and rely instead on ssh-agent. My impression of this strategy is that it's analogous to forcing an out-of-band verification process -- since the in-channel communication is happening in the tty, and the remote host will have some level of control over the tty once authentication succeeds, it's important that any locally-divulged secrets (e.g. the passphrase for the local secret key) are not transmitted over the tty in question. Of course, disabling in-terminal key-based authentication creates something of a usability problem for users who aren't using X11 (and who don't have some other method for an out-of-band ssh-askpass). And it also points out the additional problems with X11 forwarding (e.g. a compromised host allowed to forward X connections could trigger a mimicry of a standard ssh-askpass password prompt). This is something that debian might want to consider, as we've diverged from upstream on the default settings for ForwardX11Trusted. I'm uncomfortable with how Damien's suggestion raises the bar to key-based authentication in general, since users will now have to understand both keys and agents in order to effectively authenticate this way. But maybe that's what's needed, since we desperately need to phase out password-based authentication (and all the security pitfalls associated with it) in this brave new networked world. At any rate, i've adopted the suggestion for now:

[0 dkg@squeak ~]$ tail -n1 .ssh/config
IdentityFile none
[0 dkg@squeak ~]$ 

I'm curious to know if other people have adopted this strategy, or have other mitigating techniques.Tags: security, ssh

Been rather busy, so I haven't had a chance to continue recording the trip... We got into Zurich (albeit late), without incident. Immigration was the biggest joke ever. There was no paperwork at all, and we just handed our passports to the guy, who just looked at them casually, and waved us through. No stamp, no scan, no nothing. It was a bit disappointing really. We got our rental car, and drove around aimlessly for a bit, until the GPS got lock, and then headed for Prague. We went through Austria, where the guy at the border did give our passports a more thorough inspection, more because we were confused and were waving them at him. He also gave us a stamp. The woman from Hertz told us we needed to buy some sort of highway sticker for the car to drive in Austria (wow it's hard to type "Austria", "Australia" just keeps coming out from muscle memory), so we bought one of them and stuck it on the windscreen, and then promptly entered Germany. The autobahns in Germany are wicked! Everyone's screaming along at a ridiculous pace. The fastest I got up to was 180 km/h. The roads themselves were surprisingly quiet, and only two lanes. We stopped off for dinner somewhere in Germany, and finally arrived at the hotel in Prague at about 1am on Sunday morning, so it took about 7 hours instead of the 6 that we'd estimated. We got to bed by about 2am. I woke up at about 10am, then went back to sleep until about 2pm. We finally ventured out for a bit of exploration at about 3pm on Sunday. One observation about Czechs: they seem like a pretty dour bunch. Here we were wandering around, being all wide-eyed and touristy, smiling at everyone, and they'd just scowl back at you, no matter how hard we tried to get a smile out of them. After that initial wander, we discovered that there was a Metro station right across the road from the hotel in another direction, so we caught that to go and check out Prague Castle. The Metro system is another one of those great subway systems that I love. It ran regularly, so you didn't need to concern yourself with a timetable. The ticketing was a bit bizarre. It seemed totally honor-system based. There were no barriers to stop you getting in or out. It was fairly late by the time we got to Prague Castle, so we just wandered around the grounds, took a look inside Saint Vitus's Cathedral, and caught an orchestral performance in Saint George's Basilica, then headed back to the hotel. Everything at Prague Castle was pretty mind-blowing. The size of grounds. The view. Saint Vitus's Cathedral. The Cathedral was huge. When you stepped inside and looked up... words can't describe it. It was amazing. Unfortunately, we didn't bring a camera with us, so we don't have any photos from the Sunday excursion, but Sarah went back this afternoon, and her photos are here. I think the thing that struck me the most was that here were some seriously old buildings - older than my home country, and they were in amazingly good condition. They really built things to last back in the day. The weather so far has been pretty miserable, and if the forecast is anything to go by, will remain miserable until we drive out on Saturday. We've survived, language-wise. The default language of the hotel staff seems to be English, and most random people we've had to interact with seem to speak English. I feel really arrogant and rude just speaking in English to people without first asking if they speak English, but I'm also getting really sick of starting every conversation with "Do you speak English?" The printed language is by and large indecipherable. The currency, which in English is called a "crown" is crazy. One US dollar buys about 16 Czech Koruny, and the prices are ridiculous. A glass of wine at the hotel is maybe 250 CZK. Granted, the hotel prices are obscene, but seeing triple-digit prices for a glass of wine seems totally bizarre. The prices in general seem pretty steep. Sarah said she got a 2 koruny coin in change today. We've got no idea what you'd actually use that for. Last night, after the conference had finished for the day, we wandered off in a different direction again, and wandered through the grounds of Vy ehrad Castle. The Cathedral of Saint Paul and Peter has an amazing graveyard in it, including the grave of the composer Dvorak. We grabbed some dinner at a nearby restaurant, which was substantially cheaper than the hotel restaurants. Again, we forgot to take a camera with us.

It’s not every day that your work is ignored by a founder of Mozilla Europe. From El Pa s:

En Espa a un 23,5% de visitas se dan en Firefox, un ndice que es superior al de EE UU, pero que no llega a los ndices de Polonia donde el 40% del tr fico se da en el navegador de Mozilla. A pesar de estos aceptables datos [Tristan] Nitot ha recordado y pr cticamente hecho un llamamiento para crear una versi n del navegador en gallego: “Hay una versi n en catal n de Firefox construidas por voluntarios que les importa su idioma, al igual que la hay de euskera. Pero a n no hay una versi n en Galicia, muchas veces me lo preguntan y mi respuesta es que si nadie de Galicia se presenta no habr una versi n en gallego, estamos dispuestos a que la gente trabaje con nosotros".

Loosely translated:

“There’s a Catalan version of Firefox built by volunteers who care about their language, and there’s another one in Basque. But there’s no Galician version yet, I get asked this very often, and my answer is that if nobody from Galicia steps up there will be no Galician version. We would like people to work with us".

So, apparently, there’s no Galician translation of Mozilla. I guess that my more than three years’ worth of work were wasted (Dec 2001 - Jul 2004 and Jan 2006 - Aug 2006), that Xis and Galego21 did nothing back in the nineties and noughties, and that what mancomun.org is hosting is an empty XPI file. To not speak of the paralysed/paralysing bureaucracy of the Mozilla Foundation when several groups of volunteers, one after the other, tried to reinstate the official Galician l10n team. I would be pissed off if I cared about Galician. Because, you know, from reading my blog it’s obvious I don’t.

Last Thursday, and the few days after, were quite intense. A series of events made me feel really loved by a lot of people, which is always a good reminder of what kind of friends you are surrounded by. I could talk about Pep's gift at work, Visenteta, a goldfish which now lives in an aquarium at home, which in turn was donated by Cristina and Brande. While I still have mixed feelings about keeping animals in cages, my choices were give it a better place than the small bowl where it initially lived, give it away to someone who could properly take care of Visenteta, or sacrifice it. I unsuccessfully tried #2, can't do #3 myself, so I accepted Brande's offer to have a decently-sized aquarium at home. Visenteta seems happy today, and I've learned all about aquarium maintenance the hard way. During the day my mobile phone didn't rest for too long intervals; everyone was calling it to congratulate me and so on. But the bigger emotions came after leaving work, when I went to l'Alqueria to hang around with my friends and see if they would go have an orxata with Maria and me. Strangely, they refused, being in the middle of an apparently very important plant transplantation operation. When suggested going for dinner instead, the reaction was pretty cold too, but this was understandable as we'd meet on Friday at my place for a tiny celebration. In the end we headed off to Alboraia alone and had a delicious orxata in Toni's shop. Maria said she had a surprise reservation in a Indo-Pakistani restaurant near my house, so after a while we cycled back to Val ncia. As it was getting dark and cold, we went into my house to get some clothes, and when I opened the living room door, I was scared by a bunch of shadows suddenly shouting at me and was buried in confetti. I couldn't react for the next 10 seconds, while my brain quickly built relations of many details that had happened during the week, all part of the preparations for a secret party at my own place. Wow, the feeling is incredible. I've participated in similar surprise parties, but had never been the target. I hope everyone reading this gets one at least once in their lives, I really loved it! But still, when the party ended, I slowly started to find little gifts all over the place: a book under my pillow, a bicycle bell on my handlebar, a cactus for my computer space... My friends had been planning all of this for the last two weeks, and I never suspected anything. Incredible! It really makes me feel surrounded by people who care about and love me, and went through the hassle of coordinating 10 or 12 persons with me not noticing at all. Thank you, everyone! The book, by the way, is Si no plou, plour , by TV3's M nica L pez, a fun compendium of popular weather proverbs which we discovered in a gas station in Tarragona, during our Easter trip to la Terra Alta.

I'm excited by version 7 of debhelper, in particular the opportunity for debian/rules minimization. I suspect this will lower the barrier for rapid, reasonable packaging of simple software tools in a way that should be easy to audit and maintain. The most-minimized debian/rules possible with it is just (from dh(1)):

#!/usr/bin/make -f
%:
	dh $@

And all of the project-specific interesting bits go into nice, clean, well-named files under debian/. However, lintian (at least as of 1.23.48) complains loudly about the minimized debian/rules:

E: xdotool source: debian-rules-missing-required-target binary
E: xdotool source: debian-rules-missing-required-target binary-arch
E: xdotool source: debian-rules-missing-required-target binary-indep
E: xdotool source: debian-rules-missing-required-target build
E: xdotool source: debian-rules-missing-required-target clean

I'm not sure the right way to proceed: should i try to manually add overrides for each package that uses a minimized debian/rules? Should lintian recognize debhelper-specific minimized rules files and accept them? Should debhelper assuage lintian somehow? Or is this rules file minimization actually not as good an idea as I think it is? I notice that mr, which is Joey Hess's first example package using the minimized rules also reports the same errors.Tags: debhelper, lintian, packaging

People who know me are surprised when I tell them I play Guitar Hero, simply because I don t ever touch gaming consoles, or any computer games whose complexity surpasses Pac Man, with a stick except Guitar Hero, which is just fun. I also listen to a bunch of music, whenever possible, basically, and there are plenty of songs that I d love to try on Guitar Hero. Mel and I decided that e.g. Shine on You Crazy Diamond or Comfortably Numb are far up there (and they probably exist somewhere), but today I listened to Damn the River by The Phoenix Foundation and thought the same, yet I doubt that this song has been transcribed, which is a shame. I am well aware that sites exist, or must exist, which have songs for download, or you could make your own (check out Metallica s Master of Puppets there!). But that sounds like a lot of time lost, which I prefer to spend otherwise like today it occurred to me that Guitar Hero 2000 is long overdue. Guitar Hero 2000 is the Guitar Hero game that takes your song on audio input and scans it in advance and that fits the song to play to the five frets in the game in real-time. It can t be that hard. Where is it? NP: Pure Reason Revolution: The Dark Third

A brilliant commentary on how the mindless war in Iraq has been effecting the lives of people in the USA, In the Valley of Elah says a lot without speaking much. By the end of the movie, a father -- the same who tells his disturbed soldier-son over the phone: "it is your nerves speaking" -- hangs the US flag upside down.

A full week of high fever kept me down and even the "low hanging fruit" of life went undone. Then, another few days of blood-red eyes, thanks to some stiff antibiotics that I was on. The cause for this recurring fever seems to be an infection of the throat and tonsils, so it looks like I might have to consider getting my tonsils removed. To some extent, In the Valley of Elah shook me out of my moroseness. H says that Charlize Theron is a very cerebral actress and I must agree.

On a related note, I was pointed to this neat article titled Why Do They Hate Us? in which Mohsin Hamid says that the question that US-o-American's should be asking is Why do they love us?.

After shutdown of the old L.ROOT-SERVERS.NET the IP address formerly associated with it, the IP continued to answere requests. More informations can be found at the ICANN Blog
UPDATE: Before bothering around, if you read the ICANN Blog, you realize that the issue was fixed very shortly. The whole problem is, that the file of the root DNS servers have to be keeped up to date. This issue should be fixed by operator of resolving nameservers (usually your ISP). A goody will be, to have this fixed by the next point release of debian, but it is NOT security critical.
Thanks Thijs for make me sensible that my article may misslead people who are not reading the referenced document.
UPDATE 2: A more technical description can also be found at Renesys Blog and a disussion how it is related to debian.