My Dell PowerEdge T105 server (as referenced in my previous post [1]) is now working. It has new memory (why replace just the broken DIMM when you can replace both) and a new BIOS (Dell released an “Urgent” update yesterday that fixes a problem with memory timing and Opteron CPUs). The BIOS update can be installed from a DOS executable (traditionally done from a floppy disk) or an i386 Linux executable. As I didn’t have a floppy drive in my new server I had to use Linux (not that I object to using Linux, but I’d rather have had the technician do it all for me). I used rescue mode from a Fedora 9 CD that was convenient, mounted a USB stick that I had used to store the BIOS update, and then ran it. The Dell service was quite good, on-site service and the problem was fixed approximately 27 hours after I called them. Replacing a couple of DIMMs is hardly a test of skill for the repair-man (unlike the time in Amsterdam when a Dell repair-man swapped a motherboard in a server with only 20 minutes of down-time). So I haven’t seen evidence of them doing anything really great, but getting someone on-site close to 24 hours after the report is quite decent, especially considering that I paid for the cheapest support that they offer. When I got it working I was a little surprised by the memory speed, I had hoped that a new 2GHz Opteron would perform similarly to an Intel E2160 and better than an old Pentium-D (see the results here [2]). Also the memtest86+ run took ages on the step of writing random numbers (I don’t recall ever seeing that step on previous runs, let alone having a system spend half an hour doing it). It seems that the CPU (Opteron 1212) doesn’t perform well for random number generation. In terms of actual operation all I’ve done so far is to install Debian. The process of installing Debian packages was quite fast (even with a RAID-1 reconstruction occurring at the same time) and the boot time is also very quick. The hard drive “rails” seemed a little flimsy. The way they attach to the drive is that they have screws that end in pins, so you screw them into plastic and the pins just sit in the holes in the drive where screws normally attach. I think that it would make more sense to have them not screw onto the plastic and instead screw onto the disk. Then if the plastic part that connects the two sides was to break it would still be usable. In fact they could just make the “rails” be separate rails as most other manufacturers do. One thing that surprised me was the lack of PS/2 keyboard and mouse ports. I had expected that such ports would last longer than serial ports and floppy drives. However my Dell has a power connector for a floppy drive and has a built-in serial port (with some BIOS support for management via a serial port - I have not investigated this because I always plan to use a keyboard and monitor). Of course I expect that most other machines will start shipping without PS/2 ports now and I will have to dispose of my stockpile of PS/2 keyboards and mouses. I generally like to keep a few on hand so that I can give friends and relatives a chance to try a selection and discover which type suits them the best. But I probably don’t need a dozen of them for that purpose. While a comment on my previous post noted that the floppy drive bay can be used for another disk, it seems that a disk is not going to fit in there easily. It looks like I might be able to install a disk there from the front if I unscrew the face-plate - but that’s more effort than I’m prepared to exert for testing the system (for production I will only have two disks). In terms of noise, the Dell seems considerably better than a NEC machine which was designed for desktop use. Of course it’s difficult to be certain as part of the noise is from hard disks and one of the disks I’ve installed in the Dell is a WD “Green” disk and the other may have newer technology to minimise noise. Also the mounting brackets for disks in a server may be better at damping vibrations than screwing a disk to the chassis of a desktop machine. Finally the NEC machine does seem to make more noise now than it used to, so maybe it would be best to compare after a few months use to allow for minor wear on the moving parts. I was initially going to run Debian/Etch on the machine. But as Debian didn’t recognise the built-in Ethernet card and the Xen kernel crashed when doing intensive disk IO I was forced to use CentOS. CentOS 5.1 didn’t start my DomU’s for some reason (which I never diagnosed) but CentOS 5.2 worked perfectly. Finally I was shocked when I realised that the Dell has no sound hardware! When the CentOS post-install program said that it couldn’t find a sound device I thought that meant that it didn’t support the hardware (it’s the sort of thing that sometimes happens when you get a new machine). But it actually has no sound support! It seems really strange that Dell design a desk-side server (which is quiet) and don’t include sound support. If nothing else then using something like randomsound to take input from the microphone line as a source of entropy is going to be useful on servers. While the seven USB ports initially seemed like a lot, being forced to use them for keyboard, mouse, and sound (if I end up using it on a desktop) means that there would only be four left.

• [1] http://etbe.coker.com.au/2008/06/26/dell-poweredge-t105/


• [2] http://doc.coker.com.au/computers/ram-speed-memtest86/

Share This

Late last year, I spent some time disentangling aptitude's internal UI library and packaging it as a separate library, which I named cwidget. This article is the first in what will hopefully become a series describing the basic concepts and APIs of cwidget. It applies to the versions of cwidget currently available in Debian sid and lenny, 0.5.11-1 and 0.5.12-1. Autogenerated documentation of cwidget can be found here (but beware that as of this writing it is somewhat incomplete).

---

In this tutorial, I will walk through a simple program (hello.cc) that initializes cwidget, displays a simple message box, and then terminates the program when the user confirms the message. I assume a basic familiarity with C++. The first thing to do is to include the portions of cwidget that our program will use. Most importantly, we need the top level cwidget routines. These are the global routines that initialize cwidget, shut it down, and control its main loop (among other things).

#include <cwidget/toplevel.h>

cwidget comes with a collection of stock dialog boxes for things like displaying messages to the user. To access the routines that build these dialogs, we write:

#include <cwidget/dialogs.h>

All the symbols provided by the cwidget library are in the cwidget namespace. Using the full library name means that there's a reasonable chance that its names will not conflict with the names provided by other libraries; however, it's a real pain to type cwidget over and over. Since this is the only namespaced library we are using in this program, it's handy to define cw as an alias for cwidget:

namespace cw = cwidget;

Now we're ready to write the main routine. The first interaction of client code with the cwidget library is to initialize it. This will initialize the ncurses library and put the terminal into a mode suitable for a full-screen curses program.

cw::toplevel::init();

Next, we create a dialog box that will be displayed to the user. There are two things to note about this code:

1. cwidget is Unicode-aware and the ok() routine expects the message string to be a wide-character string. In this case, that means that we need to pass in a wide-character string (indicated by typing L in front of the string).
2. The second argument tells cwidget what to do when the ok button is pressed. The expression

     sigc::ptr_fun(cw::toplevel::exitmain);
   

   creates a slot using libsigc++. Briefly, a slot is a reference to a function or to a method of a class instance. When invoked, this particular slot will call cwidget::toplevel::exitmain(), which causes the main cwidget loop to exit. The slot is wrapped in cwidget::util::arg, a utility function that handles passing slots as optional arguments.

cw::widgets::widget_ref dialog =
    cw::dialogs::ok(L"Hello, world!",
                    cw::util::arg(sigc::ptr_fun(cw::toplevel::exitmain)));

Now that we have a widget, the next step is to arrange for it to appear on the terminal. In cwidget, control of the terminal is assigned to a single top-level widget: whatever it displays is what gets displayed on the terminal, and all user input is passed directly to it. In a real program this widget will typically manage a collection of sub-widgets and assign each one a screen region, but for now let's just display the dialog box we created:

cw::toplevel::settoplevel(dialog);

With everything initialized, we're ready to start the main loop. mainloop() will keep the display up-to-date and dispatch incoming events (for instance, keystrokes and mouse presses) until exitmain() is invoked.

cw::toplevel::mainloop();

When the user presses Enter or clicks on the Ok button in the dialog, exitmain() will be invoked by the binding that we set up earlier. Once this happens, we need to shut down cwidget in order to restore the terminal to its original state. If you skip this step, the terminal will be garbled and will not work properly when your program exits.

cw::toplevel::shutdown();

And that's it! To compile the program, change to the directory containing hello.cc and run:

$ g++ -o hello hello.cc $(pkg-config --cflags --libs cwidget)

Of course, you'll need to have the g++ and libcwidget-dev packages installed for this to work!

My Dell PowerEdge T105 server (as referenced in my previous post [1]) is now working. It has new memory (why replace just the broken DIMM when you can replace both) and a new BIOS (Dell released an “Urgent” update yesterday that fixes a problem with memory timing and Opteron CPUs). The BIOS update can be installed from a DOS executable (traditionally done from a floppy disk) or an i386 Linux executable. As I didn’t have a floppy drive in my new server I had to use Linux (not that I object to using Linux, but I’d rather have had the technician do it all for me). I used rescue mode from a Fedora 9 CD that was convenient, mounted a USB stick that I had used to store the BIOS update, and then ran it. The Dell service was quite good, on-site service and the problem was fixed approximately 27 hours after I called them. Replacing a couple of DIMMs is hardly a test of skill for the repair-man (unlike the time in Amsterdam when a Dell repair-man swapped a motherboard in a server with only 20 minutes of down-time). So I haven’t seen evidence of them doing anything really great, but getting someone on-site close to 24 hours after the report is quite decent, especially considering that I paid for the cheapest support that they offer. When I got it working I was a little surprised by the memory speed, I had hoped that a new 2GHz Opteron would perform similarly to an Intel E2160 and better than an old Pentium-D (see the results here [2]). Also the memtest86+ run took ages on the step of writing random numbers (I don’t recall ever seeing that step on previous runs, let alone having a system spend half an hour doing it). It seems that the CPU (Opteron 1212) doesn’t perform well for random number generation. In terms of actual operation all I’ve done so far is to install Debian. The process of installing Debian packages was quite fast (even with a RAID-1 reconstruction occurring at the same time) and the boot time is also very quick. The hard drive “rails” seemed a little flimsy. The way they attach to the drive is that they have screws that end in pins, so you screw them into plastic and the pins just sit in the holes in the drive where screws normally attach. I think that it would make more sense to have them not screw onto the plastic and instead screw onto the disk. Then if the plastic part that connects the two sides was to break it would still be usable. In fact they could just make the “rails” be separate rails as most other manufacturers do. One thing that surprised me was the lack of PS/2 keyboard and mouse ports. I had expected that such ports would last longer than serial ports and floppy drives. However my Dell has a power connector for a floppy drive and has a built-in serial port (with some BIOS support for management via a serial port - I have not investigated this because I always plan to use a keyboard and monitor). Of course I expect that most other machines will start shipping without PS/2 ports now and I will have to dispose of my stockpile of PS/2 keyboards and mouses. I generally like to keep a few on hand so that I can give friends and relatives a chance to try a selection and discover which type suits them the best. But I probably don’t need a dozen of them for that purpose. While a comment on my previous post noted that the floppy drive bay can be used for another disk, it seems that a disk is not going to fit in there easily. It looks like I might be able to install a disk there from the front if I unscrew the face-plate - but that’s more effort than I’m prepared to exert for testing the system (for production I will only have two disks). In terms of noise, the Dell seems considerably better than a NEC machine which was designed for desktop use. Of course it’s difficult to be certain as part of the noise is from hard disks and one of the disks I’ve installed in the Dell is a WD “Green” disk and the other may have newer technology to minimise noise. Also the mounting brackets for disks in a server may be better at damping vibrations than screwing a disk to the chassis of a desktop machine. Finally the NEC machine does seem to make more noise now than it used to, so maybe it would be best to compare after a few months use to allow for minor wear on the moving parts. One interesting feature is the Broadcom Gig-E port on the motherboard, it supports iSCSI as a boot protocol which is an interesting alternative to PXE, so if you have a server attached to a SAN via iSCSI you can use the same protocol for booting. There is a USB port inside the case (for permanently attached USB devices), however the USB boot option states that it is offering the option to boot from front USB ports - and it claims that no operating system is found on the USB stick that I use to boot my Thinkpad. The down-side is that the bnx2 module in the Debian/Etch kernel doesn’t seem to work with it. I want the machine to have three Ethernet ports, I have a two-port PCI card and if I can get the port on the motherboard to work then I’ll have enough. Otherwise I need to buy a PCIe Ethernet card (the machine only has one PCI slot). I ended up installing CentOS on the machine after the Debian/Etch Xen kernel started falling over on disk IO load (a problem I had seen on another Debian/Etch 64bit Xen machine). CentOS 5.1 supports the built-in Ethernet device, but didn’t work correctly with Xen (my DomU’s would just hang or abort). CentOS 5.2 is now working correctly.

• [1] http://etbe.coker.com.au/2008/06/26/dell-poweredge-t105/


• [2] http://doc.coker.com.au/computers/ram-speed-memtest86/

Share This

After I arrived at home after work today I noticed that the machines at my parents home network were all down and just recovering from the outage. Two of my m68k autobuilders are located there. Nothing serious, I thought, because the machines are located behind DSL and maybe there was a short DSL outage.
Some minutes later I received two mails from my UPS that there was a power outage. Well, this explains the DSL outage as well, because the DSL is not attached to the USV (located in a different room).

Thu Jul 03 17:56:19 CEST 2008 Power is back. UPS running on mains.
Thu Jul 03 17:56:19 CEST 2008 Mains returned. No longer on UPS batteries.
Thu Jul 03 17:46:49 CEST 2008 Running on UPS batteries.
Thu Jul 03 17:46:43 CEST 2008 Power failure.

Ten minutes of power outage without machines being shutdown. It's a APC UPS BR800I with 3 machines (2x m68ks, 1x PIII@550), a SCSI hardware RAID with 7 disks and a 8 port switch hooked up to it. I'm really glad that I bought the UPS earlier this year - exactly for this purpose and to prevent filesystem errors on the buildds when there is a power outage. :-)

I already mentioned a few times in the blog that I’m working on a Debian package of the Conkeror web browser. And now, after a lot of fine-tuning (and I still further new ideas how to improve the package ;-) Conkeror is finally in the NEW queue and hopefully will hit unstable in a few days. (Update Thursday, 03-Jul-2008, 18:13 CEST: The package has been accepted by Jörg and should be included on most architectures in tonight’s updates.) Those who could hardly await it can fetch Conkeror .debs from http://noone.org/debian/. The conkeror package itself is a non-architecture specific package (but needs xulrunner-1.9 to be available), and its small C-written helper program spawn-process-helper is available as package conkeror-spawn-process-helper for i386, amd64, sparc, alpha, powerpc, kfreebsd-i386 and kfreebsd-amd64. There are no backported packages for Etch available, though, since I don’t know of anyone yet, who has successfully backported xulrunner-1.9 to Etch. Interestingly the interest in Conkeror seems to have risen in the Debian community independently of its Debian packaging. Luca Capello, who sponsored the upload of my Conkeror package, pointed me to two blog post on Planet Debian, written by people being fed up with Firefox 3 already and are looking for a more lean, but still Gecko based web browser: Decklin Foster is fed up with Firefox’ -eh- Iceweasel’s arrogance and MJ Ray is fed up with Firefox 3 and its SSL problems. Since my previously favourited Gecko based web browser Kazehakase never became really stable but instead became slow and leaking memory (and therefore not much better than Firefox 2), I can imagine that it’s no more an candidate for people seaking for a lean and fast web browser. Conkeror has some “strange” concepts of which the primary one is that it looks and feels like Emacs:

• The current location is shown in a status bar below the website, where Emacs usually shows buffer names. All input, even entering new URLs to go to, is done via the mini-buffer, an input line below the status bar.
• Instead of tabs it uses Emacs’ concept of buffers. So no tab bar clutter and though easy access to all currently open pages.
• It has no buttons, menu-bar or such. And except the status bar and mini-buffer, it uses the whole size of the window for the displayed web page. This is the main reason why I prefer Conkeror on the 7” EeePC: I don’t want to waste any pixels for buttons or menu bars and still have a fully functional web browser.
• It of course has Emacs alike keybindings (with a slight touch of Lynx). While this may seem awkward for the vi world (Hey, they have the vimperator^*, also in Debian since a few days!), as an Emacs user you just have to remember that you web browser now also expects to be treated like an Emacs. It just works:

  C-x C-c

  Exit Emacs -eh- Conkeror

  C-x C-f

  Open File -eh- web page in new buffer

  C-x C-b

  Change to some other tab -eh- buffer

  C-x C-v

  Replace web page in this buffer and use the current URL as start for entering the new one

  C-x 5 2

  Open new frame -eh- window

  C-x 5 0

  Close current frame -eh- window

  C-x k

  Close tab, -eh- kill buffer

  C-h i

  Documentation

  C-s

  Incremental search forward

  C-r

  Incremental search backward

  C-g

  Stop

  l

  Go back (Think info-mode)

  g

  Go to (Open web page in this buffer)

  (Hehe, I like the faces of vi users having read these keybindings and now wondering how to remember them. SCNR. Well, sometimes vi key bindings are a mystery to me, too. :-) There are of course many more and nearly all are the same as in Emacs, even the universal argument C-u and the M-x command-line are there. E.g. C-u g lets you open a web page in a new buffer, too.
• Conkeror also has very promising concept for following and copying links with the keyboard only. Opera is very inefficient here since you have to jump from link to link to get to the one you want. In Conkeror you just press f for following or c for copying links and then all links on the currently shown part of the page show a small number attached to it. Then you just enter the number (and additionally press enter if the number is ambigous) and the link is either opened or copied to the clipboard. A funny anecdote about how this concept grew over the time: Early versions of Conkeror (back in the days when it just was a Firefox externsion as vimperator) numbered all links on the page, not only the visible ones. On large pages with many links or buttons (e.g. my blog ;-), this took minutes to complete. The idea to just number the visible links is so simple and important – but someone first needed to have it. :-)

Footnotes *) I just noticed that there is now also muttator, making Thunderbird look and behave like vim (and probably also mutt), too. Wonder into which e-mail client the Emacs community will convert Thunderbird. GNUS? RMAIL? VM? Wanderslust? What will it be called? Wunderbird? Thunderslust? (SCNRE ;-)

This is the third installment of my article about the Serial Console Server for the Poor. First installment here, Second installment here. The first part of the article having covered the hardware and the udev part creating the device nodes, and the second part explaining how to solve the software part using ser2net, this part explains why ser2net was ditched in favor of cereal and how the console server operates with cereal now. Cereal (which I was pointed to on IRC as a reaction to article II) is a nifty combination of runit’s runsv and screen. One of the less-known features of screen is that screen can also connect to a serial port instead of a “real” console. cereal makes use of this feature, putting up with the fact that screen can only set a baud rate. I have not seen a serial application with other parameters than 8n1 (8 data bits, no parity, 1 stop bit) in a decade, so I cannot comment whether this is a real disadvantage. I guess that it might be possible to set the serial port to the desired set of parameters before starting up screen, but I didn’t actually try it since I do not need it. Cereal uses a set of configuration parameters and processes called a “session” to associate a serial port with a baud rate and a set of user/group settings to control who is able to start, stop, attach or detach a session. It doesn’t have a “real” configuration file. Instead, it has an admin program, cereal_admin, which takes the parameters associated with a session and writes them to an (intentionally? undocumented?) set of config files in /var/lib/cereal. Only a single user is able to attach to a session read/write, while an entire group can attach to a session read-only and can thus access the logs. A session is automatically started when the sysem boots and can be stopped and started using cereal_admin as well. Once a session is running, a specially configured screen process runs attached to the serial port, and users simply attach and detach to and from it as one would to a normally running screen. That way, one can scroll back and examine what was shown on the serial port while nobody was attached. This is quite handy when the device connected to the port prints out warnings, errors and status information to its serial port. The screen configuration that is used is rather sophisticated. So, a permanent log file is written, which is also used for read-only access to the serial session. Also, a very informative status line is configured. Unfortunately, one of screen’s biggest disadvantages applies here as well: User X cannot attach to a session started by User Y unless Y has access privileges for X’s pty (or vice versa, I never can remember), which can be a security risk. Additionally, it is not possible to su or sudo to X and then to attach to the session - one needs to have the original pty opened by the correct user, which usually means that one needs to do a “real” log in with the correct account (via /bin/login or sshing in to the box). If one has the privileges necessary, one can use the cereal executeable to attach to the screen (which gives read-write access) or to tail -F the log file (giving timestamped read-only access). That way, one never knows that one is actually working with an appropriately configured screen that is kept running by runit. The restrictions coming with cereal suggest a setup similiar to what I did with ser2net previously: Each session has its own user account, which forces an attach to the appropriately named cereal shell on login:

my-device-name:x:1801:1801:my-device-name,,,:/home/my-device-name:/usr/local/sbin/cerealshell

$ cat /usr/local/sbin/cerealshell
#!/bin/bash
set -eu
cereal attach $(id --user --name)
$

You can see that I decided to name the sessions after the actual device name, allowing the unterlying ttyUSB device name to change without change in the user interface. The actual users and sessions were created with a small shell script:

#!/bin/bash
createconsole()  
  NAME=“$1”
  PORT=“$2”
  BAUD=“$3”
  MUID=“$ PORT/USBserial/180 ”
  echo sudo addgroup --force-badname --gid $MUID $NAME
  echo sudo adduser --force-badname --gecos “$NAME,,,” --ingroup $NAME --uid $MUID --disabled-password
$NAME
  echo sudo adduser $NAME dialout
  echo sudo mkdir -p /home/$NAME/.ssh
  echo sudo chmod 755 /home/$NAME/.ssh
  echo sudo touch /home/$NAME/.ssh/authorized_keys
  echo sudo chmod 644 /home/$NAME/.ssh/authorized_keys
  echo sudo chown $NAME:$NAME /home/$NAME/.ssh /home/$NAME/.ssh/authorized_keys
  echo sudo cereal-admin create $1 /dev/$2 $3 $1 $1
  echo sleep 2
    echo sudo cereal-admin start $1
  echo echo -----
 
createconsole my-device-1 USBserial1 9600
createconsole my-device-2 USBserial3 115200

Note that the script also uses a hardcoded UID range which might need adaption to your local needs (and breaks for more than ten serial ports), and that it also takes care of creating an empty authorized_keys file with correct permissions. That way one can simply ssh to my-devlce-1@consoleserver and find oneself immediately connected to the serial console, seeing the last things that happened on the serial port, and immediately being able to work with the device. That’s fine, comfortable and useable. I actually like that better than what I built with ser2net previously.

I have just watched an interesting lecture by Steven Levitt about car safety for children in the 2-6 age range [1]. The evidence he presents shows that the benefits for children in that age range are at best insignificant and that in some corner cases (EG rear impacts) the child seat may give a worse result than an adult seat belt! He advocates a 5-point harness [2] for children in the 2-6 age range that is based on a standard adult seat and seems to be advocating a child “booster seat” integrated into the adult seat (which approximates the booster seats offered by some recent cars such as the VW Passat). He has a picture of a child in a child-sized 5-point harness to illustrate his point. But one thing that should be considered is the benefit of a 5 point harness for adults. Race car drivers use 5 point harnesses, I wonder how the probability of a race car dying during the course of their employment compares with the probability of an average adult dying while doing regular driving. I also wonder how a 5 point harness compares to a three point harness with a pre-tensioner, it seems quite possible that a 5 point harness would be cheaper and safer than the 3 point harness with pre-tensioner that is found in all the most expensive cars manufactured in the last few years. He believes (based on tests with crash-test dummies) that part of the problem is that the child seat will move in an accident (it’s attached to a soft seat). It seems that one potential solution to this is to have child seats that firmly attach to some solid part of a vehicle. I had previously suggested that child seats which replace existing seats as an option from the manufacturer would be a good idea [3]. But there is a good option for making better child seats for existing vehicles. It is becoming common in the “people mover” market segment to design vehicles with removable seats. For example the Kia Carnival has three seats in the middle row which are removable and which attach to four steel bars in the floor. It should not be difficult to design a child seat which attaches to those bars and could therefore be plugged in to a Carnival in a matter of minutes. The Carnival is designed to have the mid row seats installed or removed easily and safely by someone who is untrained, while for comparison it is recommended that a regular child seat should only be installed by a trained professional (IE your regular mechanic can’t do it).

• [1] http://www.ted.com/talks/view/id/30


• [2] http://en.wikipedia.org/wiki/Seat_belt#Five-point_harnesses


• [3] http://etbe.coker.com.au/2007/12/22/a-better-design-for-child-seats/

Share This

Debian 4.0 version of Ruby is open to the, now widely known, Ruby security vulnerabilities. The bug is reported as 487238 in Debian s BTS, and is closed, since the version now in sid (version 1.8.7.22-1) is already fixed. Users of stable can apply the patch provided by Daniel Franke (it doesn t seem to fix all, but goes a long way). Apparently, this brought up (again) the rants over full disclosure. Indeed, what is vulnerable is not that hard to find, as Zed Shaw showed us, so, why not talk about it in a plain and bold form? Why just provide the CVE numbers and ask for everybody to upgrade? Zed goes more deep about the quality of C code, but that is not the issue I want to talk about As a Free and Open Source Software supporter (and developer), I can see the benefits of full disclosure. As a not-full-time webmaster, I can see the benefits of not having a proof-of-concept piece of code attached to the vulnerability report. Of course, there s a lot of things a webmaster can do to prevent having a machine completely compromised in case a security advisory is published with a proof-of-concept code in it (think about chrooting, randomized memory protection, security libraries, grsecurity, SELinux, etc) and my machines, although vulnerable to the bug, would not be fully compromised if exploited. I guess one should be prepared to whatever comes from the Internet Full disclosure, in this sense, have more pros than cons, IMHO. For instance it was not clear if Debian 4.0 were vulnerable There were no security advisory coming from Debian (and there s still not), and it is not promptly obvious if the version packaged is affected. I know that at least I wanted to run a proof-of-concept to check if my server is vulnerable or not before going all the way into packaging a fix (or backporting the sid version), and it was not until I read Matasano Chargen Blog that I could test older versions. But different people have different ideas

I promised to post some updates about how the Aptitude project would be going so here it is. Here’s what aptitude-gtk currently looks like : Well, nothing very special right now. It’s really only a testing interface. The final GUI will probably be different. Now you may be interesting by what’s going on behind it ? Where to start ? Aptitude is written in C++ with varying dosages of OO coding depending on the age of the code :). For the most part, the code is neat, clean and easy to understand. Sometimes, it’s overengineered: the code that implements the progress status of packages downloads and actions is exhaustive enough to cover the setup phases of a hydraulic dam, although sometimes you can still see progress bars mysteriously going backwards. Sometimes, Daniel Burrows will be happy to provide you with complimentary barf bags while explaining some ungodly oddities that have existed for years because it’s easier to remember the ritual dances to do than to make stuff behave logically. Currently Aptitude-gtk is able to execute the libapt-pkg initialization phase, load up repository lists and update lists (think “aptitude update”). The next big task will be to load up the installed packages list and display it. It involves quite a lot of code because of all the things that connect to it : incremental package searches, sorts, filters and so on. It’s been very interesting so far. By the way, the minesweeper feature is already implemented, courtesy of gnomine

While digging what was happening in bug #473557, I happened to get just in the right place of Iceweasel’s code to fix the longstanding issue of it proposing “less” and other terminal-only applications as helpers for some MIME types. The upstream bug is 6 years old. The fix is 3 lines. One of these lines is “ ” It will be in next xulrunner upload to unstable.

Newegg.com just had a special on 750Gb Seagate SATA drives, so I thought it might be a good opportunity to replace my 400Gb IDE drives with ones that can be connected to the host by something less ghetto than IDE to USB 2.0 adapters. Who knows? I might even lash out on some kind of enclosure, instead of sitting them on cork trivets on top of the computer they're attached to. So once the drives turn up, all I'll need to do is replace the PCI 4 port USB 2.0 controller with a PCI 4 port eSATA controller. I'm a total SATA ignoramus, so if anyone has any suggestions on what's good, or what to avoid, shoot me an email.

In this Free Software movement we have many mottos - One of which, describing what motivates us to work writing code, is scratch where it itches.
Of course, I could not keep it to myself - Almost a week ago, I took part of the World Naked Bike Ride. What I didn't tell you... Is that it became obvious I cannot reach most of by back - And it's because I'm mostly careless. When the WNBR started, it was still quite cloudy, even starting to rain... so I was mostly careless.
If you opened the newspaper PDF I attached to my previous post, you'll surely remember (not an easy sight to get out of your head, I guess) I had painted on my back "Veh culo libre de emisiones" - Emissions-free vehicle (and yes, it's strictly true: My bike is zero emissions. The animal riding it might not be... But that's a different story). Add incomplete sunblock to the equation, and...

Were it not for the poor lighting conditions under which I took the photo, you'd clearly appreciate the words "libre de" on my back.
And... Well, one week later, my freedom itches.
Badly.

How to autologin X without a display manager Problem: configure a custom Debian box used to drive some industrial machinery. The system should boot directly into the GUI control application, that runs full screen, with root privileges. Everything should respawn if X is killed or the control application dies. In theory, you'd run an X display manager with autologin, then run matchbox-window-manager and the control application as the X session. You wish. At the end of the post is an explanation of why this way failed. So, here is how to get the whole thing to work, without a display manager. Use init to drive the whole thing:

6:23:respawn:/sbin/getty -L -n -l /usr/local/sbin/autologin

This will respawn everything if it dies, stop respawning if it dies all the time, avoid starting it in single user mode, and not ask for a username. /usr/local/sbin/autologin contains:

#!/bin/sh
/bin/login -f root MAINAPP=true

This will autologin as root, setting an extra env variable. Then comes root's ~/.bash_profile, that just starts X if we are doing autologin:

if [ "$MAINAPP" = "true" ]
then
    startx
    logout
fi

If the application was running as a special user, we could have made things simpler and just used startx as the shell for that user; however, we still want root to have bash as the shell, and the above hack does it. Finally, root's ~/.xsession:

#!/bin/sh
matchbox-window-manager &
# If the touch screen is not calibrated, run the calibration
while [ ! -f /etc/touchscreen-calibration ]
do
        calibrate-touchscreen
done
# Run the main application: if it ends, the session ends
main-application

And there we go, no dependencies at all. Why not using a display manager gdm and kdm seem to do autologin, but their dependency list is not acceptable for something that should just respawn an X server in an industrial system that must be kept simple. xdm on the other hand has a small set of dependencies, but its developers seem to have decided that autologin is a ""glitz", and there is no need for it in such a bare-bones display manager". Dict for "glitz" gives "tasteless showiness". What one has to bear... wdm seems however even more disconcerting, as it "doesn't actually support autologin but you can set the default user and default password in /etc/X11/wdm/wdm-config. Now, [...] you only need to press Enter twice [...] to login". Figure how this would look in the manual: "After powering up the unit, attach a USB keyboard and press enter twice to start the system". And this is why we are not using a display manager.

I have this IPv6 issue with my ADSL. It's kinda bizarre and I'd be interested in whether anyone has any ideas or has seen anything similar themselves.

I don't get IPv6 packets smaller than 71 bytes (excluding the PPP header).

Small IPv4 packets? No problem. Sending small IPv6 packets? Also fine. Getting them back again? No go.

I first noticed the problem because I couldn't get to Google's IPv6 site. I ended up getting some quite useful help from various Google engineers, who were prepared to take my report seriously even though I'm just an end user these days. I've promised to get back to them with what the problem was when I find out. If.

My ADSL is provided by Enta, through a reseller. My parents also use them, but via a different reseller. My understanding is this shouldn't make a difference, as Enta are responsible for terminating the connection in both cases. On my parents' line IPv6 seems to work fine. They have a Linux box with a Conexant based PCI card. I have an AR7 router running OpenWRT. My first thought was that it might be some weird hardware issue, so I dug out my Speedtouch, hooked it up to my laptop and tried that. Still no small packets. I tried a different AR7 ADSL router. I downgraded to a 2.6.16.x kernel (which is what my parents are on). All gave the same results; anything over 70 bytes would get through fine, anything under wouldn't.

So I took my router to my parents'. I unplugged their kit and plugged the router in, with only my laptop attached. I left it configured with my username/password. And it worked. Small packets came though fine. To make absolutely certain I tried the same thing again at home. And it didn't work.

Now. Exactly the same kit at my end in both instances. Exactly the same ISP at the other end (who confirm all their end points are configured identically and even if they're not I'd have expected to get a duff one at my parent's once or twice and a working one at my end given the number of reconnections I've made over the period of trying this all out). That leaves BT as the variable (we're about 100 miles apart, so very different exchanges).

My questions to you, the reader:

• Does this line of logic seem reasonable? If not, what have I missed?
  
• Have you ever heard of anything similar? I know BT used to have an issue with IPv6 and PPPoE and corruption of the packet length field, but I'm using PPPoA (I've tried PPPoE as well and it wasn't any better).
• Is there an ATM packet sniffer for Linux, along the lines of Wireshark? If I could hook up the Speedtouch to my laptop and try a connection while sniffing the ATM packets I could see if there was any corruption or oddities happening at that level, which might provide a clue.

Update: will-h has pointed out it's 70 bytes excluding the PPP header, not including it.

I was like “wtf?!”. Debian.org replaced by a link farm ? debian.org being actually domainsquatted is highly unlikely, so I started searching how this could happen. First, a little explanation of the setup :

• I’m on a bullet train on my laptop, up-to-date Debian Lenny, 2.6.24
• My laptop is connected to a 3G+ (HSDPA in the US) PDA phone with a USB cable
• The phone appears to the computer as a network interface thanks to the usb-rndis-lite kernel module
• The phone does NAT routing between my computer (192.168.0.100), himself (192.168.0.1) and a restricted network from my phone operator
• The only host visible on this restricted network is a HTTP only proxy server that checks the user agent (Nokia is OK, Firefox means GO AWAY)
• I connect through this proxy to a dedicated host through a OpenVPN tunnel masquerading as HTTP with a Nokia user agent
• The dedicated host at the other side has special iptables rules to redirect requests coming from my mobile phone operator netblock on port 80 to the regular OpenVPN port.
• The dedicated host does NAT for my computer to the real Internet.
• The total latency varies from 120ms to 30 secs and the bandwidth from 2mbps to 8kbps depending on the coverage
• The only DNS server on my laptop is set in resolv.conf to 192.168.5.1, the remote OpenVPN endpoint, the dedicated server
• The dedicated server runs Bind and provides recursive resolution

Now there are some peculiarities to the situation :

• It happens exactely once a week on the train from my home in Paris to the campus in Grenoble
• It doesn’t happen the other way around or at any other time for that matter

Some hints :

• My hostname at home is aeris.home.eu
• My hostname on campus is aeris.liuo.res.rhb
• I almost never shut down my computer, only hibernate
• Jonathan Roes

Now for the challenge : how could this happen ?

Coding and posting on a bullet train, while reading documentation on the net through a 3G wireless connection. On the laptop is a proof of concept Aptitude GTK+ demonstration.

(Playing Kraftwerk - The Telephone Call.) Warning: This is a long-wound complaint post. The only reason this is going to the Planet is because I have no method yet of disabling individual posts for syndication. Please skip, with my apologees for the noise, if you don’t want to listen to complaining. May contain nuts. May drive you nuts. Drove me nuts. Mmm, pistachio. When I was around 11, I got my first cellphone. I was very proud. This was back when being 11 and having a cellphone was a real novelty; pagers were still being sold, and the NMT network was still running. Like many things I appreciate, I found it in a dumpster. It was ancient, even then: a Motorola MicroTAC brick, missing its antenna. I borrowed one of my grandmother’s hairpins, and voila, working phone - as long as you didn’t leave Oslo. It had a certain cyberpunk look to it, even then: I loved it. I remember that I first bought a NetCom pay-as-you-go card; I don’t quite remember the number, but it had “283″ in it at the end, if you want to wardial. For some reason, Dad needed a SIM card so I gave him mine. So I bought myself a new one, a Telenor card, pay-as-you-go, number 91 85 95 08. I must have been around 12 at the time. And that number served me very well. Fast-forward 6 years, to late March, 2006. I had just turned 18, and one of the first things I wanted to do was get a massively cheaper, proper subscription. I’d been procrastinating it for a bit - as I am wont to - but when a nice gentleman at the subway station told me about a nice new company called SEA Norway and their wonderful prices, I accepted. Big mistake. Here begins the saga of woe… For a good while, I was very happy with their service - even though GPRS data never worked, I never used it anyway. Their name changed to Vitel somewhere along the way. I received a phone call from an enthusiastic salesman who told me how much cheaper Vitel’s power subscription is. It seemed very reasonable, so I went for it. One of the arguments he gave me was that I could collect all those utilities into one bill. I told him that I couldn’t have this: Since I’m a live-alone student, my power bill is covered entirely by the city council, so I need a proper bill to hand over every month. “Sure, that’s no problem”. I check and double-check that, and I stress it. Sure, no problem. OK, deal. Big, big mistake. They draw 2700 Kroner from my account, using the automated pay system (AvtaleGiro) that I had set up for the phone bill. 2700 Kroner (530 US Dollars) is a lot of money, especially when your monthly income, 5000 Kroner (1000 US Dollars) barely covers the necessities. So I cancel the autopay system. (I still have not received that money!) 23rd of January, my subscription is cut, since I hadn’t paid the bill. They hadn’t mailed it to me, and I’d told them I’d cut the AvtaleGiro, but I simply did not receive the bill. So I call them up in February some time and try to figure out a solution. “You didn’t pay the bill, so the subscription is closed.” -”So if I pay the bill, will you reopen it?” -”No, sorry. It is closed now.” -”So then I’ll have to transfer the number to another provider?” -”No, you can’t do that; it’s closed now.” -”You can’t refuse to transfer the number, that’s simply not legal.” -”Sure it is, the subscription’s been closed.” Urgh. So some time in the middle of March, before The Gathering, I call NetCom up: I want to transfer my number to them, please. Sure, no problem. No, this number is registered as active in our system. All is well. We’ll make the switchover on March 28th, and you will get your SIM card in the mail: It should be in your box by then. Fantastic! The 28th of March came and went with no great ceremony, not even a SIM card. No switchover occurred. I give them the benefit of the doubt for more than a fortnight. Some time in April, then, I get sufficiently annoyed to call them up and ask what had happened. “Oh, no, it seems Vitel is using the old transferral system”. -”OK?” -”Yes, you will have to send us a form with your signature by fax to carry this transfer out.” -”Sigh, alright. Where can I get this form?” -”I’ll email it to you.” Great. So I get the form. May was very busy, so I didn’t get an opportunity to fill the form out, and by now I was getting fairly tired of the whole thing anyway! The thing that finally got me, however, was a bill from Vitel - on the “closed” subscription - for not only the monthly fee, but also several kroner of SMS “content services” (Read: ring tones) and GPRS data (Which never even worked even when the subscription did!) So last Tuesday, June 3rd, I send them the damned fax. Wednesday, June 4th, I call NetCom up and ask what the status is of my subscription. “Oh, yes, this is now active with us.” -”Really?!” (I was happy in the way that only someone who’s gone 5 months without a working phone could be.) -”Sure, we’ve sent the SIM card to Bekkeveien (something).” -”…Bekkeveien? But I’ve never lived at any Bekkeveien. My last name is Bekkedal, but..” -”Alright, then that’s probably a mistake. What you can do, though, is go to a NetCom dealer and pick up a new SIM card.” -”Perfect! I’ll do that, then.” (I stress “pick up” for a reason which will later become apparent.) Goodie. I’ll get a working phone! I was very happy as I took the tram down to Aker Brygge and looked everywhere for the damned NetCom dealer. Having finally found it, I happily stride inside and ask for a SIM card for my subscription. “Sure. That’ll be 200 Kroner.” Argh! I hadn’t brought enough money! She did say pick up. Oh well. Aker Brygge is a center of business, I’m sure there are other shops. So I ask to use one of their phones to call NetCom. Sorry, no phones you can use. Sigh. Fine. Do you know of any phone booths around? They didn’t, but I found one anyway, finally. I deposit the necessary $1 for a local call (See, this is the problem with having a cellphone company run the phone booths!) and dial NetCom customer service. They take my number and - Sorry, that number isn’t yet active, it’s still registered to Vitel. ARGH! Fine. So what’s standing in the way? Well, Vitel can’t refuse it - (thanks, I know that already) - but the form that I was sent wasn’t the right form. The form I need to send is from Vitel to Vitel, authorizing the transfer.While I’m trying to hold a conversation with the customer support guy, some drunk guy is accusing me of stealing phones, and begins reading out loud the sponsor company names on the back of my DebConf T-shirt. But Vitel has already told me that I cannot transfer this number, under any circumstance! They consider it closed! “Yes, but you have to talk to Vitel.” -”I have!” -”Well, we can’t really do anything…” Alright. So I hang up and I try to call Vitel. But that doesn’t work: They closed at 3 PM!. So finally tired of Netcom failing to port my number for a while, I call Telenor. I talk to a very cheerful and helpful lady who admits to not knowing about the particulars of that situation. Fantastic! At least she isn’t going to fib it! She says that she has a vacation Thursday, but she can call me back on Friday after discussing the matter with the number transfers department. Wow! She’s actually going to confer with the relevant expertise! This is too good to be true! So she said she’d call me back Friday at 1PM with a status update. As I am writing, it is Friday at 11:01, I am anxiously awaiting the telephone call. But now I get a funny SMS message:

From: NetCom Message from NetCom: Your number has been ordered by another operator. We would like to remind you that violation of the commitment period will be billed to the order of 1500 kroner. For questions, call 05050.

My subscription with Vitel was made in 2006, more than the 12 months I and knowledgeable friends believe to be the maximum legal commitment period (I doubt I would have agreed to more anyway!). Besides, the text message keeps saying that it’s from NetCom. So my deduction is: It’s from NetCom, who I have registered an active subscription and are now complaining that I’ve moved the subscription I’ve opened with them (but which they have not successfully moved from Vitel), over to Telenor. I don’t think this is an unfair conclusion. So I call NetCom customer service - which to NetComs infinite credit is a number you always can call, almost like 112 (technically it’s accomplished completely differently, but you get my point. The number is never blocked in a blocked subscription.) And they say it’s not from NetCom, even though it says it’s from NetCom. So I’ll keep both of my readers posted on the developing situation. At least the text message indicates that something is happening with my subscription. I just want the dialtone!

(Is this a network?) Terry Lane asked:

"Do you know of any reason why someone would suggest we consider placing blogs on more than one server? I think his main concern would be related to SEO and - I'm assuming here - Google."

There are some small reasons, mainly about various sorts of reliability: what if the server catches fire, what if someone filters out adverts from the server, what if the server gets labelled as a spammer or splogger, and so on... but I believe they're outweighed by ease of management and having all your site on one server. If the search engines label your IP address as a spammer, you can get another IP address as a short-term fix, but in general, the search engines are always a major threat to a blog-based business. If they label one server as a spammer, I think it would take the guys at google or whatever about 0.1 seconds to spot the link to another server. The best tactic is to avoid looking like a spam source in the first place... I guess if you're hosting several blogs on shared servers, like I do, splitting your blogs across several servers is a good idea for those reasons, which is part of why I do it... In any case, make sure you download backups in case your hosting goes like this:- The Planet (EV1) Data Center Catches Fire - 9000 Servers Offline If a blog becomes really popular, the usual tactics of mirroring and distributed load-balanced hosting can be used, but I don't think that was the question here. Even after all those, I can't think of any real killer reasons to split a blog across multiple servers if you're on your own dedicated server already. Have I missed a reason?