As a follow-up to Tolimar s post, here are some ponies for ftpmasters: (Clicking on an image leads to the relevant flickr page.) Those crazy folks are almost ACCEPTing X11 libraries with added udebs faster than I m uploading them. Source packages needing an upload include cairo, pango1.0, gtk+2.0, udev, and xorg-server. Then we should be able to deal with udebs maintained by the d-i team. Anyway, back to the initial topic: Ponies, thanks & kudos to ftpmasters!

I hope some people from the OCaml community will enjoy this changelog, extracted from llvm 2.6-7, which has just been uploaded:

  [ Arthur Loiret ]
   
  [...]
  [ Sylvain Le Gall ]
  * Build a libllvm-ocaml-dev package, which contains the OCaml binding:
    Closes: #568556.
    - debian/debhelper.in/libllvm-ocaml-dev. dirs,doc-base,install,META : Add.
    - debian/control.in/source: Build-Depends on ocaml-nox (>= 3.11.2),
      ocaml-best-compilers   ocaml-nox, dh-ocaml (>= 0.9.1).
    - debian/packages.d/llvm.mk:
      + (llvm_packages): Add libllvm-ocaml-dev.
      + (libllvm-ocaml-dev_extra_binary): Define, install META file.
    - debian/rules.d/binary.mk: Add dh_installdirs and dh_ocaml.
    - debian/rules.d/vars.mk:
      + include /usr/share/ocaml/ocamlvars.mk.
      + Configure with --with-ocaml-libdir=$(OCAML_STDLIB_DIR)/llvm.
  * debian/rules.d/build.mk: Fix symlinks pointing to the $DESTDIR.

In other words: LLVM is now built with its OCaml bindings and a META file for findlib. It will take some days before reaching every architectures, but hopefully it will be in Squeeze (next Debian stable release). Thanks to Arthur Loiret for the quick upload.

Last night, in two different instances I read the claim that the England s first copyright act, the statute of Anne passed in 1710 was never intended to protect authors but to protect the reproducers like printing houses and presses investing in authors implying that printing houses loved the act. After pouring through hundreds of pages of Adrian John s history of piracy, that statement is pretty off and in fact I don t think the Statute was really about printers/booksellers or authors but the public. While licensing had all together lapsed for a period before this statute was passed, and the printing houses and book sellers were indeed clamoring loudly for an official recognition of property in literary works, they wanted a perpetuall right in literary property rooted in common and natural law. Like I am talking here about forever, not like a measly, paltry 14 years. They were not exactly thrilled at this statute (in fact, they were downright pissssssssed off) for it severely limited how long they held a property right over books. In fact, so pissed were they, they challenged the statute, went to court in 1769 (Millar v Taylor) and got what they wanted: a perpetual right to literary work. It took s a fiery Scot and bookseller by the name of Alexander Donaldson (I kind of think of him as the RMS of booksellers; he was quite a rabble rouser) to challenge Millar and he finally got his day in the highest court of the land in 1774 in Donaldson v Beckett and the outcome was that a perpetual right in books was tossed out the window. The court ruled that copyright was a limited statute. One of the lords in the case even stated Knowledge has no value or use for the solitary owner: to be enjoyed it must be communicated. Adrian John s explains the significance of this case in the following way: Copyright, they decided, was not a right of man at all. Indeed, it was almost the very opposite: an artifact, and one that replaced a prior right established by an author s work of creation. . . In terms of revolution principles, liberty won out over property Again the printers booksellers (minus the pirate ones) were not happy a bunch. Unfortunately the subsequent history is one we all know well, one in which booksellers and others with vested interests in copyrights pushed to extend property rights in all sorts of ways to get to where we are today (obviously with a lot of different historical developments), a land, time, period where perpetuity may not be forever but it is long enough to nullify the very public domain envisioned by the first copyright act. However, I think it is nonetheless important to recognize how radical in many respects the first copyright act was: given what the book printers and sellers wanted (and they were a powerful bunch). For those interested in learning more about Alexander Donaldson, I would check out his Some Thoughts on the State of Literary Property, where he rails against the London booksellers for being monopolistic and calling for a limited property right in books.

Last night, in two different instances I read the claim that the England s first copyright act, the statute of Anne passed in 1710 was never intended to protect authors but to protect the reproducers like printing houses and presses investing in authors implying that printing houses loved the act. After pouring through hundreds of pages of Adrian John s history of piracy, that statement is pretty off and in fact I don t think the Statute was really about printers/booksellers or authors but the public. While licensing had all together lapsed for a period before this statute was passed, and the printing houses and book sellers were indeed clamoring loudly for an official recognition of property in literary works, they wanted a perpetuall right in literary property rooted in common and natural law. Like I am talking here about forever, not like a measly, paltry 14 years. They were not exactly thrilled at this statute (in fact, they were downright pissssssssed off) for it severely limited how long they held a property right over books. In fact, so pissed were they, they challenged the statute, went to court in 1769 (Millar v Taylor) and got what they wanted: a perpetual right to literary work. It took s a fiery Scot and bookseller by the name of Alexander Donaldson (I kind of think of him as the RMS of booksellers; he was quite a rabble rouser) to challenge Millar and he finally got his day in the highest court of the land in 1774 in Donaldson v Beckett and the outcome was that a perpetual right in books was tossed out the window. The court ruled that copyright was a limited statute. One of the lords in the case even stated Knowledge has no value or use for the solitary owner: to be enjoyed it must be communicated. Adrian John s explains the significance of this case in the following way: Copyright, they decided, was not a right of man at all. Indeed, it was almost the very opposite: an artifact, and one that replaced a prior right established by an author s work of creation. . . In terms of revolution principles, liberty won out over property Again the printers booksellers (minus the pirate ones) were not happy a bunch. Unfortunately the subsequent history is one we all know well, one in which booksellers and others with vested interests in copyrights pushed to extend property rights in all sorts of ways to get to where we are today (obviously with a lot of different historical developments), a land, time, period where perpetuity may not be forever but it is long enough to nullify the very public domain envisioned by the first copyright act. However, I think it is nonetheless important to recognize how radical in many respects the first copyright act was: given what the book printers and sellers wanted (and they were a powerful bunch). For those interested in learning more about Alexander Donaldson, I would check out his Some Thoughts on the State of Literary Property, where he rails against the London booksellers for being monopolistic and calling for a limited property right in books.

I've made a quick release of dh-make, now up to 0.52. Besides a minor dh_make.1 manual page fix this release will put the right value in the debian/source/format file. 0.51 will make it a native source package no matter what flags you use.

If you get weird lintian errors about native source formats and version numbers wrong on your brand-new Debian package you just made, you might of been bitten by this bug.

That leaves a few bugs left, there are two I need help with:

• Bug 328692 - If you have a plan ASCII name like me, then your name looks fine in the dh-make generated man pages. This bug requires converting names that aren't plain ASCII (e.g. that use UTF-8) into something groff understands. Someone suggested decomposed unicode but unicode and groff are pretty much a black art to me, let alone combining them.
• Bug 533117 - This one is all about making dh-make make your python packages. You'll need to understand the new debhelper v7 rules files. Again, python is not something I use so the bug is stuck here.
  

Related articles by Zemanta

• UTF-8: Bits, Bytes, and Benefits (research.swtch.com)

I finally got a few hours free this morning to check an item off my home system administration checklist: upgrading the wireless router's firmware to OpenWRT. There were a couple motivations for this, including the fact that my SoundBridge Radio couldn't maintain a connection to my firefly server using the built-in firmware, and I had read that OpenWRT would work better. Since this is posted on Planet Debian, I should mention why I didn't use DebianWRT. The basic answer is this text at the top of the DebianWRT homepage:

Currently the most common methods used to run Debian on these systems is to install OpenWRT or a similar firmware, add disk space either by USB storage or NFS, create a debian chroot by either running cdebootstrap from inside OpenWRT or debootstrap --foreign on a PC, and running Debian from this chroot. For example, instructions for the WLHDD.

I'm not sure whether this is because DebianWRT is experimental, or because its goal is to use routers as cheap general computers. Either way, it sounds way too complicated and/or fragile for what I'm interested in (i.e., a wireless router with better software). The goal here is to get something that does a better job than the built-in WRT firmware, but doesn't require too much tinkering to get working or to maintain. I have plenty of outlets for my tinkering urges already. Nothing here was exactly difficult, but it was hard to find all the information I needed to get things working. Hopefully documenting the steps I went through here will save someone else some time. Step 1: acquire the firmware This was trickier than you might think. If you click on the download link at the OpenWRT web site, you end up at the top of an FTP server populated with a vast quantity of stuff. Worse, when you find the actual firmware images, you'll quickly discover that there are piles and piles of them divided between sixteen directories, and no guidance as to which one to pick. And picking the wrong one will turn your beautiful router into a doorstop. Luckily, the OpenWRT documentation contains a section called "Getting Started". Unluckily, that section consists of the following text:

1.1 Getting started 1.1.1 Installation 1.1.2 Initial configuration 1.1.3 Failsafe mode

Whoops, someone forgot to execute on a TODO. Undeterred, I consulted the usual fallback reference, Google. It pointed me at several references, some of which were hidden on other parts of the OpenWRT site. Armed with these, I was able to determine that:

1. My WRT54GL v1.1 probably uses a Broadcom 5352 chipset.
2. The correct firmware, according to multiple sources, is probably in the kamikaze top-level director, the latest version's subdirectory, and the bcrm-2.4 directory under the version (the link is to 8.09.2, which is current as of March 6, 2010). Apparently the bcrm47xx directory doesn't have wireless support; it helpfully contains a file called NO-BROADCOM-WIRELESS to warn you off, but unhelpfully doesn't include any additional information in that file (like what exactly is broken or that you can find a working firmware in a sibling directory) ... oh well.
3. The firmware file that you want is openwrt-wrt54g-squashfs.bin, even though it doesn't match the model number of the router. This directory could use a README file explaining which hardware is supported by each of the dozen or so firmware files it contains.

Step 2: install the firmware After Step 1, this was a real relief. I just used the built-in Linksys firmware installer, pointed it at the .bin file, and it went. Step 3: configure the router The installation guide I followed was pretty much silent about what to do after I got the firmware on. Luckily, this is just a software problem, meaning it's much more familiar territory for me.

1. First things first: I checked that I could still get a DHCP lease. It worked.
2. Armed with that, I tried telneting to the router. I used the resulting root prompt to set a password on the root account.
3. I logged out and tried telneting in. Apparently the router is configured to disallow root logins over telnet if you don't have a password. Good for them (although why allow telnet at all?); oops for me.
4. Luckily, an ssh server was installed by default. I like using keys to log in, so I tracked down the documentation on configuring the server to use public-key authentication; it turns out there's a single global key file named /etc/dropbear/authorized_keys that's exactly like OpenSSH's per-user authorized_keys file. No idea what would happen if I had multiple users, but I won't.
5. The next obstacle: I didn't have an Internet connection. For some reason, my cable modem didn't want to give the router a DHCP lease. On the off-chance that it was remembering too much, I rebooted it and ran ifup wan. That fixed the problem. I still don't know why.
6. Not a step, but a useful note: in the process of figuring the above out, I found readlog. It's basically dmesg for syslog files; it shows the most recent lines written to syslog. This is useful because there isn't a real syslog file, due to the fact that there would be no room to store it on the 54GL.
7. Finally, I had to get wireless working. The documentation is very helpful when it comes to describing the syntax of the wireless configuration. Unfortunately, I read the list of encryption options and missed the section right below where their meanings are explained (although, to be honest, I might not have understood the implications of the explanation without the research I did anyway).

   option encryption none, wep, psk, psk2, wpa, wpa2

   I wanted WPA2 encryption, so I entered wpa2. And nothing worked. After a good hour of trying different options on the client, swapping software components in and out on the router, experimenting with the encryption key syntax, and crawling Google, I finally found my answer. If you just want WPA2 encryption, you must not use wpa2 as the encryption type. Instead, use psk2. It turns out out that wpa2 actually means use WPA2 and also use an external RADIUS server for authentication. psk2 is the system you're familiar with from a typical consumer wireless router.

Step 4: enjoy And with that, it works. Unfortunately, contrary to what I wrote here originally, my Roku still doesn't work. On the other hand, having a real Linux installation is helpful for debugging it. Currently my suspicion is that the router isn't passing multicast packets between the wired and wireless interfaces (broadcast works fine, multicast doesn't). That said, it seems like if I restart Firefly just before I start playing music, I can play reasonably reliably -- as long as I don't stop, because if I do, the Roku forgets that the music server is there. Either way, I've spent about as much time fighting this as I can afford. One lingering worry I have is security; unlike Debian, which has both a security mailing list and tools to inform me when I need to install a security update, the OpenWRT firmware doesn't seem to have any mechanism for distributing security notices. True, there is an openwrt-security-announce list, but it appears to be entirely unused, as is openwrt-announce. Something to keep an eye on, then. Also (file under note to self), I need to remember to verify that the router isn't exposing services to the outside world. The default iptables configuration is hideously complex; with just a quick glance, it could be setting up a floral shop for all I can tell. I'll need to test this empirically and maybe analyze the rules in more depth.

My ex-AM now sort-of mentor Zack asked for help of an Autoconf/Libtool guru with an RC bug... well, The MirPorts Framework taught benz and me, under consumption of a bottle of wine, how to deal with that stuff. So I've fixed #559822 (CVE-2009-3736, another of them...) and NMU'd. Sort of a PITA, considering gettextize runs interactively, and there's a lot of files to remove in debian/rules:clean for a double-build to not add nonsensical files to the .diff.gz; but I did it in the end.

I spent the day working with Daniel. He has been trying to get the correct runes for a GCC build in a strange environment. Turns out all he needed was me to throw stupid ideas at him until one caused him to examine some of the generated intermediate symbol maps...

As previously mentioned I've switched my webserving over to a mixture of apache2 & thttpd. I chose thttpd as it is simple to configure for my needs, and supports the execution of CGI scripts. Some of the other simple webservers available to Debian's current stable release (such as nginx) don't support CGI so they were ruled out. Of course prior to choosing thttpd I looked at the state of the Debian package. Distressingly the package has no current maintainer and has several bugs open, including some that have been open for several years without comment. I've just made my second upload fixing a couple of bugs, including ones that I could see affecting myself, but now I'm done with it. In conclusion:

• I've fixed a few bugs.
• I suspect that many of the open bugs are 100% unreproducable and should be closed after checking with the submitter.
• The package could do with a volunteer to maintain it.

On the one hand it is "just another webserver", on the other hand it is genuinely small, simple to configure, and has a couple of compelling features (CGI + throttling). So. Go. Adopt. Maintain. Pretty please... ObFilm: Red Sonia

The video of our talk at FOSDEM 2010 didn t come out great, so I ve made a slidecast of the RDF beginners guide that I gave as part of that talk. Enjoy below! At FOSDEM we also announced a competition for the coolest hack using RDF, SPARQL and Tracker with the prize kindly sponsored by Codethink. The prize is a Google Nexus One. After some discussion we ve decided to open up the competition to everyone and extend the deadline to the 15th of March. So if this tutorial inspires a great idea, get it coded up and submitted! On #tracker on GIMPNet there are great bunch of hackers who can help you get your idea up and running. There are no hard rules for the competition, we just want to see implementations of cool ideas. The code doesn t have to be perfect, the only requirement is that the judges can check it out and run it on their systems. All entries should be submitted to tracker-competition@codethink.co.uk by the deadline. <object height="300" width="400"><param name="allowfullscreen" value="true"><param name="allowscriptaccess" value="always"><param name="movie" value="http://vimeo.com/moogaloop.swf?clip_id=9848513&amp;server=vimeo.com&amp;show_title=1&amp;show_byline=1&amp;show_portrait=0&amp;color=&amp;fullscreen=1"><embed allowfullscreen="true" allowscriptaccess="always" height="300" src="http://vimeo.com/moogaloop.swf?clip_id=9848513&amp;server=vimeo.com&amp;show_title=1&amp;show_byline=1&amp;show_portrait=0&amp;color=&amp;fullscreen=1" type="application/x-shockwave-flash" width="400"></embed></object> RDF Beginner s Guide from Rob Taylor on Vimeo. Update!
Looks like I hit a bug in PiTiVi that caused the render to get mangled. I ve rerendered and it should all be good now. If Vimeo is being slow for you , you can download the ogg here. Edward, I promise to log a repro as soon as I can!

My automatic rule-based time tracker (arbtt), which is written in Haskell, collects every minute a data sample consisting mainly of the list of currently open windows (window title and program name). Naturally, this log grows rather large. Since October of last year, I collected 70,000 samples. I already went from a text-based file format to a binary format using Data.Binary, which gave a big performance boost.
But by now, I was afraid that this is not enough. My log file is now 30MB large. Looking at the memory graph of gnome-panel, it is taking up more than half of my memory. When running arbtt-stats, the Haskell run time system reports 569 MB total memory in use and the command finishes after 28.5 seconds. Naturally, the log file is highly redundant: Compressing it with bzip2 shrinks it to 1.6MB. But as I would like to preserve the ability to just append samples at the end, without having to read the file, I chose not just to add bzip2 or gzip compression. Rather, I am now exploiting a very obvious redundancy: Two adjacent samples usually list exactly the same windows, and a focus change only changes a flag. So now, when storing a string that is part of a sample, it will check if this string was already present in the previous sample and, in this case, just store the number of that string (one byte). Only if the string was not present it will write a zero byte and then the string. When reading the sample, the process is reversed. This greatly reduces the file size: It is down to 6.2MB. It also improves the memory consumption, due to Haskell s abilities with regard to sharing: When a reference to a string in a previous sample is read, then only one instance of this string is in memory, even if it occurs several times in the log. This brings the memory consumption down to 264 MB and the runtime to 17 seconds. I released the changes as version 0.4.5.1 to Hackage, Debian and as a Windows installer. The log file is not automatically converted, but new samples will be written in the compressed format. If you want to convert your whole file, you have to stop arbtt-capture, run arbtt-recover, and then move the hopefully noticeable smaller ~/.arbtt/capture.log.recovered to ~/.arbtt/capture.log.
The required code changes were not too big. I somewhat isolated the relevant code in the Data.Binary.StringRef module. Unfortunately, I have to use OverlappingInstances to be able to provide the special instance for String is there a cleaner way (besides the trick used for the Show class)?

This post is about an upcoming feature in Zeitgeist 0.3.3 and is so far only available in checkouts from trunk or our PPA. It is expected to be released within the next weeks. Some weeks ago I implemented a new feature in Zeitgeist and I figured I d drop some lines about it. I m talking about a data-source registry. You may be wondering, what the hell is that even, a data-source? . So Zeitgeist is a database, a global event log, but it doesn t do any magic indexing or monitoring by itself; the information it logs needs to come from somewhere be it applications sending it to Zeitgeist themselves, daemons, plugins for applications, etc. Any such entity is called a data-source . Having a register of all data-sources interacting with Zeitgeist provides some benefits, like for example:

• Having a list of them. Lists are nice :).
• Being able to disable data-sources from a centralized place instead of requiring each to write its own preferences dialogue.
• Being able to set up a blacklist rule considering which data-source the information comes from as a condition (not implemented yet).

More details When they register, data-sources will need to provide the following information: an unique ID, a name (may be localized), a description (may be localized) and optionally a template specifying what sort of events it logs. Additionally, the last timestamp the data-source was seen by Zeitgeist, whether it is running right now and whether it is enabled will also be available. It is important to note that registration is not compulsory; while it is highly encouraged for data-sources to use it, is it still possible to anonymously insert information into Zeitgeist (for example from a shell script). The event template is also only informational, and will not be enforced by Zeitgeist at this time. Avoiding duplicates from GTK Recently Used You may know that zeitgeist-datahub provides basic support for applications which have no direct Zeitgeist support but do use GTK s RecentManager, which is not as detailed as we would like, but it is better than nothing. However, until now we had a problem: when applications had support for both, GTK s Recently Used and Zeitgeist (be it native or as an extension), it was possible for duplicate events to be inserted or other sorts of conflicts between both data-sources. Now that we have the information from the registry available, we ve been able to solve this modifying our Recently Used data-source to ignore any events concerning applications which already have another data-source logging the same types of events.

---

In case you don t care at all about what I m talking here and you just want to see fancy interfaces, go check this out. Related posts:

1. Zeitgeist is out!
2. Introduction to Zeitgeist 0.2 s API
3. Zeitgeist Hackfest (II)

---

No comments
Siegfried-Angel Gevatter Pujals, 2010. Permalink License Post tags: gnome, Programari lliure, zeitgeist

Time for a little end-of-the-month looking back. (Looking back o-ver my shoul-der ) What about X11-based graphical installer? After the one-week rush early this month, a summary of my findings was posted on debian-boot@, including udebs, patches, and source packages, labelled as v1. People seemed to like the idea, and I received a bunch of comments to fix or improve various things. It took some time to implement everything in a satisfying (at least to me) manner, but I reached a point where I was confident enough to publish a v2 set of udebs, patches, and source packages. That was also announced on debian-boot@, and then re-announced once I ve been able to rebuild the image with speakup enabled again. Hopefully, that ll be (more or less) the final plan, and d-i folks should either give us a green or red light based on that v2 set. Some details will have to be ironed out (some items were mentioned in both v1 and v2 summaries), but they shouldn t prevent us from starting adding the needed udebs; or at least not too long. Speaking of X11, xserver-xorg-video-intel is buggy as hell! Basically, yes, and that s known. Many bugs were due to kernel issues, and regressions got fixed in the series of 2.6.32.y stable updates. Usually, upgrading to at least 2.6.32-3-$arch (from linux-2.6 s revision 2.6.32-9) helps, as well as running latest libdrm, xserver-xorg-core, and mesa from sid. Trying with some 2.6.33-ish kernels from experimental would be nice as well. You re of course very welcome to keep us posted through the bugs you opened already, closing them if appropriate. And before reporting more bugs, please make sure you re running recent versions of all those components. That should help people walking the list of remaining bugs to deal with them more efficiently. A very annoying bug which can still be experienced with an up-to-date sid environment is described in freedesktop s #26723.

In the past, several of my Puppet modules have been tightly coupled. A perfect example is Apache and Munin. When I install Apache, I want munin graphs set up. As a result my apache class has the following snippet in it:

munin::plugin   "apache_accesses":  
munin::plugin   "apache_processes":  
munin::plugin   "apache_volume":  

This should make sure that these three plugins are installed and that munin-node is restarted to pick them up. The define was implemented like this:

define munin::plugin (
      $enable = true,
      $plugin_name = false,
      )  
   include munin::node
   file   "/etc/munin/plugins/$name":
      ensure => $enable ?  
         true => $plugin_name ?  
            false => "/usr/share/munin/plugins/$name",
            default => "/usr/share/munin/plugins/$plugin_name"
          ,
         default => absent
       ,
      links => manage,
      require => Package["munin-node"],
      notify => Service["munin-node"],
    
 

(Note: this is a slight simplification of the define). As you can see, the define includes munin::node, as it needs the definition of the munin-node service and package. As a result of this, installing Apache drags in munin-node on your server too. It would be much nicer if the apache class only installed the munin plugins if you also install munin on the server. It turns out that is is possible, using virtual resources. Virtual resources allow you to define resources in one place, but not make them happen unless you realise them. Using this, we can make the file resource in the munin::plugin virtual and realise it in our munin::node class. Our new munin::plugin looks like:

define munin::plugin (
      $enable = true,
      $plugin_name = false,
      )  
   # removed "include munin::node"
   # Added @ in front of the resource to declare it as virtual
   @file   "/etc/munin/plugins/$name":
      ensure => $enable ?  
         true => $plugin_name ?  
            false => "/usr/share/munin/plugins/$name",
            default => "/usr/share/munin/plugins/$plugin_name"
          ,
         default => absent
       ,
      links => manage,
      require => Package["munin-node"],
      notify => Service["munin-node"],
      tag => munin-plugin,
    
 

We add the following line to our munin::node class:

File<  tag == munin-plugin  >

The odd syntax in the munin::node class realises all the virtual resources that match the filter, in this case, any that is tagged munin-plugin. We've had to define this tag ourself, as the auto-generated tags don't seem to work. You'll also notice that we've removed the munin::node include from the munin::plugin define, which means that we no longer install munin-node just by using the plugin define. I've used a similar technique for logcheck, so additional rules are not installed unless I've installed logcheck. I'm sure there are several other places where I can use it to reduce such tight coupling between classes.

In an update to an earlier article I posted, it appears that the Google executives in question have been convicted: http://www.corriere.it/salute/disabilita/10_febbraio_24/dirigenti-google-condannati_29ebaefe-2122-11df-940a-00144f02aabe.shtml (in Italian) They were convicted for having failed to block the publication of a video showing some teenagers picking on and hitting another minor with Down's syndrome. It will be interesting to see how Google reacts. Apparently, the court believes that Google is criminally responsible for videos its users happen to post, which means that they would, in theory, have to personally review every video submitted to determine whether they are going to be infringing on someone's rights because of its content? Update: Here's a New York Times link: http://www.nytimes.com/aponline/2010/02/24/business/AP-EU-Italy-GoogleTrial.html

Update 2: "cate" posted a link to Google's official response: http://googleblog.blogspot.com/2010/02/serious-threat-to-web-in-italy.html Also, it's really incredible to read the comments here (in Italian): http://vitadigitale.corriere.it/2010/02/processo_vivi_down_google_cond.html Most of them are against this ruling, but a significant number think it's a good thing, which just goes to show that you can't put all the blame on politicians for Italy's woes: someone is voting for them, after all.

The t-prot package might need your help: There is a discussion going on with the upstream developer how to proceed with respect to a hopefully helpful change in its behavior. There are several options how to address this, one of them would involve using the Getopt::Long module instead of Getopt::Mixed. Given that the benchmarks of upstream rather speak for sticking with Getopt::Mixed we would like to ask you for help: Please test this version of t-prot (for your safety: detached gpg signature for the version) and compare it to the packaged version 2.15 that I just upload into unstable (it is installable without anything else also into (old)stable or testing). Your feedback on this is truly appreciated, please send it until the start of next week (Monday evening/Tuesday morning) to "t-prot (AT) tolot.escape.de". Much thanks in advance!

I've been overhauling the way that I am host a number of virtual websites upon my main box. Partly to increase security, and partly for a cleaner separation or roles, ownership, and control. (In general everything on my box is "mine", but some things are "ours"...) After a fair amount of experimentation I decided that I wasn't willing or able to rewrite all my Apache mod_rewrite rules just yet. So my interim plan was to update each existing virtual host:

• Add a dedicated user & group to run it under.
• Launch it via a minimal server listening upon the loopback adapter.
• Have Apache 2.x proxy through to it.
  • Expanding any mod_rewrite rules prior to the proxying.

To make it clear what the users were for I decided that every hosting-user would have an "s-" prefix. So the virtual host "static.steve.org.uk" was initially going to be served by the s-static user. The thttpd configuration file would look like this, and would be located in /etc/thttpd/sites/static.steve.org.uk:

host=127.0.0.1
port=1008
dir=/home/www/static.steve.org.uk/htdocs/
chroot
user=s-static
throttles=/etc/thttpd/throttle.conf
logfile=/home/www/static.steve.org.uk/logs/thttpd.log
pidfile=/home/www/static.steve.org.uk/pid/file

(I wrote a trivial script to stop/start all the sites en mass, and removed the default thttpd init script, logrotation job, and similar things.) How did I decide which port to run this instance under? By taking the UID of the user:

steve@skx:~$ id s-static
uid=1008(s-static) gid=1009(s-static) groups=1009(s-static)

With this in place I could then update the Apache configuration file from serving the site directly to merely proxying to the back-end server:

<VirtualHost *>
    ServerName  static.steve.org.uk
    # Proxy ACL
    <Proxy *>
        Order allow,deny
        Allow from all
    </Proxy>
    # Proxy directives
    ProxyPass          /   http://localhost:1008/
    ProxyPassReverse   /   http://localhost:1008/
    ProxyPreserveHost on
</VirtualHost>

So was that all there is to it? Sadly not. There were a couple of minor issues, some of which were:

cronjobs

I have various cron-jobs in my main steve account which previously updated blog indexes, etc. (I use namazu2 to make my blog searchable.) I had to change the ownership of the existing indexes, the scripts themselves, and move the cronjob to the new s-blog user.

cross-user dependencies

I run a couple of sites which pull in content from other locations. For example a couple of list summaries, and archives. These are generally fed from a ~/.procmail snippet under my primary login. Since my primary login no longer owns the web-tree it is no longer able to update things directly. Instead I had to duplicate a couple of subscriptions and move this work under the UID of the site-owner.

I'm no longer running apache

For a day or two I'd forgotten I was using the apache facility to include snippets in my site; such as links to my wishlist. Since I'm not using Apache in the back-end server-parsed files no longer work. Happily I'm using a simple template-based setup for my main sites, so I updated the template-parser to understand "##include ./path/to/file". For example this source file produces my donation page. The upshot is my "static" site is even more static, which is a good thing.

uploads are harder

Several of my domains host entirely static content which is generated on my main desktop machine, and then uploaded via rsync post-build. I had to add some more accounts and configure SSH keys, then update the uploading routines/Makefiles appropriately. Not a major annoyance, but suddenly my sshd_config file has gone from "PermitUser steve,backup" to including many additional accounts.

The single biggest pain was handling my my mercurial repositories - overhauling that took a bit of creativity to ensure that nothing was broken for existing or new checkouts. I wish that a backport of mercurial-server was trivial because I'd love to be using that. In general though watching the thttpd logs has been sufficient to spot problems. I had to tweak things a little to generate statistics properly, but otherwise all is good. Why thttpd? Well small, lightweight, and the ability to run CGI scripts. Something missing from nginx for example. I'm still aiming to remove apache2 from the front-end - it is mostly just a dumb proxy, but it does perform some ACL operations and expand mod_rewrite rules. I could port those to another engine .. but not today. The most likely candidates are nginx, perlbal, or lighttpd - each of these should be capable of doing simple ACL checks, and performing mod_rewrite-like rules. ObFilm: Mallrats

LC_ALL=C debian/rules debian/control
md5sum --check debian/control.md5sum --status   \
		/usr/bin/make -f debian/rules debian/control-real
make[1]: Entering directory  /home/wouter/debian/other-peoples-source/linux-2.6-2.6.32'
chmod +x debian/bin/gencontrol.py
debian/bin/gencontrol.py
Traceback (most recent call last):
  File "debian/bin/gencontrol.py", line 331, in <module>
    Gencontrol()()
  File "debian/bin/gencontrol.py", line 14, in __init__
    self.process_changelog()
  File "debian/bin/gencontrol.py", line 305, in process_changelog
    (distribution, version))
RuntimeError: Can't upload to unstable with a version of 2.6.32-8~local1
make[1]: *** [debian/control-real] Error 1
make[1]: Leaving directory  /home/wouter/debian/other-peoples-source/linux-2.6-2.6.32'
make: *** [debian/control] Error 2

The issue at hand was that I'd created a version of '2.6.32-8~local1', to document that I'd locally branched version 2.6.32-7 with that one config option turned on, but that my version should not be deemed larger than 2.6.32-8 (signalled by the ~ and whatever follows that). However, something somewhere in the Debian kernel build system (I was unable to figure out what, exactly) disliked that version number and told me I could not upload to unstable with that version. So it borked, and told me I had to fix my version. Well, no, I don't want to do that. Instead, I wanted to disable that check somehow. Turns out that isn't too hard; gencontrol.py not only checks the version number, it also checks the target distribution. So if you don't want to upload to unstable, you just need to tell the tool that:

-linux-2.6 (2.6.32-8~local1) unstable; urgency=low
+linux-2.6 (2.6.32-8~local1) local; urgency=low

Simple, but you'd need to know.

After some stability problems and an unresolvable PCI IRQ problem with my Debian server at home (Internet gateway, mail, PostgreSQL, LDAP and NFS server and test system), I decided to get a new mainboard and wireless card last week. I did some research to get hardware that is properly supported and where I can use the rest of my current components. I had

• a AM2 socket AMD Athlon64 3500+ CPU
• 2 1GB DDR2/667 DIMMs
• a ATX chassis
• an IDE Transcend 4GB SSD for my root partition
• 2 750GB SATA hard disks (software RAID-1)
• a Intel EtherExpress 100 Server PCI adapter (that I wanted to use to separate the internal and external networks but which did not work due to the above mentioned PCI trouble)

So I had to find a mainboard with at least 2 DDR2 DIMM sockets, an AM2 compatible CPU socket in ATX format with SATA ports at least one IDE Port, a Gigabit ethernet port (serving NFS home directories) and at least 2 PCI slots (one for the wireless card) that is well supported by the current Debian Squeeze Linux kernel. As I had some issues with the previous board's nvidia SATA chipset I wanted to get something else that is AHCI compatible. After some research I decided to buy a Gigabyte GA-MA74GM-S2H (rev. 3.0) which is available for a good price and fits all my criteria (2 DDR2 DIMM slots, 6 SATA ports, an RTL8169 based Gigabit ethernet ports, 2 PCI slots, ...). The mainboard uses an AMD 740G + SB710 Chipset. It has an integrated graphics chipset which I don't really need because I run the machine as a headless system. As I use the server as a wireless access point I need a wireless network adapter that supports AP mode. There are not many chipsets that are properly supported in AP mode and allow good data rates so I decided to get an Atheros ath9k based card, because I don't need non-free firmware like with broadcom based cards and could find some affordable hardware. The previous was a Netgear WG311 ath5k card that had issues that it lost its connection under more than minimum load and could only be reanimated by a system reboot. I looked at the Linux Wireless pages and found out that D-Link has a matching adapter the DWL-G520. Unfortunatelly they don't tell about the used chipset (as almost all other vendors too) and write about possibly changing hardware at the product sheet. To be sure I looked at their Windows driver's .inf files and found nothing indicating that there are any non Atheros variants of the card. I also ordered two Fantec MR-35 SATA mobile racks for more comfort when one of the RAID1 discs crashes (had 2 crashes last year) and a 12" chassis fan to keep the system cool. Today the package arrived and after unpacking and putting everything together I started the system (with keyboard and a display attached) to see how it works. All hardware was automatically detected by the current Debian Squeeze system and I only had to remove the entries for the old onboard network adapter and the old wireless adapter from /etc/udev/rules.d/70-persistent-net.rules and fix the device names for the new network cards. I added a new stanza for the Intel ethernet adapter in /etc/network/interfaces and setup a set of ferm rules to have a working firewall (thanks to Formorer for the suggestion to use ferm). After this was finished everything worked fine so far and I put the machine at its normal place without keyboard and display. To verify that the stability situation had really improved, I copied some huge files over the network (both wired and wireless and in both
directions). Afterwards I did a bonnie++ benchmark to test the SATA and hard drive reliability. Everything went well and I'm happy with my investment.

As part of some house-keeping I've been checking over my systems and ensuring they're all tickity-boo for the past couple of days. One thing that I'm getting increasingly tempted by is converting my kvm guest to a 64-bit system. I've not quite sold myself on the prospect of what will be a fair amount of downtime, but I'm 90% there. I do think that a lot of my setup needs an overhaul, for example:

• Running all my websites under www-data is beginning to worry me.
• Running services as root is beginning to make me more and more paranoid.

One possible plan is to wipe my system, and then restore data from backups. A perhaps saner approach is divide my guest into two smaller ones, and migrate services over one by one (e.g. website1, website2, .. websiteN, email, etc). For the moment I've taken a complete dump of my existing guest, and I'm running it with an IP in the 10.0.0.0/24 range on my desktop. That's at least given me a clear idea of the amount of work involved. I'm still a little unclear on how best to manage running N websites with the intention they'll each run under their own UID. I guess it comes down to having a few instances of nginx/lighttpd/apache and then proxy from *:80 to the actual back-end. Precisely which mixture of services to use is a little overwhelming. Though at some point soon I need to start enabling IPv6 support, and that changes things a little. (Not least because nginx has no IPv6 support present in the Lenny release - I've got a backported package which I run on the Debian Administration website.) It's possible I could hack mod_vhost_alias to redirect/proxy to a local port based upon the virtual hostname present in the request - that's pretty trivial and I've already done something similar for work purposes. Though something like that should presumably already exist? I would expect a map of some form:

example.org: 127.0.0.1:8080
example.net: 127.0.0.1:9090

That has to be about the minimum necessary information to make the decision; a pair of vhost name & local destination. /me googles some.. Update

OK quick update I've added local users for some of my sites, and now have them running under thttpd.

skx:/etc/thttpd# ls -ltr /home/www/   tail -n 4
drwxr-sr-x  4 s-static   s-static   4096 Jan 15 01:41 static.steve.org.uk
drwxr-sr-x  5 s-openid   s-openid   4096 Feb 16 21:31 openid.steve.org.uk
drwxr-sr-x  6 s-images   s-images   4096 Feb 16 21:52 images.steve.org.uk
drwxr-sr-x  5 s-packages s-packages 4096 Feb 16 22:03 packages.steve.org.uk

That seems to work well, with a small wrapper script to start N instances of thttpd instead of a single one. Minor issues are that I'm using mod_proxy to forward requests to the thtpd instances running upon the loopback - and it was initially logging 127.0.0.1 as the source IP. A quick patch later all is well. I'll leave it running a couple of the simple sites for the next few days and see if it kills children. If it does I'll convert the rest. Probably will aim to have nginx in front of thttpd, instead of Apache, but this way I don't have to worry about mod_rewrite rules just yet.

ObFilm: Cruel Intentions