Do you know code that compare versions of debian packages (for example, that knows if 2:23.2.3~rc1-1 is lower than 2:23.2.3-2?), besides dpkg –compare-versions? If yes, please write a comment to this blog post, preferably with a link to the code. Also, did someone already write a test suite for that? Who would be interested in such a test suite? I’m considering writing a function in PL/SQL to compare debian versions (for the Ultimate Debian Database project). If someone already wrote that, I’m interested as well.

Some time ago, there was some flamewars^H^Hdebate about the Release Team’s removals of RC-buggy packages from testing. Basically, some people claimed that popular packages shouldn’t be removed, even if RC-buggy. But, do we really miss popular packages in testing? It’s difficult to know. You could get the popcon data, and compare it with the Packages files for testing and unstable. Or work with source packages (which removes a lot of noise), but then, you have to convert the popcon data (which uses binary packages names) to source packages. Not completely trivial. That’s where the Ultimate Debian Database GSOC project comes to the rescue. The goal of Christian von Essen’s project is to gather data from various sources in Debian into a single SQL DB, so queries that combine all those data sources can easily be written. For example, here is the query that lists the source packages that are in unstable, but not in testing, sorted by their popcon (using the number of insts of the most popular binary package of the source package as value for the source package):

SELECT DISTINCT unstable.package, insts
FROM (SELECT DISTINCT package FROM sources
WHERE distribution = 'debian' and release = 'sid') AS unstable, popcon_src
WHERE unstable.package NOT IN (
   SELECT package FROM sources
   WHERE distribution = 'debian' AND release = 'lenny')
AND popcon_src.source = unstable.package ORDER BY insts DESC;

And the results are available on the web! Top packages (> 1000 insts):

lzo	64962
gnome-cups-manager	32346
db4.6	20708
ffmpeg-debian	12908
freetype1	10569
flashplugin-nonfree	7116
perlftlib	6769
nvidia-graphics-drivers	3864
wxwindows2.4	3640
dvi2tty	2239
kdebase-runtime	1725
easytag	1717
g-wrap	1582
yaird	1507
slocate	1499
youtube-dl	1390
hugin	1275
w3c-libwww	1058

Interested in UDD? Join #debian-qa or debian-qa@lists.d.o (or talk to me @DebConf!)

When I gave a Revealing Errors talk at Lug Radio Live USA, I had the misfortune of being up against Robert Love's talk on Android which many people at the conference wanted to see -- myself included! One person who showed up to my talk anyway was Allison Randall. She was apparently entertained enough to invite me to give a short version of the talk as one of the keynote presentations at OSCON 2008! In the talk, I covered the ideas behind my Revealing Errors project and quickly walked through a few examples that showcase what I'm trying to do. I'm happy with the result: a couple thousand people showed up for the talk despite the fact that it was at 8:45 AM after the biggest "party night" of the conference! For those that missed it for whatever reason, you can watch a video recording that O'Reilly made and that I've embedded below. A larger version of the Flash video as well as a QuickTime version is over on blip.tv and I've created an OGG Theora version for all my freedom loving readers.

Usually, files in /etc/pam.d/ are simple, linear descriptions of how a user should be authenticated, e.g. Try to authenticate him against ldap, and then against the local data base . But sometimes, you want something more advanced, for example If the user is called guest, please authenticate him with pam_dbus, otherwise use regular pam_unix. This is possible, and here I ll note down how to do that.There are actually two problems to solve: How to detect the username, and then how to do the flow control.For the first problem, I recently discovered the pam_succeed_if module, that allows for relatively advanced logic for checking uids, usernames, hostnames and group membership. For our case, the line would read

auth ? pam_succeed_if.so quiet user = guest

Now what next? If we just wanted to allow unrestricted access to guest, we could put sufficient for the questionmark. But we need something like if..then..else. Unfortunately (and I hope this will be fixed eventually), the only flow control available is skip the next n lines . So we can skip to pam_unix when this module fails (i.e. the user was someone else but guest), and if we did not skip, we can run the guest-specific module and then skip over pam_unix. So here is the complete snippet:

auth [default=2 success=ignore] pam_succeed_if.so quiet user = guest
auth [success=ok new_authtok_reqd=done ignore=ignore default=die] pam_dbus.so
auth [default=1] pam_permit.so
auth required pam_unix.so

You can read more about this advanced configuration in the PAM Administration guide. And here is the corresponding configuration for gdm, where guest can always login:

auth [default=2 success=ignore] pam_succeed_if.so quiet user = guest
auth required pam_permit.so
auth [default=1] pam_permit.so
auth required pam_unix.so

So I have a guest account with a locked password and I can allow ssh logins with a mouse click and use it directly with gdm. I probably should put the gdm configuration also in xscreensaver to not lock me out.

A recent post reminded me of a problem I once had; determine the glibc version and its support for various things. There's actually a little known but useful confstr call defined for just this sort of thing. Here's a minimal example: man confstr has all the details. If you don't need it in your program, you can also just run /lib/libc/so.6 and it will print out it's version info, e.g. There's also another glibc trick that often comes in useful; the LD_DEBUG environment variable. Start with help and you can get more details from there.

I’m the happy owner of a nice geeky toy: a Suunto X6HR watch, that includes an altimeter and an heart rate monitor, which I use mainly for moutain biking and hiking. During outings, the watch can log the altitude and heart rate every 2, 10 or 60 seconds, and the data can be transfered to a PC using a serial interface. The problem is that Suunto only provides software for Windows. I got tired of using virtualbox to connect to the watch (qemu doesn’t work, Suunto Activity Manager apparently does strange things with the serial port), so I reverse-engineered the protocol (using skimanager and J rome Kieffer’s work as a basis) and implemented a script to fetch the logs, and export them in a format suitable for gnuplot. Of course, Suuntux is publicly available. I’d be happy to hear from you if it works for you too. Also, if you own a Suunto X6 (similar watch, without HRM), I’d be interested in supporting it too (if it’s not supported already). Below is a example graph, from a short mountain bike ride just before leaving for Debconf.

I have just configured IPVS on a Xen server for load balancing between multiple virtual hosts. The benefit is not load balancing but management. With two virtual machines providing a service I can gracefully shut one down for maintenance and have the other take the load. When there are two machines providing a service a load balancing configuration is much better than a hot-spare, one reason is the fact that there may be application scaling issues that prevent one machine with twice the resources from giving as much performance as two smaller machines. Another is the fact that if you have a machine configured but never used there will always be some doubt as to whether it would work… The first thing to do is to assign the IP address of the service to the front-end machine so that other machines on the segment (IE routers) will be able to send data to it. If the address for the service is 10.0.0.5 then the command “ip addr add dev eth0 10.0.0.5/24 broadcast +” will make it a secondary address on the eth0 interface. On a Debian system you would add the line “up ip addr add dev eth0 10.0.0.5/24 broadcast + true” to the appropriate section of /etc/network/interfaces, for a Red Hat system it seems that /etc/rc.local is the best place for it. I expect that it would be possible to merely advertise the IP address via ARP without adding it to the interface, but the ability to ping the IPVS server on the service address seems useful and there seems no benefit in not assigning the address. There are three methods used by IPVS for forwarding packets, gatewaying/routing (the default), IPIP encapsulation (tunneling), and masquerading. The gatewaying/routing method requires the back-end server to respond to requests on the service address. That would mean assigning the address to the back-end server without advertising it via ARP (which seems likely to have some issues for managing the system). The IPIP encapsulation method requires setting up IPIP which seemed like it would be excessively difficult (although maybe not more than required to set up masquerading). The masquerading option (which I initially chose) rewrites the packets to have the IP address of the real server. So for example if the service address is 10.0.0.5 and the back-end server has the address 10.0.1.5 then it will see packets addresses to 10.0.1.5. A benefit of masquerading is that it allows you to use different ports, so for example you could have a non-virtualised mail server listening on port 25 and a back-end server for a virtual service listening on port 26. While there is no practical limit to the number of private IP addresses that you might use it seems easier to manage servers listening on different ports with the same IP address - and there is the issue of server programs that are not written to support binding to an IP address. ipvsadm -A -t 10.0.0.5:25 -s lblc -p
ipvsadm -a -t 10.0.0.5:25 -r 10.0.1.5 -m The above two commands create an IPVS configuration that listens on port 25 of IP address 10.0.0.5 and then masquerades connections to 10.0.1.5 on port 25 (the default is to use the same port). Now the problem is in getting the packets to return via the IPVS server. If the IPVS server happens to be your default gateway then it’s not a problem and it will already be working after the above two commands (if a service is listening on 10.0.1.5 port 25). If the IPVS server is not the default gateway and you have only one IP address on the back-end server then this will require using netfilter to mark the packets and then route based on the packet matching. Marking via netfilter also seems to be the only well documented way of doing similar things. I spent some time working on this and didn’t get it working. However having multiple IP addresses per server is a recommended practice anyway (a back-end interface for communication between servers as well as a front-end interface for public data). ip rule add from 10.0.1.5 table 1
ip route add default via 10.0.0.1 table 1 I use the above two commands to set up a new routing table for the data for the virtual service. The first line causes any packets from 10.0.1.5 to be sent to routing table 1 (I currently have a rough plan to have table numbers match ethernet device numbers, the data in question is going out device eth1). The second line adds a default router to table 1 which sends all packets to 10.0.0.1 (the private IP address of the IPVS server). Then it SHOULD all be working, but in the network that I’m using (RHEL4 DomU and RHEL5 Dom0 and IPVS) it doesn’t. For some reason the data packets from the DomU are not seen as part of the same TCP stream (both in Net Filter connection tracking and by the TCP code in the kernel). So I get an established connection (3 way handshake completed) but no data transfer. The server sends the SMTP greeting repeatedly but nothing is received. At this stage I’m not sure whether there is something missing in my configuration or whether there’s a bug in IPVS. I would be happy to send tcpdump output to anyone who wants to try and figure it out. My next attempt at this was via routing. I removed the “-m” option from the ipvsadm command and added the service IP address to the back-end with the command “ifconfig lo:0 10.0.0.5 netmask 255.255.255.255” and configured the mail server to bind to port 25 on address 10.0.0.5. Success at last! Now I just have to get Piranha working to remove back-end servers from the list when they fail. Update: It’s quite important that when adding a single IP address to device lo:0 you use a netmask of 255.255.255.255. If you use the same netmask as the front-end device (which would seem like a reasonable thing to do) then (with RHEL4 kernels at least) you get proxy ARPs by default. For example you used netmask 255.255.255.0 to add address 10.0.0.5 to device lo:0 then on device eth0 the machine will start answering ARP requests for 10.0.0.6 etc. Havoc then ensues.

Share This

Kris blogs about akademy being in Sint-Katelijne-Waver—which, since I moved to Mechelen, is my backyard, really—and wonders why nobody in the Belgian FLOSS community talked about it. It's not that I didn't know; Sune Vuorela, one of our Debian KDE developers, mentioned it to me a few months ago. He knew about our office in Mechelen, since he slept there at some FOSDEM a few years back. Of course, my first reaction was "oh, you'll pay me a visit then, right?", though I quickly realized "hang on, won't I be in Argentina then?" Turns out that's was the case. So I didn't bother blogging; perhaps I should have. Thing is, I've always felt like the Belgian FLOSS community is somewhat disjunct. It shouldn't be; we have a bunch of healthy and working community communication things, we have timely dinner meetings and drink meetings; and we even have a big important international developers meeting in the heart of our country. Even with that, I feel that more could be done. For example, I would probably like more unorganized social gatherings (say, more "lets-have-a-beer-now" type of meetings), and other things. Is this just me? I dunno.

It’s widely regarded that the best practice is to set the time zone of a server to UTC if people are going to be doing sys-admin work from various countries. I’m currently running some RHEL4 servers that are set to Los Angeles time. So I have to convert the time from Melbourne time to UTC and then from UTC to LA time when tracking down log entries. This isn’t really difficult for recent times (within the last few minutes) as my KDE clock applet allows me to select various time zones to display on a pop-up. For other times I can use the GNU date command to convert from other time zones to the local zone of the machine, for example the command date -d "2008-08-06 10:57 +1000" will display the current Melbourne time (which is in the +1000 time zone) converted to the local time zone. But it is still painful. In RHEL5, CentOS 5, and apparently all versions of Fedora newer Fedora Core 4 (including Fedora Core 4 updates) the command system-config-date allows you to select Etc/GMT as the time zone to get GMT. For reference selecting London is not a good option, particularly at the moment as it’s apparently daylight savings time there. For RHEL4 and CentOS 4 the solution is to edit /etc/sysconfig/clock and change the first line to ZONE="Etc/GMT" (the quotes are important), and then run the command ln -sf /usr/share/zoneinfo/Etc/GMT /etc/localtime. Thanks to the Red Hat support guy who found the solution to this, it took a while but it worked in the end! Hopefully this blog post will allow others to fix this without needing to call Red Hat. In Debian the command tzconfig allows you to select 12 (none of the above) and then GMT or UTC to set the zone. This works in Etch, I’m not sure about earlier versions (tzconfig always worked but I never tried setting UTC). In Lenny the tzconfig command seems to have disappeared, now to configure the time zone you use the command dpkg-reconfigure tzdata which has an option og Etc at the end of the list. Updated to describe how to do this in Lenny, thanks for the comments.

Share This

As mentioned elsewhere, LSB 4 is due out soon, and won’t really make a lick of difference when it comes to improving compatibility with non RPM/redhat-like systems. With software appliances and software as a service becoming more relevant, and appliance-oriented non-RPM distributions like rPath, Ubuntu JeOS and Defusion coming around that offer equal (or arguably better) value to customized Fedora/RHEL/CentOS and improved administrative ability due to using tools not stuck in the 1990s (RPM, I am looking at you here), one would think that the LSB working group might actually want to make LSB not suck. Right now, Debian derivitives like Ubuntu JeOS and Defusion can compete by using alien, and rPath has the RPMPackageRecipe for conary, but these are kludges and carry their own share of problems. So, why does the LSB require a specific format? There’s no reason for them to. Really, LSB compliance is a redhat-only club. Not just an RPM-only club… last time I checked, SuSE is in the same boat as everyone else and they use RPMs. A lot of the LSB needs to simply be ripped out in order to do any good. Until the LSB working group is willing to drop a lot of the RedHat-isms they have had, non-RedHat distros will always have problems complying. What about source-based distros like Gentoo for example? There is really no easy way they can comply by default (on the other hand, do they care to?). To put things simply, the LSB sucks. Here’s why:

• The LSB spec depends on RPM. I mean, come on. Seriously. Why do they need to require a specific package manager? If package handling is really required, then why not create a simple package format that can be converted on demand into the system package format? Or why care about packages at all?
• The LSB spec invents things without consulting distros. Like the whole init scripts thing. But that’s not as bad as depending on RPM or requiring a specific layout.

Ideally, the LSB spec would define a config format capable of describing how the system worked, and all of that, but it doesn’t. Until it does, then the LSB spec is worthless, because it can’t handle all distributions (even the common ones).

One of the things of getting too much mail is that you will get swamped in it, sometimes to the level of not even managing to figure out there's been replies on your blog for the past several weeks. Oops. Apparently quite a number of people answered to my blog post about the belgian government issues, and I only found out right before leaving for Argentina. They're now all accepted from moderation, but that doesn't mean I can't follow up on them anymore. Most of them just agree with what I have to say, or posit another opinion (which is fine), but some clearly show a misunderstanding of what I was trying to say. So, since I don't want to appear as one posting gibberish, allow me to clarify:

"I could say that some other things about the past deb cle also puzzle me, such as the insistence of some people to get an unconditional split of BHV, thereby destroying all chances of even remotely reaching a compromise." You are saying that you would accept giving in to the demands of the Francophones that the Flemish give up territory. (Think about it, what century are they from? In what other country does one community demand the enlargement of its territory as an exchange for fixing a situation which the constitutional court has ruled to be illegal?)

Thanks for asking, but no, I'm not saying that. Let's be clear about this: there's a huge difference between a position that says "we need to split BHV, period" on the one hand, and "we need to give territory to the francophone community" on the other. It should be perfectly possible to, say, have the flemish community come up with some benefit to the francophone community in some respect somewhere that does not include "giving territory to the south of france"; but apparently the "negotiators" think not. To quote just one example: at some point Reinders (MR) suggested that a federal election circle be created to replace BHV, so that francophone politicians could still be elected in flanders, but also the other way around. This proposal was however killed by flemish politicians before the press as "not even negotiable" without even having discussed it. This, and other similar examples, I do not understand. After all, the fact that the constitutional court has ruled the current situation to be illegal does not change anything about the fact that this is still a request from the Flemish part of the country, and not from the Francophones; anyone telling you anything else is simply lying. There's nothing wrong with wanting something and being declared correct in court, of course; but there is something wrong with wanting that unconditionally. Unless you won a war, that is. And then still. Of course, not caring about much of the definitions of many political parties and not being a politician in any way, I ticked off someone who just happens to be a member of one of the parties I don't even like in the first place. Amedee, in case it matters: I didn't call CD&V a "Catholic" party to imply anything, but simply because I'm blissfully ignorant of the difference between Catholic and Christian. And happily so, too, given the CD&V's current behaviour. Oh, and the SP.A is not my favourite party; it's just that they seemed to be the more sensible of the lot during the last elections' campaigns. What's really my favourite party isn't something I'll tell you (or anyone), though.

When installing Xen servers one issue that arises is how to assign MAC addresses. The Wikipedia page about MAC addresses [1] shows that all addresses that have the second least significant bit of the most significant byte set to 1 are “locally administered”. In practice people just use addresses starting with 02: for this purpose although any number congruent to two mod four used in the first octet would give the same result. I prefer to use 02: because it’s best known and therefore casual observers will be more likely to realise what is happening. Now if you have a Xen bridge that is private to one Dom0 (for communication between Xen DomU’s on the same host) or on a private network (a switch that connects servers owned by one organisation and not connected to machines owned by others) then it’s easy to just pick MAC addresses starting with 02: or 00:16:3e: (the range assigned to the Xen project). But if Xen servers run by other people are likely to be on the same network then there is a problem. Currently I’m setting up some Xen servers that have public and private networks. The private network will either be a local bridge (that doesn’t permit sending data out any Ethernet ports) or a bridge to an Ethernet port that is connected to a private switch, for that I am using MAC addresses starting with 02:. As far as I am aware there is no issue with machine A having a particular MAC address on one VLAN while machine B has the same MAC address on another VLAN. My strategy for dealing with the MAC addresses for the public network at the moment is to copy MAC addresses from machines that will never be in the same network. For example if I use the MAC addresses from Ethernet cards in a P3 desktop system running as a router in a small company in Australia then I can safely use them in a Xen server in a co-location center in the US (there’s no chance of someone taking the PCI ethernet cards from the machine in Australia and sending them to the US - and no-one sells servers that can use such cards anyway). Note that I only do this when I have root on the machine in question and where there is no doubt about who runs the machine, so there should not be any risk. Of course if someone from the ISP analyses the MAC addresses on their network it will look like they have some very old machines in their server room. ;) I wonder if there are any protocols that do anything nasty with MAC addresses. I know that IPv6 addresses can be based on the MAC address, but as long as the separate networks have separate IPv6 ranges that shouldn’t be a problem. I’m certainly not going to try bridging networks between Australia and the US! Another possible way of solving this issue would be to have the people who run a server room assign and manage MAC addresses. One way of doing this would be to specify a mapping of IP addresses to MAC addresses, EG you could have the first two bytes be 02:00: and the next four be the same as the IPv4 address assigned to the DomU in question. In the vast majority of server rooms I’ve encountered the number of public IP addresses has been greater than or equal to the number of MAC addresses with the only exception being corporate server rooms where everything runs on private IP address space (but there’s nothing wrong with 02:00:0a: as the prefix for a MAC address). I also wonder if anyone else is thinking about the potential for MAC collisions. I’ve got Xen servers in a couple of server rooms, I told the relevant people in writing of my precise plans (and was assigned extra IP addresses for all the DomUs) but never had anyone mention any scheme for assigning MAC addresses.

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

Share This

Linux has this great thing called locales. You can basically control everything through a few system variables. The system is so flexible that you could in fact have English language with Swedish dates and Chinese error messages. The problem with the current system is that it's controlled mostly with one variable. Just about everyone I know (including me) set the system locale to en_US because they don't want to use their local language as the system language. This in turn causes new problems, mostly due to the metric system used in the sane countries. I finally got around to debug how to get the system to speak my language. The key here is the file /etc/default/locale which on Debian based systems contain the locale settings. Usually there is just one line in that file. LANG=en_US.UTF-8 Since I live in Finland and want my computer to speak English I can add the following lines: LC_NUMERIC="fi_FI.UTF-8"
LC_PAPER="fi_FI.UTF-8"
LC_NAME="fi_FI.UTF-8"
LC_ADDRESS="fi_FI.UTF-8"
LC_TELEPHONE="fi_FI.UTF-8"
LC_MEASUREMENT="fi_FI.UTF-8" This replaces the settings for numerals (decimal separator and such), paper (yes, the rest of the world uses A4), name, address, telephone and measurement (YAY, metric system!). This way I have a nice English speaking system with Finnish settings. I tried setting LC_ALL to fi_FI.UTF-8 but that causes gnome to speak Finnish to me, even though the LANGUAGE and LANG settings are set the English. LC_TIME is something I'd like to use, but I find the Finnish abbreviations for weekdays and months to be confusing. LC_MESSAGES causes gnome to talk partially Finnish, the general locale is English as it's supposed to be, but for example gnome-panel changes the menu entries to Finnish. I wish that it was easier to set these settings. I also doubt that various tools know how to respect these settings and will overwrite that file with the default setting. That is why I'm writing this entry so that I remember how to fix it when that happens. In the end the system is flexible but it's built in a funny way. The actual variable built by combining 2 or 3 values: language, country and possibly encoding. So to make thing easy for me I would have to declare en_FI.UTF-8 locale and start translating applications to that locale. I don't want to, so I'm sticking to this "temporary" solution.

There is an interesting article in The Age about the effect of petrol prices on the poorer people in Melbourne [1]. The article claims that people are unable to sell large old cars and buy smaller cars. To investigate that claim I did a price search on Ford Falcons and Holden Commodores on the web site www.drive.com.au . The Ford Falcon and Holden Commodore were for a long time the two leading marques of cars sold in Australia - both of them large cars. It seems that if I wanted to buy a Falcon that is less than 20 years old with an engine of 4.0L (or bigger) then I would have many choices available with list prices under $2500, including some cars in that price range which are as little as 10 years old (the average age of a car that’s registered for use in Australia). For Commodores there seems to be less choice, there are a few of them with 4L engines that are just over 10 years old being advertised for just under $5000 and a significant number being advertised in the $5,000 to $7,500 range. I don’t know whether the increased asking price for Commodores is due to greater optimism by the owners or a greater demand. One thing that we have to keep in mind is that due to the low price of advertising on the web site and the duration of the advert (which permits changing the price at any time) the sensible strategy is to start the advert with an optimistic price, and then gradually drop the price if there is little interest by the buyers. There are also some Falcons on auction on Ebay that are going fairly cheaply, one example is less than $6000 for a 2000 Falcon with only a few minutes to go. The HSV (Holden Special Vehicles) cars are listed on Drive as a different make on Drive (it’s just Holden’s range of faster vehicles), and surprisingly their prices are quite strong. There is only one vehicle on offer for less than $5000, and only a few for less than $10,000. Now when it comes to buying a small car, on ebay there are a number of Toyota Corollas on sale, two 1997 models are on sale for just under $9,000 and just under $10,000. It seems that you could sell a 2000 model Ford Falcon on ebay and not receive enough money to buy a 1997 Toyota Corolla! For the Corollas advertised on Drive the majority of them seem to be advertised for around $15,000, but the volume on sale is great enough that there is a significant minority advertised for lower prices. There are 173 Corollas advertised for between $2,500 and $5,000 it might be possible to find one of those that has no significant problems. So it seems that ebay is not the place to buy a Corolla! So it seems that the main premise of the article (that you can’t sell a second-hand large car and buy a small car) is correct. If you were to sell a 1990’s Falcon or Commodore and buy a Corolla (which cost about half as much as a high-end Falcon or Commodore when new) of the same age then you would be lucky to get more than half the Corolla purchase price. Then of course there’s a 4% “stamp duty” tax to pay and the risk that a second-hand car you buy might have some hidden problem (the cheaper cars are unlikely to have been well serviced).

• [1] http://www.theage.com.au/national/so-near-and-yet-so-far-with-distance-measured-in-litres-20080801-3olr.html?page=-1

Share This

A while back wanted to know about a replacement for my Dreambox. I was also asked to write up a summary of the replies. Initially I assumed that my Dreambox 7025C was failing, it showed a classic symptom, progressively increasing error rate which wasn't showing up on my neighbors. Since we share the cable they should see the problems too, so I ordered new tuners for the box and the problem persisted. In the end it turns out that the problems were initially showing on such channels that my neighbors weren't watching or in such amount that they didn't pay attention to it. In the end it was a problem in the feed and my box is just fine. I now have 2 brand new DVB-C tuners for the 7025 (anyone want to buy them?) and a perfectly working setup. (YAY!). In a way I feel lucky that the box wasn't failing on me. Nobody suggested any complete solutions, but I was able to spot ReelBox Avantgarde as a possible alternative. It runs Linux like I want it to, but it's way too expensive. Another alternative could have been Maximum 8000, which appears to be a re-branded Marusys C-8000. It has Linux as the OS but the community side appears to be rather lacking. Then again, it's a pretty new device... I was suggested VDR and MythTV as the DIY solution. I dismissed MythTV without even looking in to it. Although I must admit that it's been quite a few years since I tried MythTV, but it was way too unstable for my taste. Also I wasn't too happy about the architecture of it. VDR is something I could have tried. The downside appears to be that it lacks in hardware support. The last time I was building my own PVR I ran in to the common problem of getting a decent output to the TV. VDR folks have traditionally solved this by using a HW decoder card to output the stream directly to the TV. Using VDR with a budget DVB card is possible but not recommended because of the CPU power needed to decode the stream. I've always considered VDR to be the more sophisticated solution of the two, but it is starting to sound a lot more hassle than it's supposed to. Also, the DIY solutions are hard to get in to a decent form. Usually the cases are bulky and custom modifications are required. I'm not one of those guys that install neon lights to their computers to make it look cool, but if I'm having it in my living room I expect it to look decent. Take a look at the VDR boxes section on the website for examples. While I admit that it's up to me to build a decent box, I'm not willing to spend too much time hand picking every single component so that it fits a casing and works with the given application. Finally, I'd like to thank all the people that sent me comments. Even though I ended up sticking with the current setup, it was a valuable look in to what is out there. The Dreambox I have, doesn't have a HDMI output and lacks in few areas. Keeping that in mind I'm eventually going to take this same look in to the alternatives while picking a replacement for the current box. Lets hope VDR, MythTV and Elisa (to name a few) continue to evolve and the video output properties of Linux become better and eventually I'll have the possibility of replacing my current setup with something that is even more flexible.

The lecture by Professor James Duane about why you should not talk to the police (in the US at least) is doing the rounds at the moment. The Google video site doesn’t work for me, so I downloaded it from youtube with the following references:
part 1 [rVq6N0xAEEM]
part 2 [-Z0bpj3EEHI]
part 3 [44-GSZofXIE]
part 4 [zSvxiaO-TG8]
part 5 [gzYHnWrqfWg]
part 6 [BErNzdOnWGY] The first thing that struck me about this is that it’s the first time I’ve ever seen someone clearly state the problem with the excessive number and complexity of the laws. It’s impossible to know whether you are breaking the law. This is obviously wrong and it should be a legislative priority to reduce the number of laws and the complexity of the laws. If for every law they sought evidence regarding whether it helped people or helped preserve the state then that would be a good start. The excessive number of laws is not just a problem due to the risk of accidentally breaking a law, but also due to the fact that a malicious cop could arrest anyone that they wished - it would merely be a matter of following them for long enough. In the second half of the lecture Officer George Bruch from the Virginia Beach Police Department gives his side of the story. At one point he cites an example of the road laws where he can follow a car and find a legitimate reason for booking the driver if he wishes. Virginian law allows the police to destroy primary evidence. If they tape an interview then they can transcribe it to a written record and then destroy the original tape. If the transcription removes some of the content that has meaning then the defendant is probably going to suffer for it. It’s often stated that on the net you have to make extra effort to make your meaning clear as jokes can’t be recognised by the tone of voice. It seems that the same effort would need to be made in a police interview (but without the possibility of going back and saying “sorry I was misunderstood” that you have in email). It’s also legal for police to lie to suspects. While I can imagine some situations where this could be reasonable, it seems that at a minimum there should be some protection for child suspects against being lied to by police (there have been some travesties of justice stemming from children trusting police in an interview room). It seems that if someone doesn’t get a good lawyer and refuse to talk to the police then they will be likely to be convicted regardless of whether they are guilty or innocent. Officer Bruch says that he tries to avoid interviewing innocent people. So I guess whether someone ends up in jail or not will depend to some extent on the opinion of a cop who may or may not interview them. While I guess a high rate of success at securing convictions is in most cases a good thing, the fact that convicting an innocent person is the absolute best way of letting a criminal escape justice seems to be forgotten. Another issue is the fact that a witness may have reason to believe that they could be a suspect. The advice that a suspect should never talk to a police officer seems to logically imply that intelligent people will be hesitant about providing witness statements in situations where they may be a suspect. I wonder how the legal system in Australia compares to the US in regard to these issues. I know that we have far too many laws and too many complex laws which can not be understood and obeyed by a reasonable person.

Share This

I have written a script named postfix-nochroot to disable the chroot functionality of Postfix. I plan to initially include this in the selinux-basics package in Debian, but if the script was adopted by the Postfix package or some other package that seems more appropriate then I would remove it from selinux-basics. The reason for disabling chroot is that when running SE Linux the actions of the various Postfix processes are restricted greatly, such that granting chroot access would increase the privileges. Another issue is the creation of the chroot environment, the Postfix package in Debian will recreate the files needed for the chroot under /var/spool/postfix when it is started. The first problem with this is that when a package is ugraded the chroot environment won’t be upgraded (with the exceptions of some packages that have special code to restart Postfix) and when the sys-admin edits files under /etc those changes won’t be mirrored in the chroot environment either. The real problem when running SE Linux is that it requires extra privileges to be granted to the Postfix processes (to be able to call chroot()). While the SE Linux policy places much greater restrictions on the actions of daemons than a chroot would. For example a non-chrooted daemon process running with SE Linux will not be able to see most processes in ps output (it will be able to see that processes exist through entries under /proc, but without the ability to search the subdirectories of /proc related to other processes it won’t be able to see what they are). It would be possible for my script to be used as the first step towards making a Postfix installation automatically use a chroot when SE Linux is disabled or in permissive mode, and not use a chroot when SE Linux is in enforcing mode. I’ve probably done about half the work that is needed if this was the end goal, but I have no great interest in such configuration and no time to work on it. I would be prepared to accept patches from other people who want to go in this direction.

Share This

As mentioned earlier, I've uploaded a new Pyroman release to Debian. I've also updated the download at the download page on alioth for the non-Debian users.There is just one single user-visible change (under the hood I switched some Python API so you need python 2.4+ now, which was available in sarge already):This version has a new command line option, "--verification-cmd". This can be used to point to a script file to verify network connectivity. For example, you could try to send a ping to the next router, or you could ssh to another host, have it ssh back and touch a flag file in /tmp to signal success.Similar to the --safe option, it is meant as a safety feature to avoid locking yourself out of your system. But while --safe needs to be used interactively, this new command could be used when automatically activating new firewall rules, e.g. triggered by cfengine or some other configuration management. If the verification command does not succeed, the firewall rules will automatically be rolled back to the previous state.Note that I didn't get around to add IPv6 support yet. It would definitely be desirable to add ip6tables support, but I currently do not have any experience with IPv6, so I'm not sure I'd know how to do things right. Of course I'd welcome any patches.(In case you havn't read about pyroman yet - it's yet another tool to configure iptables firewalls. It puts a thin abstraction layer on top of iptables, but the main benefit is that it uses "iptables-restore" to quickly mass-set all the firewall rules - other tools tend to invoke several hundred iptables processes to achieve the same - and if any error occurs it will both give you a clear indication of which rule caused the error and rolling back your firewall to the previous state.)

Various people have asked me why there'd ever be a justification for ACPI tables to base various types of behaviour on the operating system they're running on, and why Linux claims to be Windows. There's pretty straightforward explanations that don't involve conspiracies, but they're not necessarily obvious. Let's start from the beginning.

ACPI provides two mechanisms for determining the OS, _OS and _OSI. _OS is an ACPI object containing a string. This string is supposed to represent the operating system. Windows 98 contained "Microsoft Windows", NT4 "Microsoft Windows NT" and ME "Microsoft WindowsME: Millennium Edition". All later versions of Windows contain "Microsoft Windows NT". Linux was "Linux" up until 2.6.9, and has been "Microsoft Windows NT" since then.

The obvious drawback to _OS is that it's a single string. _OSI was introduced with later versions of ACPI, providing an interface for ACPI tables to request which interfaces an OS supported. Interfaces may be something like "3.0 Thermal Model", indicating support for a specific aspect of ACPI, but may also be used to indicate the interfaces supported by the OS. The _OSI method is passed a string and returns either true or false depending on whether the OS claims to support that interface. The OS can therefore claim to support many different interfaces. Linux implements pretty much every aspect of ACPI that Windows does, and so claims to support all the interfaces that Windows implements. As a result, Linux will return true when asked if it implements support for any of the Windows interfaces (up to and including Vista).

That's all straightforward enough, but leaves two questions. The first is why Linux now claims "Microsoft Windows NT" for _OS. That's actually pretty simple - some DSDTs only check for various _OSI strings if _OS is "Microsoft Windows NT". This is stupid of them, but not a violation of the ACPI spec. The second is why Linux returns false for _OSI("Linux"). This is a little more subtle, but it basically boils down to "There is no Linux interface". The behaviour of Linux changes over time. We make no guarantees that its behaviour will be consistent over time as we find and fix bugs. Microsoft take a different approach. Their ACPI behaviour has few changes over time. Something claiming to be Windows 2000 will always behave the same way. We can't even bump the interface string per release - doing so would require us to maintain every broken behaviour we've ever implemented and switch between them depending on what the BIOS asked us for. Linux does not provide a stable ACPI API to platform firmware, and we make no guarantees that it ever will. The only behaviour you can depend on is that Linux will conform to either the ACPI spec or (where it differs) the behaviour of Windows. If you find behaviour that does not fall into either of those categories, then it's likely that the behaviour will change when we notice. The reason we removed Linux from the supported interfaces list in 2.6.24 was that we were beginning to see BIOSes that changed behaviour when they detected that they were running on Linux, and changes we wanted to make could have potentially broken these BIOSes.

Anyway. That's why we claim to be Windows. Now, why would a DSDT want to do anything with that information? It should be noted that making decisions based on this is not a contravention of the ACPI spec - section 5.7.2 even describes a case of this. There are a few situations under which this can be helpful. The first is due to varying interpretations of the spec. Early versions of Windows require that hotswap bays signal their removal by sending a bus check notification to the parent IDE bus. Later versions want a device check notification on the device itself. Both are valid, but you ideally want to use the right one on the corresponding OS. Checking the OS version lets you do so.


Red Stripe makes a lousy spec-compliant ACPI implementation. That is because it is not a spec-compliant ACPI implementation, it is beer! Hooray beer!

Another is user experience. Not all hardware is supported by all operating systems. For instance, older versions of Windows don't support high-precision event timers (HPET). The HPET is defined as an ACPI device, and so will show up as an unknown device in the Windows device manager unless the firmware disables it. This is acheived by altering a flag in the _STA response depending on the Windows version - earlier versions are told that the device should be invisible, and later versions are told that it should be exposed. Finally, there's bug workarounds. An example of this is Windows 98 crashing if a thermal zone reports a temperature of less than 15.8 degrees celsius. Working around that seems like a perfectly reasonable thing for a piece of hardware to do, since Microsoft don't make it easy for vendors to provide hotpatched versions of Windows.

The final part of this mystery is why various BIOSes attempt to check whether they're running on Linux. Almost all the BIOSes I've examined do nothing with this information, which is consistent with someone writing an OS lookup table many years ago and adding Linux just in case someone found it useful. People don't generally write ACPI tables from scratch (doing so would be very dull), so they'll base it on the one from a previous version. Code won't be removed unless it's breaking things, so you'll end up with various odd evolutionary dead ends that have persisted anyway. If your ACPI firmware checks for Linux, this is not inherently a bug in your BIOS. It's more likely that nobody cared enough to remove two lines of code that might turn out to be useful one day.