A recent thread which started on the Debian Release mailing list caught my eye this week. I attempted to aid the migration of this thread to the debian-ipv6 mailing list, which is really a better place for this and sorely in need of controversial topics for discussion. It is interesting how people can so blindly decide that broken things should be destroyed. Repair often appears not to be an option, even for a long-term, wide-reaching effort like this, though we are all working on open-source software! In this case there are an unknown number of less fortunate people in the world who are located behind some kinds of broken DNS infrastructure which discards 'AAAA' lookups. Of course 'AAAA' lookups are attempts to resolve a name to an IPv6 address, and the resolver in a 'modern' libc (i.e. one from the last five years or so :-) will try to retrieve an IPv6 address before it attempts to resolve a name as IPv4 with an 'A' lookup. That is how the standard is written, so if you want to comply with the standard you have to do it that way. Other things also interfere, but this element of the specified behaviour seems to cause the most annoying and pointless whingeing I have heard. I suppose that the people who want working IPv6 make it so, and do not have problems with this behaviour. But it seems that people who are behind this kind of broken DNS either disable IPv6, or they have to whine about IPv6 being turned on by default, and can't we please all go back to the good old days. What's wrong with IPv4 anyway? Doesn't NAT solve all of it's problems? Are we sure this new (heh!) technology is safe? Fortunately some people are so good at making their pain felt by other people that they can get other people to do their work for them. So Mithrandir has written a nice elegant patch for libc6 so that it won't do the IPv6 lookups unless you have a usable IPv6 configuration. I've filed bug #435646 against Debian to get this included, but Aurelian Jarno justifiably wants a few people to test it a bit harder... So I've taken the original patch and tweaked it to apply against current libc6 sources (2.6-5) and tested it for myself. It works as desired, as far as I can see, when comparing behaviour with an unpatched system. The patch is attached to the bug report, of course. Perhaps some other people out there can put a wee bit of CPU into testing this for other environments so that we can make life easier for those people with no time / inclination to use IPv6, to ensure that they don't just disable it because it is making life too painful for them in it's current form? How to build libc6 for fun and proft If you have appropriate deb-src URLs configured, and are running Sid, then the following will let you build a local copy of libc6 with the patch. This is probably better testing than if I just make my packages available (which are only i386 in any case).

apt-get build-dep glibc
apt-get source glibc
cd glibc-2.6
debian/rules unpack
cd build-tree/glibc-2.6
wget http://tinyurl.com/3xzm3o
patch -p0 <glibc-only-lookup-ipv6-if-it-makes-sense-debian.patch
cd -
dch --newversion 2.6-5+v6 "Apply IPv6 Resolver Sanity"
fakeroot debian/rules binary

Wait a few hours for it to build... Install... And then confirm that this only does 'AAAA' lookups if (when) you actually have a global or site scoped IPv6 address. When you only have a loopback or link local IPv6 address then you should only see 'A' record lookups. Step 3: profit! Whoops! I forgot the fun bit: please update the bug report :-) What the patch does In my opinion this is quite an elegant solution from Tolleff. He has picked a single characteristic of the IPv6 interfaces to further refine whether the IPv6 configuration of some interface is actually usable. With IPv6 it is much more common to have multiple addresses assigned to a single interface. Interfaces are automatically configured with a link-local address which is not globally routable, and the loopback interface is also configured with the IPv6 equivalent of 127.0.0.1 (which is "::1"). To get a usable IPv6 setup you will also end up with a more widely usable address. In most cases this will be a global address, meaning that it is (in theory) globally routable from other people who also have global addresses, or you could have a "site" address, which is the IPv6 equivalent of RFC1918 addressing. The patch considers that for the purposes of name resolution, it will be pointless to do AAAA lookups unless you have an address of the second kind. This means that people behind broken DNS won't be impacted unless the try and set up IPv6, and people who don't try and set up IPv6 won't get the 'hesitation' while their system attempts to resolve each address in IPv6 space first. It will also mean that when people start to enable IPv6 around them, their setup will continue to work correctly.

Today I’ve implemented a feature which was long overdue: making the table sortable by the available table headers. The second feature I’ve added is that every bug report now has it’s “Last Action” date. While both features are useful for themselves, combining both result in a very handy bug triaging tool. A few months ago when I was trying to help the KDE team on their bug triage, I’ve missed the feature to sort bugs by their date of the last action in our BTS since I’ve noticed that many of the very old bugs (last action-, not bug number wise) where already fixed or could be closed for other obvious reasons. The problem was just to find all those “stale bugs”. I was able to close dozens of old bug reports but it took much more time to find them, than to decide whether they’re still active or not. And since I hadn’t the tools available to find the “easy targets” on a quick way, I gave up after a few days. Today it’s just as easy as firing up rng and let it search for all bug reports belonging to the qt-kde team: rng debian-qt-kde@lists.debian.org and sorting the resulting list by last action… sweet! The package was just uploaded and should be available tomorrow. Update: Don pointed out that you can get the ordering in the web interface too by appending ordering=age to the URL. Neat.

God bless buildbot. Once Poky was released Richard, Marcin and myself started pushing upgrades into Poky trunk, resulting in 96 commits during the day. These generally worked on our personal machines, but thanks to the incremental autobuilder (which compiles all of the packages for five different targets) all of the problems were caught rapidly and fixed by the end of the day. As a well-done present the nightly autobuilder (which does a clean build) managed to build everything successfully for almost all of the targets. Impressive stuff really, without buildbot I doubt we'd have been able to upgrade autotools, Linux, X, and GNOME in one day and still produce working images the next. NP: Butterfly Wings Make, Orla Wren

In case you think that greylisting might have some disadvantages but give you also some benefits, you probably have thought about to use greylisting with some conditions. For example if you checked some parameters of the mail and you (or better your mailsystem) guess it may be spam, greylisting could be very usefull.
Until now, I was using plain policyd-weight. But mails with $REJECTLEVEL <= score <= $DEFER_LEVEL where in some conditions defered (see policyd-weight default) and if they come back with the same conditions, they will be defered twice. So it makes sence to me to greylist them and if they return within $DEFER_LEVEL, they will pass cause the greylist will allow them.
At first let’s create a restriction class which we can call from policyd-weight within main.cf of postfix:

# restriction class for use with polw (DEFER_ACTION)
smtpd_restriction_classes = greylist
greylist = check_policy_service inet:127.0.0.1:60000 To call postgrey for $REJECTLEVEL <= score <= $DEFER_LEVEL you need to make use of the restriction class “greylist” and let $DEFER_STRING match all defer strings, to get them all greylisted:

# echo “\$DEFER_STRING = ‘NOT’;” >> /etc/policyd-weight.conf
# echo “\$DEFER_ACTION = ‘rc:greylist’;” >> /etc/policyd-weight.conf
# /etc/init.d/postgrey restart Also you may have a look into The DNSBL countries.nerd.dk. This might be a way to score connections comming from well known spamming countries. But keep in mind, that there may also legitim mails comming from those! ;) planet, policyd weight, Postfix, spam

xorg and openoffice.org started with a cleanup of their bug reports. It is really great that compared to 2-3 years ago major cores of the Debian OS in unstable are quite in sync with upstream. Thus it is easy to forward to upstream the interesting part of bugs. The linux-2.6 bugs count reached that weekend almost 850 open bugs. Seeing that it gets unmanageable I'll decided to get it down to a target of 100 bugs. I'll blog from time to time about the progress. The process consists of pinging quite some bug reports against old Linux images and closing a huge swap of duplicate or no longer relevant bug reports. I expect the signal to noise ratio getting better once the bug count gets denser. The current side effect was to forward 1 patch upstream and to get 2 easy low hanging fruits fixed in latest linux-2.6 trunk. Thanks to enabling CONFIG_BLK_DEV_IO_TRACE trunk gains support for the blktrace(8). blktrace does direct IO block layer tracing - see also blktrace guide.

In case you're wondering why my blog has become so silent (3 posts in July, 2 posts in June - yes, my posting frequency is down by a magnitude!):About a year ago I started dancing, and this has by now become my main leisure time activity. And since I'm now off dancing (and meeting friends I know from dancing) like 5-7 days a week, that also means I'm spending much less of my free time on the computer.It's not just that I'm not blogging as much anymore; I'm also spending much less work on my opensource projects. Sorry about that; but all the dancing has recently been very fulfilling, whereas sometimes opensource work can be somewhat demotivating (especially when you fail to attract people to join your project).This especially means that some of the projects I started or played a bigger role in (e.g. SELinux on Debian) now need to find someone else to take over my work. Especially SELinux could definitely use some fresh hackers.

July 31st was my last day working for Sixbell-Nekotec Solutions (formerly known as Nekotec Tecnolog a). I lasted there three years. It seems like a life was spent there, heh: I entered after turning 20 and I’m leaving some days before I turn 23. Our future is still a bit fuzzy, but we are working on it. In the meantime, I’m getting back full-time to Mathematics next 13rd. But if our plans succeed and if everything goes right, we’ll be moving by the end of August or early September. Heh, yes, leaving school temporarily, again! Anyway, I’m unemployed right now. Listening to music most part of the day, taking Raquel to work, coding a bit here, there, doing some Debian labor, etc. Meh. An End Has A Start is one of the albums by the English band, The Editors, it makes a great title for my post now :-). I just listened to Taraf de Ha douks’ Maskarada, it’s not that great as the masterpiece as The Continuing Adventures. I’m getting addicted to the Cold War Kids.

The command crm_resource allows you to do basic editing of resources in the Heartbeat configuration database. But sometimes you need to do different things and the tool xmlstarlet is a good option. The below script can be used for testing Heartbeat OCF resource scripts. It uses the Heartbeat management program cibadmin to get the XML configuration data and then uses xmlstarlet to process it. The sel option for xmlstarlet selects some data from an XML file, the -t -m options instruct it to match data from a template. The template is the /resources/primitive part. The --value-of expression will print the values of some labels from the XML. The script will concatenate the name and value tags and export them as environment variables (see my post about Configuring a Heartbeat Service for an explanation of the use of the variables). The TYPE variable is the name of the script under the /usr/lib/ocf/resource.d/heartbeat directory. In recent versions of Heartbeat (2.1.x) the OCF_ROOT environment variable must be set before an OCF script is called. Setting it on older versions of Heartbeat doesn’t do any harm so I unconditionally set it in this script (which should work for all 2.x.x versions of Heartbeat). The first parameter for the script is the id of the service to be operated on and the second parameter is the operation to perform (start, stop, and status are the only interesting values). The script will echo the exit code to the screen (0 means success, 7 means that the service is not running or the operation failed, and any other number means a serious error that will trigger a STONITH if Heartbeat gets it). #!/bin/sh
$(cibadmin -Q -o resources xmlstarlet sel -t -m \
"/resources/primitive [@id='$1']/instance_attributes/attributes/nvpair" \
--value-of "concat('export OCF_RESKEY_',@name,'=',@value,'&#010;','TYPE=',../../../@type,'&#010;')")
OCF_ROOT=/usr/lib/ocf /usr/lib/ocf/resource.d/heartbeat/$TYPE $2
echo $? Below is another version of the same script that instead uses crm_resource to get the XML data. The output of crm_resource has a couple of lines of non-XML data at the start (removed by the grep) and also only gives the XML tree related to the primitive in question (so the /resources part is removed from the xmlstarlet command-line). #!/bin/sh
$(crm_resource -r $1 -x grep -v ^[a-z] xmlstarlet sel -t -m \
  "/primitive/instance_attributes/attributes/nvpair" --value-of \
  "concat('export OCF_RESKEY_',@name,'=',@value,'&#010;','TYPE=',../../../@type,'&#010;')")
OCF_ROOT=/usr/lib/ocf /usr/lib/ocf/resource.d/heartbeat/$TYPE $2
echo $? The problem with both of those scripts is that they rely on Heartbeat being operational. Performing any operations other than a status check while Heartbeat is running is a risky thing to do. If Heartbeat starts a service at the same time as you start it via such a script then the results will probably be undesired. One situation where it is safe to run this is when a service fails to start. After it has failed repeatedly Heartbeat may stop trying to restart it (depending on the configuration) in which case it will be safe to try and start it. Also you can put in temporary constraints to stop the resource from running by repeatedly running crm_resource -M -r ID until all nodes have been prohibited from running it (make sure you run crm_resource -U -r ID afterwards to remove the temporary constraints). The following script does the same thing but directly reads the XML file for the Heartbeat configuration. This is designed to be used when Heartbeat is not running. For example you could copy the XML file from a running cluster to a test machine and then test your OCF resource scripts. #!/bin/sh
$(cat /var/lib/heartbeat/crm/cib.xml xmlstarlet sel -t -m \
  "/cib/configuration/resources/primitive [@id='$1']/instance_attributes/attributes/nvpair" \
  --value-of \
  "concat('export OCF_RESKEY_',@name,'=',@value,'&#010;','TYPE=',../../../@type,'&#010;')")
OCF_ROOT=/usr/lib/ocf /usr/lib/ocf/resource.d/heartbeat/$TYPE $2
echo $?

Share This

A couple of days ago the hardware that is used to host this blog was upgraded - doubling the amount of RAM in the machine. To do this the machine was halted, memtest86+ was run to ensure that the new RAM worked correctly, and then it was booted up again. During that process my ssh session was not stopped! I merely refrained from typing anything until the upgrade was complete. This is one feature I really like about Xen. It can save the memory image of a running domain to a file and then restart it later. TCP sessions remain open if timeouts have not elapsed. The command xm save can be used to save the state to a file and the command xm restore will restore it. In Debian the location of the save files is stored in the file /etc/default/xendomains with the variable name XENDOMAINS_SAVE and defaults to /var/lib/xen/save. A quick experiment with one test domain (running Debian/unstable in 128M of RAM and had just run apt-get dist-upgrade so the memory contents would not be all zeros) showed that gzip -9 would decrease the file to 35% of it’s size at a cost of just over 1 minute of CPU time on a Pentium-M 1.7GHz. But gzip -3 compresses it to 37% and only takes 9 seconds. 9 seconds of CPU time to save 80M of disk space seems a reasonable trade-off. In my particular case it saves CPU time as the encryption I use for my root filesystem takes more CPU time than gzip -3 so compressing the data saves time. But I don’t expect my case to be common. Now when Xen is used on a more modern machine with a faster CPU gzip -3 has the potential to save time as well as disk space. A machine with a CPU that is in aggregate 10x faster than my laptop (I think that means most 64bit multi-core CPUs) running with a single S-ATA disk (that will have a sustained contiguous read speed of 80MB/s and write speed that is less) will save time when saving multiple Xen DomU’s if it runs them in parallel and compresses them. Also gzip is not the fastest compression program. There may be other options that are better suited to the needs of Xen. I have filed a Debian bug 435406 requesting that compression be supported.

Share This

Know how to use FontForge? If so we need your help with two release critical bugs in ttf-indic-fonts, #427885 and #428023. What has happened is that for the Latin ranges of some of these fonts, their designers have copied glyphs from proprietary fonts. They need to be replaced with glyphs from free fonts. If you can help, please let me know

I just flushed a bunch of updates.I started regression testing for qemubuilder.Nothing special, really.

Wow, the pilot of Californication, a new TV series starring David Duchovny (from X-Files hall of fame), is awesome! Quoting Wikipedia, the show is about “a troubled novelist whose obsessions with sex and drugs interfere with his personal and professional lives”. It was created by Showtime and it will begin airing on August 13th but the preair was leaked some days ago. It’s really cool and full of memorable quotes, I hope the rest of the episodes are as nice as the pilot. Go watch it!

In a comment on my previous post about ECC RAM someone commented that Dell sells PowerEdge desktop machines with ECC RAM. I visited the Dell web site and found that a low-end PowerEdge tower server (which still has a Pentium-D dual-core 64bit CPU) costs as little as $800AU. I also noticed that Dell Precision workstations that have ECC RAM - but that start at $2400. I wonder how much noise a low-end PowerEdge machine would produce. HP Workstations with model codes starting with xw also have ECC RAM and are advertised at $584US as the starting price (about the same as a low-end PowerEdge). I checked out NEC and Lenovo and according to their web sites they don’t make a desktop or desk-side machine that takes ECC RAM (someone please correct me if I’m wrong). So now I’m looking for cheap HP Workstations and Dell PowerEdge and Precision machines at auction.

Share This

I really believe we should not require repacking the original tarball to strip non-free but distributeable stuff, as long as that non-free stuff is not installed in the resulting binary packages, nor used in any parts of the building process.

Get your documentary on.

$TITLE is what I can now officially say; I’ve just received the papers that make it official. That’s a Master’s Degree in Computer Engineering for those who aren’t familiar with this very french thing that is the Dipl me d’Ing nieur. INSA Lyon stands for the Institut National des Sciences Appliqu es de Lyon, which is one of the top French engineering universities, as they put in on their website. Now I can live my life. At last.

In a comment on my blog post titled Childhood, Don Marti refers to an earlier blog post he wrote which refers to a New York Magazine article about the effects of praising children. The article does in some depth to describe scientific research into the issue of praising children for being “smart” vs praising them for working hard - with the conclusion being that it’s significantly better to praise them for working hard! One quote from that article that I find very significant is “Baumeister has come to believe the continued appeal of self-esteem is largely tied to parents pride in their children s achievements: It s so strong that ‘when they praise their kids, it s not that far from praising themselves’“. This matches my theory about people who subject their children to TV documentaries about gifted children. The conclusions regarding children seem quite clear and the article provides direct advice to parents and teachers as to how to avoid the problems. One issue I am wondering about after reading the NYM article is whether being exposed to smarter children hurts a child’s learning ability. The fact that there is no correlation between high self-esteem and learning ability has been proven, but the reports do not indicate whether there might be a correlation between a decreases in self-esteem and a decrease in learning ability. I recall pointing out to one the few good teachers at high-school that having some of the most capable and some of the least capable students in the same class was inefficient and led to excessive boredom for the more capable students and excessive difficulty in keeping up for the less capable students. I was told that “streaming” was considered bad because it was bad for the less capable students to know their status. I was also refused access to my results of the Westpac Maths contest for the same reason - which seems particularly strange, I was in the training program for the International Mathematical Olympiad so I doubt that releasing my score from one maths contest would change anyone’s opinion of my ability. I am also wondering about how this effects adults (apart from their education history). Should we try to praise work colleagues for their effort instead of being smart? Are adults discouraged from trying hard at their work when they see others succeeding with little apparent effort? One data point for this seems to be kernel coders in the Linux community. Everyone sees super-star Linux kernel coders on stage (on a pedestal) at conferences and it’s easy to believe that such people are significantly more intelligent than others (the well-known programmers are indeed very smart - but they also work a lot harder than most people believe) and that being so smart is a necessary pre-condition for submitting Linux kernel patches. I have met many people who appear to have the ability to be good at any type of coding but seem intimidated by kernel coding it for these reasons. Statements such as “I’ve been doing Linux coding for 10 years but I’m not a kernel coder” are often heard at Linux conferences. Also people who’s skills are respected are often regarded as kernel coders without any real reason. The Linux kernel is a large C program with limited options for a debugger, if you are good at C coding you should do OK! I know that I am trivialising the issues related to kernel coding, there are some tasks such as reverse-engineering device-drivers and debugging some of the tricky race conditions that require special skills - but no-one is born with such skills! I would not suggest that someone try a significant kernel coding task on their first attempt - as with all areas of programming it’s best to start with the easy things first. The web site kernelnewbies.org is a good source of information for people who are getting into kernel coding. I wonder whether a change in the attitudes towards such things could encourage more people to write free software, and more of the current programmers to attempt new challenges (such as kernel coding).

Share This

I am subscribed to the Google news alerts for the keyword Debian, and usually this means that I am notified of every security upgrade at least three or four times (needlessly, since I'm subscribed to Debian's security announcements anyway...) But today, two headlines sparked my interest: One, Carla Schroeder wrote an introductory article into building Custom Linux kernels with Debian and Fedora (though why somebody would want to do this is beyond me...), showing how easy the process is (I may be biased, but I find Debian's way is easier. On the other hand, it within the -- rpm -- package framework instead of a custom command -- make-kpkg in Debian -- feels more consistent and logical. Without reading documentation you won't get anywhere on both systems, so it probably doesn't matter...) One down for Carla, however, for not doing enough basic research: “The new naming convention [linux-* instead of kernel-* packages] opens the door to using other kernels with Debian, which I don't know what those would be, but Debian is ready for them.” Or one down for us, the Debian project, for not making enough noise around the various non-Linux ports. Though that will come when GNU/kFreeBSD is released with lenny... Two, Debian derivative SimplyMEPIS, which switched to Ubuntu as a base operating system a year ago, is now returning to Debian GNU/Linux as its base system. The main reason seems to be long term stability and upgradeability - which is a key strength of Debian for many other users as well (me, for one.) The reason for switching to Ubuntu in the first place has been newer application versions and predictable upgrade schedules (and that Warren Woodford misunderstood how Ubuntu LTS was to be maintained, apparently) -- both issues are being addressed within Debian as we get better release management and faster integration of new application versions (the big pieces of software I use regularly are the Linux kernel, X.org, KDE and OpenOffice.org, all of which I find are integrated in unstable fast enough, and much faster than 2 years ago. That the testing migration sometimes takes time is not a problem since mixing etch, lenny and sid is usually possible without problems even in a production (desktop) environment.) So, if we take a step back from the day-to-day squabbling between developers working at cross purposes and look at the output we produce, I believe we're still doing some things right.

Every now and then, I see somebody who -just as Russell did today- talks about the advantages of water heating systems not being tank-based, but tankless! Sounds kewl, hah? Shiny, new?
Well... I live at a house that is slowly but steadily started to show its age. Built in 1955 and owned for almost two decades by the very renowned phycisist (of course, my father's mentor and teacher) Marcos Moshinsky, my parents bought it in 1974, and it has been my home since 1976. And, at least since 1980 (I cannot be sure about earlier events for reasons that might be obvious to the casual reader), we have always had an Calentador Ascot de paso. Ascot (and further companies that have bought their name) have manufacutred this kind of water heaters for at least 60 years in Mexico. Yes, they are gas-based and not electricals like the ones Rusell links to, but that might just be because in Mexico gas has always been incredibly cheaper than electricity. And yes, the heater is godsent for ecolocigally conscious people - No more storing 20 to 40 lt (the sizes of the usual storage-based tanks around here) of hot water all day around just because you might want to take a shower, no more waiting for 20 minutes after you turn it on until you start having your morning shower (and more important, no more taking your morning shower ice-cold just because you overslept!)
Yes, it seems like life is perfect with our tankless (de paso) system... Almost.
As I said, our house was built over 50 years ago. It was built on what intended by then to be a middle-upper class suburb, on a very modern house with fancy stuff and all. And of course, the heater was not planned for the most visible or hearable areas of the house - specifically, nowhere close the living room - or the bedrooms. Silly details, the bathrooms are close to those areas. So, what's the answer? Want to take a shower? Ok, open the water...
And wait.
For around 3-5 minutes, until the hot water finishes the looong ride from the opposite corner of the house.
Of course, it takes a path that's not easy to intercept in order to move the heater to a saner place: The hot water pipe goes right under the middle of the living room, yay.
So we use our fancy de paso system whenever we are too lazy. Nadezhda and I prefer to fill one hot water bucket (~20lt) for each in the washing room, just by the kitchen (and the heater, of course!) and throw hot water over us to get a nice bath. Or, in case we are too lazy for that, collect as much as possible from the otherwise-wasted hot water in another bucket (we usually get ~10lt - but I fear another such amount just falls around it) and use it later for our various household duties.

Russell Coker has recently started posting random tech-tips and recipes in his blog :

To improve things in this regard I plan to increase the number of posts I write with solutions to random technical problems that I encounter with the aim of providing a resource for google searches and to randomly inform people who read my blog.

This is nice to see on Planet Debian - although I hope we continue to see the personal entries. For anybody else who is considering posting things like this I would be delighted if you'd copy them to the Debian Administration website. There have been numerous times when I've been just about to write something on a topic, seen it posted elsewhere and figured I shouldn't do so:

• Because it would be duplication.
• Because it would look like plagiarism

(Notable examples off the top of my head: Introduction to OpenVZ, Introduction to GIT, several Xen pieces.) I don't get many submissions, which I'm getting resigned to, but it is easy and people really really are greatful for new posts. In other news linuxlinks.com are a bunch of spammers and will be reported as such. I utterly fail to care that they've added "my software" to their list; if I cared I'd join their site and agree to receive emails from them..