Search Results: "ag"

18 September 2010

Jamie McClelland: From vservers to KVM

Given the impending deprecation of vservers, I've decided to make the switch to KVM on my laptop. Although lxc is a closer approximation to vservers, I decided to go with KVM due to it's support in Virtual Machine Manager. My first step was to confirm that my CPU would support kvm:
egrep -o "svm vmx" /proc/cpuinfo
If that command outputs either svm or vmx (depending on whether you have Intel or AMD hardware) then your CPU supports virtualization. I'm working on a host machine called chicken, which has a logical volume called vg_chicken0. All vservers on chicken operate on a root filesystem that is backed by their own logical volume. In this post, I'll describe the steps to convert the vserver hobo (which operates on a filesystem mounted on the host in /var/lib/vservers/hobo and is backed by the logical volume called vg_chicken0-hobo_root). Both chicken and hobo are running debian squeeze. vservers don't have a kernel installed or grub. KVM virtual servers need both. I was hoping I could simply enter the vserver, install both a kernal and grub and be ready to go. However, grub installation will fail miserably because grub can't figure out how to install on the underlying disk (which is hidden from the vserver). Next, I tried launching a kvm instance, passing a debirf generated ISO with the -c (cdrom) option. However, grub recognized that it was being installed onto a device that did not have a partition table (the logical volume was directly formatted with a file system). So, since I had disk space to spare, I created a new logical volume:
lvcreate --size 5GB --name hobo_root_new vg_chicken0
I then added a gpt partition table (why not prepare for the coming 2TB disks?) and created two partitions. One partition for grub2 and one for everything else:
parted /dev/mapper/vg_chicken0-hobo_root_new mklabel gpt
parted /dev/mapper/vg_chicken0-hobo_root_new unit s mkpart biosboot 2048 4095 
parted /dev/mapper/vg_chicken0-hobo_root_new set 1 bios_grub on 
parted /dev/mapper/vg_chicken0-hobo_root_new unit s mkpart primary 4096
When prompted for the end of the last partition, choose: -1 and accept the adjustment. I had to eyeball cat /proc/partitions to figure out which dm device was the second partition (dm-19). I then created a file system:
mkfs -t ext3 /dev/dm-19
Mounted it:
mount /dev/dm-19 /mnt
And rsync'ed the data:
rsync -a /var/lib/vservers/hobo/ /mnt/
With the data in place, I chroot'ed and installed the packages I needed. When prompted, I chose not to install grub to the disk, because I wanted to wait until I had an environment in which the proper disk would be available to grub as it will when the virtual server boots (see below):
chroot /mnt
mount /proc
aptitude install linux-image-2.6-amd64 grub2
umount /proc
exit
Then, I cleaned up:
umount /mnt
umount /var/lib/vservers/hobo
lvremove vg_chicken0/hobo_root
lvrename vg_chicken0/hobo_root_new hobo_root
dmsetup remove /dev/mapper/vg_chicken0-hobo_root_newp1
dmsetup remove /dev/mapper/vg_chicken0-hobo_root_newp2
kpartx -d /dev/mapper/vg_chicken0-hobo_root
And I removed it from /etc/fstab. Next, I created a new kvm virtual server, using the disk /dev/mapper/vg_chicken0-hobo_root and passing a debirf cd image with -c: virt-install --name hobo --ram 512 --disk /dev/mapper/vgchicken0-hoboroot -c /usr/local/share/debian/ISOs/debirf-rescuesqueeze2.6.32-5-vserver-amd64.iso After logging in, I installed grub2 (aptitude update; aptitude install grub2) and then I installed grub:
mount /dev/sda2 /mnt/
grub-install --no-floppy --root-directory=/mnt /dev/sda
After running grub-install, edit /mnt/boot/grub/device.map so it reads:
(hd0) /dev/sda
Then, rerun grub-install command. I tried generating the grub.cfg file, but got an error message indicating that grub-probe would not detect the device providing / (because I was running on a ram file system from debirf). I added the following to /mnt/etc/fstab:
/dev/sda2  /     ext3 errors=remount-ro 0 1
proc       /proc proc defaults          0 0
And then re-generate the initrd image:
chroot /mnt
mount /proc
update-initramfs -u
So, I rebooted the virtual machine by typing:
exit
reboot
This dropped me into a grub shell. I manually typed:
root (hd0,gpt2)
linux /vmlinuz root=/dev/sda2 ro
initrd /initrd.img
boot
Once booted, I logged in a completed the task with:
update-grub

Peter Makholm: Reading Twitter with generic RSS reader

For a long time I have mainly been reading Twitter with a generic RSS reader (newsbeuter). Recently this stopped working when twitter.com disabled HTTP Basic Auth in preference of using OAuth. Now I can say a lot of good and bad things about OAuth, but to keep a short story short: It doesn t work with generic RSS readers. Instead of getting the RSS feed from a URL, my RSS reader can run a script that prints an RSS feed. So if I could just write a script that does the OAuth dance to convince twitter.com to give me an RSS feed? Perl to the rescue! Or rather CPAN to the rescue: Net::Twitter::Lite have a nice simple example for setting up OAuth with a desktop application. It also provides access to most of Twitters REST API, but no method for retrieving generic URLs. Using some Jedi mind tricks and reading the source I found a private and undocumented method _oauth_authenticated_request which does exactly what I need. It is quite simple:
  1. Get my script from gist.github.com/585710 and install the dependencies (Net::Twitter:Lite).
  2. Register you own app at dev.twitter.com to get a Consumer Key and Consumer Secret.
  3. Run the script once to setup access and get an Access Token and Access Token Secret.
  4. Run the script with an RSS feed url as parameter to get the RSS feeds.
Most interesting feed to follow is probably http://api.twitter.com/1/statuses/home_timeline.atom, which show the same as the home page on twitter.com would show you, and http://api.twitter.com/1/statuses/mentions.atom, which shows any tweet that mentions you.

Lucas Nussbaum: UDD bugs search news

Many changes to the UDD-backed Debian Bugs Search: Enjoy!

Lucas Nussbaum: Helping improve Ruby on Debian and Ubuntu

After my last blog post on Ruby in Debian and Ubuntu, I got a few offers for help, which is excellent. So I ve decided to update this wiki page with pointers to the various team resources, and some examples of tasks that newcomers can do. I d like to stress that many pending tasks are really doable by someone not very qualified in Debian packaging. They are not done just because nobody has the time to do them. Some good examples are the libinotify-ruby, libimage-size-ruby, libffi-ruby RC bugs.

Evgeni Golov: How to bypass DNS-based spam-filters using DNS

I ve been sitting on this one since more than a month. I ve contacted upstream on the 19.08.2010 and the Debian maintainer on the 02.09.2010. No reaction from them till today, and no, my spamfilter does not eat mail ;) Still, I won t tell you the name of the software (but you could easily guess or check ) So let s put the grey hat on and begin ;) Foreword: when I write spam-filter, I mean some DNSBL/SPF/blah filter, not SpamAssassin, crm114 or other content-based filters. common spam-filters There are plenty of spam-filters out there which work after the following schema:
for check in checks:
    if check(mail) == BAD:
        reject(mail)
        break
And the checks often look like this:
def check(mail):
    errors = False
    result = some_magic(mail)
    if not errors: return result
    else: return GOOD
Here some_magic is a function that do the actual checks (DNSBL lookups etc) and which stores possible happened errors in errors. If an error occurred, it s safer to say the mail was good (or at least not bad) than bad. the problem This looks like a sane approach on the first sight: iterate over all checks and execute them until a mail is found to be spam (and the corresponding check did not end up in an error (imagine some weird DNS error for DNSBL or SPF checks here)). But then the author realizes that the errors might be global , like with DNS: when the first check notices that it can t resolve anything (ie. it ran into a DNS timeout three times in a row), the second check (which also utilizes DNS queries) will most probably result in an error too. After this he adds a global counter for DNS errors and skips all the checks that use DNS if this counter is >=3. Great idea , you say, saving resources is good . Bad idea , I say The reason is simple: DNSError != DNSError. Why? The local resolver might be broken, then every DNS query will end up with an error and DNS-based checks should be really disabled. The first three (out of eg. ten) DNSBLs might be down, but that s not a reason to skip the other seven and the SPF check. Etc Now let s assume all configured DNSBLs are working properly, so is the local resolver and the checks are:
checks = [check_HELO, check_SPF, check_DNSBL]
How could one attack this filter? the attack Set up the following zone
spam.example.com IN NS ns1.example.com
spam.example.com IN NS ns2.example.com
spam.example.com IN NS ns3.example.com
spam2.example.com IN MX mx1.spam.example.com
spam2.example.com IN MX mx2.spam.example.com
spam2.example.com IN MX mx3.spam.example.com
spam2.example.com IN MX mx4.spam.example.com
ns1.example.com IN A 10.1.1.1
ns2.example.com IN A 10.2.2.2
ns3.example.com IN A 10.3.3.3
and greet the to-be-spammed-MTA with EHLO client1.spam.example.com
What happens? The spam-filter tries to resolve client1.spam.example.com in check_HELO to check whether the hostname matches the IP-address the connection is coming from, fails three times (there are no reachable DNS servers in 10.0.0.0/8) and continues with the next two checks, but these are skipped because of previous DNS errors. As no checks could identify the mail as being spam, the mail is delivered to the users mailbox. With some creativity this can also be used in SPF records (via spam2.example.com), sender-domains etc. conclusion If you want to save resources by skipping DNS-based checks after another (DNS-based) check failed don t! Think whether this is really the same error you are seeing Additionally this can be used as a sort of DoS against the not said software: according to the logs each of my tries needed between 30 and 36 seconds (!) to complete imagine some hundred simultaneous requests the end You think I did something wrong with that post? Throw the first stone then, I don t care.

Robert Collins: Maintainable pyunit test suites fixtures

So a while back I blogged about maintainable test suites. One of the things I ve been doing since is fiddling with the heart of the fixtures concept. To refresh your memory, I m defining fixture as some basic state you want to reach as part of doing a test. For instance, when you ve mocked out 2 system calls in preparation for some test code that represent a state you want to reach. When you ve loaded sample data into a database before running the actual code you want to make assertions about that also represents a state you want to reach. So does simply combining three or four objects so you can run some code. Now, there are existing frameworks in python for this sort of thing. testresources and testscenarios both go some way towards this (and I and to blame for them :) ), so does the zope testrunner with layers, and the testfixtures project has some lovely stuff as well. And this is without even mentioning py.test! There are a few things that you need from the point of view of running a test and establishing this state: Large test suites or test suites dealing with various sorts of external facilities will also often want to optimise this process and put the same state into place for many tests. The (and I m not exaggerating) terrible setUpClass and setUpModule and other similar helpers are often abused for this. Why are they terrible? They are terrible because they are fragile; there is no (defined in the contract) way to check that the state is valid for the next test, and its common to see false passes and false failures in tests using setUpClass and similar. So we also need some way to reuse such expensive things while still having a way to check that test isolation hasn t been compromised. Having looked around, I ve come to the conclusion we ll all benefit if there is a single core protocol for doing these things, something that can be used and built on in many different ways for many different purposes. There was nothing (that I found) that actually met all these requires and was also tasteful enough that folk might really like using it. I give you fixtures . Or on Launchpad. This small API is intended to be a common contract that all sorts of different higher level test libraries can build on. As such it has little to no policy or syntatic sugar. It does have a nice core, integration with pyunit.TestCase, and I m going to add a library of useful generic fixtures (like temporary directories, environment isolators and so on) to it. I d be delighted to add more committers to the project, and intend to have it be both Python 2.x and 3.x compatible (if its not already my CI machine isn t back online after the move yet, I m short of round tuits). Now, if you re writing some code like:
class MyTest(TestCase):
    def setUp(self):
        foo = Foo()
        bar = Bar()
        self.quux = Quux(Foo(), Bar())
        self.addCleanup(self.quux.done)
You can make it reusable across your code base simply by moving it into a fixture like this:
class QuuxFixture(fixtures.Fixture):
    def setUp(self):
        foo = Foo()
        bar = Bar()
        self.quux = Quux(Foo(), Bar())
        self.addCleanup(self.quux.done)
class MyTest(TestCase, fixtures.TestWithFixtures):
    def setUp(self):
        self.useFixture(QuuxFixture)
I do hope that the major frameworks (nose, py.test, unittest2, twisted) will include the useFixture glue themselves shortly; I will offer it as a patch to the code after giving it some time to settle. Further possibilities include declared fixtures for tests, and we should be able to make setUpClass better by letting fixtures installed during it get reset between tests.

Russ Allbery: GnuPG key replacement

Since last year, I've been slowly working on introducing a new 4096-bit RSA key (complete overkill, I know) with all the modern hash preferences and so forth so that I can retire my old 1024-bit DSA key. After DebConf in New York City at the beginning of August, I now have enough signatures on the new key to finish this transition. If you have signed my old key and are willing to sign the new key on the strength of a key transition document, here is key transition document signed with both the old and the new keys. While my new key has a reasonable number of signatures, I'm always happy to get more. My old key is 0x0AFC7476, and my new key is 0x82004173. You can retrieve the new key (and the old key, for that matter) from any public keyserver or from my web site (new key and old key). Shortly after posting this, I'll submit the RT ticket to transition my key in the Debian keyring. The new key has a 2048-bit signing RSA subkey which I may export to a few places other than my primary secure system so that I can do package uploads in some more convenient ways. The new primary key has a three year expiration period (which will be periodically extended), and the signing subkey has a one year expiration period (likewise).

17 September 2010

Jo Shields: Mono mythbusting, September 2010 edition

There are corners of the Internest where foolish people congregate, and invent stories. These foolish stories are then read as gospel by trusting people, and reposted, until the original made-up source is concealed from view. As an attempt to stem this flow of disinformation, here are some commonly held but incorrect beliefs about the Mono framework, and an explanation of the reality of the situation, as far as I understand it. The next Mono version is co-developed with Microsoft There is a grain of truth behind this one, but it s a gross mischaracterisation. Mono 2.8, when it ships, will bundle, for convenience, a number of Free Software libraries, which are released by Microsoft under a license considered Free Software by the Free Software Foundation, the Ms-PL. These are: So, to summarise, there are five Free Software libraries written by Microsoft under the Ms-PL included in Mono 2.8 but only two of those five are new, and none of them were co-developed in any meaningful sense. Mono development is dead There have been reports that Mono development has ended, on the basis that no commits have been made to Novell s Subversion server for a few weeks. However, these reports miss one minor detail Mono has moved to Github.com. There were 35 commits from 9 different people to the main mono.git repository (of dozens of repositories under the main Mono project) in the last 2 days, at time of writing far from dead. Mono lacks features found in Microsoft.NET Mono lacks libraries found in Microsoft.NET, such as the Windows Presentation Framework GUI toolkit. In terms of features, i.e. things implemented at a compiler or runtime level, Mono is typically more advanced. This is helped in no small part by Mono s Free Software development model, allowing experimentation and what if changes to the core runtime which a sluggish corporate behemoth like Microsoft cannot accommodate. To give three real-world examples, Mono allows embedding of its compiler as a service, and provides a REPL shell this is a planned feature for .NET 5.0, but has been available for years in Mono; Mono.Simd provides a number of data structures which will run on any version of Mono or Microsoft.NET, but will use optimized CPU extensions like SSE when run on a sufficiently new version of Mono, on an appropriate architecture as far as I m aware, there is nothing like this available or planned for Microsoft.NET. Mono is able to produce fully compiled, static executables which do not need to JIT anything at runtime this is used for iPhone compilation, for example, where JITters are not permitted. There is no comparable feature in Microsoft.NET. Clearly, Microsoft.NET can only be thought of as more featureful if one defines features in terms of does it have lots of libraries? in terms of functionality, Mono is ahead. Mono can sneak onto your system without your knowledge If you don t have the mono-runtime package installed, you can t run Mono apps. It is possible to install some Mono apps alongside the awful-yet-popular mononono equivs package, since the popular equivs script fails to place Conflicts on the correct packages (F-Spot will be blocked, Tomboy will not). No package in Debian or Ubuntu embeds its own copy of the Mono runtime, and we have no plans to make any changes to packaging which would allow execution of any C# application without mono-runtime installed. If one is using a different OS, then things may be different e.g. The Sims 3 for Mac & PC uses embedded Mono, which you wouldn t know about without looking. Canonical are pursuing a pro-Mono agenda, and are responsible for it being pushed in Debian Mono development has been happening in Debian for longer than Canonical has existed the first upload was made in April 2002. Ubuntu is made primarily from software already available in Debian deemed of sufficient quality, and when F-Spot and Tomboy became parts of the default Ubuntu desktop system in 2006, both pieces of software were already available in Debian and deemed of sufficient quality. Nobody working on Mono in Debian is paid by Canonical actually, that s not entirely true, three packages related to accessibility are officially maintained by someone who was hired by Canonical after doing the initial packaging work when he worked for Novell. But the Mono runtime itself, Canonical have no influence over its direction in Debian. As for a pro-Mono agenda , they ve always taken an extremely pragmatic approach to language choice, never showing any real preference for one language or another when it comes to app selection. They don t exhibit any overt anti-Mono policies, which is not the same thing. The names of people contributing to Mono in Debian are not secret check the pkg-mono team page on Alioth. The System.Windows.Forms namespace is protected by Microsoft patents The truth is, nobody knows for sure if SWF, or any other part of Mono, or any other framework such as Vala or Python, is covered by Microsoft patents. The way the US patent system is contrived, it is actively dangerous to check whether something contains any patents when you write it, as you are liable for triple damages should it later emerge that there WAS a patent, even if your searching missed the fact. You cannot patent an API or namespace only a specific implementation of a software concept, in those countries where software patents are permitted. There has never been any evidence shown that Mono s implementation of SWF, or indeed any part of Mono, infringes any Microsoft-held patents, because if that were the case, then the code would be rewritten to avoid the issue much like the approach taken by Linux kernel developers when a patent becomes apparent. The belief within the Mono community is that the core parts of Mono as defined in ECMA334/335 are safe (they are covered by the Microsoft Community Promise patent grant); any of the Ms-PL libraries mentioned above is definitely safe (Ms-PL includes an explicit patent grant); and the rest of the package is likely safe too (on the basis that it is a named component of the Open Innovation Network s list of protected software and on the basis that there s unlikely to be anything patentable in one of many implementations of basic ideas like database connectors). Nobody knows for sure, because that s how the system works. But, again, nobody knows for sure that Microsoft patents don t apply to other frameworks such as Python there is simply a belief and an assumption that they do not. MonoDevelop contributors removed GPL code from MonoDevelop, in an attack on the GPL This is somewhat disingenuous, given MonoDevelop is LGPL. The MonoDevelop team excised the remaining GPL code (and there wasn t much of it) in order to grant greater Freedom to developers. Previously, the entire MonoDevelop IDE was a GPL combination, meaning any add-ins for the IDE also needed to be GPL, regardless of developer choice. Now, any developer can write an add-in for MonoDevelop, using the license of their choice, whether another Free license like the Mozilla Public License, or a proprietary closed-source add-in. They are still welcome to produce GPL add-ins, if they want to, as well. Mono won t run random Microsoft.NET apps anyway, so isn t really cross-platform Actually, this one is often true. When developers write apps for Windows primarily, they rarely take the time to think is this the correct way to do it? and will often plough on with an assumption about the Windows way of doing things. It might be simple things like filesystem assumptions (assuming a case-insensitive filesystem, or assuming a backslash is used to separate directories, not a forward slash). It might be more involved, such as using P/Invokes into Windows-specific C libraries, when a more cross-platform alternative is possible. So, often, random applications for Microsoft.NET won t run on Mono. The reverse is also true F-Spot or GNOME Do are fairly heavily tied to Linux (or to UNIX-like OSes with X11, at any rate), through the libraries they invoke being fairly platform-specific. You can write platform-specific Java, with one quick piece of JNI, too. It should be noted, however, that Mono makes the chance of .NET applications being ported to Linux (and/or Mac) much more likely, since even in the worst case scenario, a company only needs to fix a portion of their source to make it cross-platform. The Mono team have a tool called MoMA, which will scan an application and its libraries, and give you detailed reports on the app s portability. This info is used at both ends by app vendors who want to become more portable, and by the Mono team who want to fill in the most frequently encountered blanks. And, it should be stressed, writing cross-platform apps is entirely possible if one desires it e.g. the IRC client Smuxi is pure cross-platform C#, and the executables compiled on Mono on Linux will run fine on Microsoft.NET on Windows. Portability in this direction is important too consider how many people have been introduced to Free Software thanks to availability of Free apps on Windows like OpenOffice.org, Firefox, Pidgin or GIMP. You can download Tomboy for Windows, and work is ongoing on fixing Banshee portability issues (which are mostly caused by gStreamer). Mono on Android is a terrible idea which will be super slow There are two efforts to enable developers to write Android applications with Mono a paid proprietary product from Novell called MonoDroid, and an untitled porting effort by big-name Android hacker Koushik Dutta. I have no insight into MonoDroid since it hasn t been released yet, but Koush did some benchmarks of his work which exhibited some remarkable figures compared to Dalvik (and even compared to Sun Java for ARM). Those numbers haven t been updated to reflect the Froyo Dalvik JITter, but Mono on Android is still very exciting from a performance perspective. Mono isn t really Free Software The source code is all available under Free Software licenses. So, um, yes it is. We don t need Mono because we have $LANG By the same logic, we don t need $LANG because we have Mono. By all means, use the language of your choice other developers will use the language of their choice too. If you want to use Vala or Python or Java, then by all means, go ahead. It doesn t mean there s no room for more languages, better suited to other usage patterns. Haskell is great for some types of development, so is Fortran, and so is C#. You might not need Mono because of $LANG, but there are others in the world with different needs. Mono apps are all slow, and crash your computer, and stuff No userland app can crash your Linux system, unless there s a bug in the kernel, or you have some severe problems with your hardware. If you ve ever observed a crash as a result of running a Mono app, then it s really coincidence that Mono is tickling whichever part of your system is busted. As for slow startup time may well be slower than for apps written in C or Vala. There s a delay due to the JITter needing to compile all the libraries used by the application (we may AOT the most common libraries in a future Mono package version, at upstream s recommendation). Once an app is running, it should be fast compared to a Python app, and memory-light compared to a Java app. The new garbage collector in Mono 2.8 should also offer significant improvements to performance, especially under heavy workloads. Ubuntu s default GTK+ themes require Mono This is my favourite recent nonsense to emerge from the Internest. There are reports mostly restricted to IRC and blog comments, that (paraphrasing here) removing Mono removes the Ubuntu themes . Here s the reality: in Ubuntu 10.04, a new visual style was implemented throughout the distro. As part of this, small icons (e.g. notification area icons) were set to be black-and-white by default, and colourised when attention is needed (e.g. the power-off icon turns red when a reboot is needed, the messaging indicator turns green when there s a new message). All of these new monochrome icons are in a package named ubuntu-mono . Removing the ubuntu-mono icon package will also remove the new Ubuntu GTK+ themes, in the light-themes package. So there s your explanation: the themes have a dependence on some monochrome icons, not on the Mono framework.

Matthew Garrett: USB runtime power management

I've just committed some patches to the rawhide (not F14) tree that re-enable USB autosuspend on some devices. This set includes a workaround in the bluetooth input code that should handle the case where people were seeing their input devices become laggy when autosuspend was enabled, but there's still some chance that other bluetooth devices will behave slightly oddly. If that's the case then try:

echo on >/sys/class/bluetooth/hci0/device/power/control

and see if it improves things. If so then please file a bug and include information about the device you're trying to connect to.

The other thing this patchset does is enable USB HCD runtime power management by default. This means that if you have a host controller with nothing connected, or with connected but suspended devices, the host controller will be powered down. It'll automatically power back up if a device is connected or a connected device sends a wakeup event. The obvious failure mode here is that your USB ports stop working. If that happens, please file a bug and include the output of lspci and dmidecode (you may want to edit the dmidecode output to make sure that your serial numbers are removed). In both cases, assign the bug to me (mjg at redhat.com).

Once this seems fairly stable I'm going to be looking at powering down more mostly unused PCI devices. SD readers and firewire controllers are typically unused and both support generating wakeup events, so they're the next step.

Steve Kemp: Room for another reverse-proxy?

Like many people I use Apache's mod_proxy to proxy from *:80 to a bunch of servers running upon 127.0.0.1:XX. (I've mentioned this too often; but in short I have a bunch of sites all running with thttpd under their own UID). Why do I use apache soley as a reverse proxy, instead of pound, varnish, nginx, or lighttpd? After all it is pretty heavy-weight. Well the answer to that is that I have a bunch of mod_rewrite rules. So I'm wondering, could I drop apache if I were to hack together a simple network proxy that would listen upon port 80, reading requests, and directing them to local servers? The answer to that is plainly "yes". There are many reverse-proxies around and writing them isn't hard. So what would be the point? Imagine a reverse-proxy that understood mod_rewrite rules. That would rock. In short we'd have to define three things: Given something like this:
LISTEN 1.2.3.4:80
host example.net or host www.example.net
 
   #redirect traffic here
   proxy_to 127.0.0.1 1011
   RewriteRule /about /cgi-bin/index.cgi
 
When the proxy received an incoming request to http://example.net/about it would actually send the request /cgi-bin/index.cgi to the host 127.0.0.1:1011. That seems neither too complex nor too impossible. The hard part would be emulating mod_rewrite 100%. Especially chained requests. I would be willing to write the trivial version, but I suspect the full emulation would be a job of diminishing returns. Am I right? ObSubject: You crossed the line first, sir. - "The Dark Knight"

Joerg Jaspert: FTPMaster meeting, I

I announced it some while ago on debian-project, we have a FTPMaster meeting this weekend. It started out with a little workout session View image before we started discussing some things from our agenda. In the middle of the discussion we took a little sidestep, looking for a victim to promote to ftpmaster. So we selected someone not attending, he can t run away screaming. And for that: Send your condolences over to Torsten Werner. Or maybe congratulations, your call :) Right now Mark is fixing up our byhand processing and Alex is doing some other Debian work, while I m merging patches from Luca. Thats it for now, sometime soon we are going to eat, after which we put some more discussions on our agenda. Still two more days to go :)

Raphaël Hertzog: How to create Debian packages with alternative compression methods

While gzip is the standard Unix tool when it comes to compression, there are other tools available and some of them are performing better than gzip in terms of compression ratio. This article will explain where you can make use of them in your Debian packaging work. In the source package A source package is composed of multiple files. The .dsc file is always uncompressed and it s fine since it s a small textual file. The upstream tarballs can be compressed with gzip (orig.tar.gz), bzip2 (orig.tar.bz2), lzma (orig.tar.lzma) or xz (orig.tar.xz), so choose the one that you want if upstream provides the tarball compressed with multiple tools. Put it at the right place and dpkg-source will automatically use it. Note however that packages using source format 1.0 are restricted to gzip, and the main Debian archive currently only allows gzip and bzip2 (xz might be allowed later) even if the source format 3.0 (quilt) supports all of them. The debian packaging files are provided either in a .diff.gz file for source format 1.0 (again only gzip is supported) or in a .debian.tar file for source format 3.0 (quilt) . The latter tarball can be compressed with the tool of your choice, you just have to tell dpkg-source which one to use (see below, note that gzip is the default). In a native package, dpkg-source must generate the main tarball and you can instruct it to use another tool than gzip with the --compression option. That option is usually put in debian/source/options:
# Use bzip2 instead of gzip
compression = "bzip2"
compression-level = 9
For 3.0 (quilt) source packages, this option is not very useful as the debian tarball that gets compressed is usually not very large. But some maintainers like to use the same compression tool for the upstream tarball and the debian tarball, so you can use this option to harmonize both. In native packages, it s much more interesting: for instance the size of dpkg s source package has been reduced of 30% by switching to bzip2, saving 2Mb of disk. In the binary packages .deb files also contain compressed tar archives and by default they use gzip as well:
$ ar t dpkg_1.15.9_i386.deb
debian-binary
control.tar.gz
data.tar.gz
data.tar.gz is the archive that contains all the files to be installed and it s the one that you can compress with another tool if you want. Again this is mostly interesting for (very) large packages where the size difference clearly justifies deviating from the default compression tool. Try it out and see how many megabytes you can shove. Another aspect that you must keep in mind is that those alternative tools might use important amount of memory to do their job, both for compression and decompression. So if your package is meant to be installed on embedded platforms, or if you want to build your package on low-end hardware with few memory, you might want to stick with gzip. Now how do you change the compression tool? Easy, dpkg-deb supports a -Z option, so you just have to pass -Zbzip2 for example. You can also pass -z6 for example to change the compression level to 6 (it s interesting because a lower compression level might require less memory depending on the tool used). The dpkg-deb invocation is typically hidden behind the call to dh_builddeb in your debian/rules so you have to replace that invocation with dh_builddeb -- -Zbzip2 . If you are using a debhelper 7 tiny rules files, you have to add an override like in this example:
%:
	dh $@
override_dh_builddeb:
	dh_builddeb -- -Zbzip2
If you are using CDBS, you have to set the variable DEB_DH_BUILDDEB_ARGS:
include /usr/share/cdbs/1/rules/debhelper.mk
[...]
DEB_DH_BUILDDEB_ARGS = -- -Zbzip2
I hope you found this article helpful. Follow me on identi.ca or on twitter.
Flattr this Share/Bookmark One comment Support my work

Sandro Tosi: HTTP requests specifying the Host header (in Python)

Since it took me some time to find this solution, I think it might be worth to share it.

When you have a web server listening on a single IP address but serving several domains, it's quite common to run:
$ curl -H "Host: domain" http://ip_address/path/to/the/page.html
if you need to view that domain directly pointing to the web server (so avoiding any balancers or network "magics" you might have in place).

Well, the question is: how to do that in Python? I find my answer in the httplib module:
import httplib
conn = httplib.HTTPConnection("ip_address")
conn.putrequest("GET", "/", skip_host=True)
conn.putheader("Host", "domain.ext")
conn.endheaders()
res = conn.getresponse()
print res.read()
HTH

Alexander Reichle-Schmehl: Release Critical Bug report for Week 37

The unofficial rc bug tracker currently knows about the following bugs:
In Total:423
Affecting Squeeze:317
Squeeze only:107
Remaining to be fixed in Squeeze:210
Of these 210 bugs, the following tags are set:
Pending in Squeeze:15
Patched in Squeeze:36
Duplicates in Squeeze:22
Contrib or non-free in Squeeze:7
Claimed in Squeeze:2
Delayed in Squeeze:7
Can fixed in a security Update:11
Otherwise fixed in Squeeze:18
Ignoring all the above (multiple tags possible), 126 bugs need to be fixed by Debian Contributers to get Debian 6.0 Squeeze released. However, with the view of the Release Managers, 255 need to be dealt with for the release to happen. Please see my older post for an explanation of the different numbers.

Russell Coker: Preferring Low Quality and Microsoft Software

Is Low Quality in Italian Academia related to the choice of Low Quality Software? Diego Gambetta and Gloria Origgi wrote an interesting paper titled L-worlds: The curious preference for low quality and its norms [1]. The paper describes how in Italian universities (and large portions of Italian life) there are covert agreements that both parties in a transaction (the employee and the employer or the buyer and the seller) will deliver less than agreed while pretending that they are offering the agreed exchange. People who offer high quality in exchanges are discriminated against because they make people who offer low quality in exchange feel guilty. Nathan suggests that this is the explanation for people choosing to pay for inferior software from Microsoft instead of getting superior software for free [2]. Now it does seem quite plausible that someone who is offering low quality goods in the manner of Italian academia would refuse to consider software from any company other than Microsoft, after all the easiest way of selecting software is to phone a MS representative and be told exactly what to buy. But I don t think that this explains even a significant fraction of the people who refuse free software. There is no direct analogy between bilateral agreements to produce low quality and the choice of MS Software because MS Software is quite expensive (they demand what would be considered a high quality trade in the jargon of the paper). If someone was to buy one of the cheaper laptops in Australia (around $650 new) and upgrade to the full version of Windows 7 along with purchasing the home version of MS Office then the cost of software would be almost as much as the cost of hardware. If they wanted one other MS product then the cost of MS software would probably be greater than the cost of hardware. Hardware costs are steadily falling and MS prices are only increasing, for people who use MS software we should expect that soon the MS tax will be the majority of the costs of running a typical PC. Good Reasons for Choosing MS One thing we have to consider is that there are people who have good reasons for using MS software. One example is the companies that depend on proprietary applications which are central to their business. When the entire company s data is stored in an undocumented proprietary database it s really not easy to change to a different application even when everyone in the company knows the software to be of amazingly low quality. If the vendor of the proprietary application in question decides to only support MS Windows then it s customers (victims?) have no choice about which OS to use. One interesting thing to note about such companies that are locked in to proprietary software is that the amount that they spend per year on license and support fees is usually greater than the cost of hiring one good programmer. If a few such companies formed a consortium to develop free software to manage their business where each company paid the salary of one programmer then after a couple of years of development they could move to the free software and reduce their operating expenses. Another category of users who have a good reason to choose MS is the people who play games seriously. If you want to play games then MS Windows does offer some real advantages. The price of games will usually be a fraction of the hardware cost (the serious gamers spend a lot more on hardware than most people) and MS Windows is apparently the best PC OS for commercial games. Personally I ve found that there are more than enough free games on Linux to waste my time, Warzone 2100 [3] is one that I currently play, and I ve tried Battle for Wesnoth [4] in the past and found it too time consuming and addictive. How a Preference for Low Quality could lead to Microsoft I think that everyone who has any significant experience in the computer industry has encountered companies that have large areas of low quality. This generally tends to be in large corporations as small companies can t afford the waste. In some large corporations Linux on the desktop is never considered, even when people are hired as Linux sysadmins and there are obvious productivity benefits to having the same OS on the desktop as on the servers (even if two desktop PCs are required so that proprietary software can be run on MS-Windows). Major wrote a good satire of the corporate IT non-working culture with a comparison to medical work [5], it illustrates the principle of a coalition to ensure low quality. He later documented how he was sacked by the low quality coalition at a company that uses a lot of Microsoft software [6]. So it does seem that when customers don t care at all about the quality of the result it does help drive some sales for Microsoft. But that doesn t explain the market share that they have. It takes a lot of work to get Market Share without Quality Microsoft has spared no effort in gaining market share. Every possible effort including buying out small competitors, aggressively FUDing competition, using all manner of legal attacks (including the threat of patent suits), and deliberately breaking standards has been used. I think it s reasonable to assume that the MS senior management are not entirely stupid, they do so many things that are unethical and possibly illegal because they know that they need to do so to maintain their market share. The result is that the market capitalisation of MS is almost as high as that of Apple and Apple makes vastly superior products. Given the amount of effort that MS uses to keep market share it seems apparent that they aren t just relying on customers not caring about quality. Should users have to Understand Computers? My observation is that most users don t want to know much about how their computers work. The desire to understand computers seems to be about as common as the desire to understand cars, people just want to buy one that looks good and have it work. The difference is that cars are very compatible while computers aren t. Cars have the same controls in the same places and large parts of the design are specified by law so that they can t differ between models. Proprietary software is usually intentionally incompatible with other software (both open and proprietary) to try and gain a competitive advantage. Hardware is often incompatible due to the rapid developments in technology and the requirements for new interfaces to take advantage of new features. In concept it seems reasonable for someone who is about to spend $30,000 on a car and $1000 on a computer (for hardware and software) to spend 30 times longer considering which brand of car to buy. One could argue that more than 30 times as much consideration should be given to the car as most people can t afford to discard a car that they don t like. As people spend a few minutes considering which brand of car to buy they can be excused for spending a few seconds considering which type of computer to buy. But once a choice has been made about which software to use it s very difficult to change to something else, while in comparison it s easy to drive a car that was manufactured by a different company. So a poorly informed choice made at an early stage can have costly long-term affects when buying software. If we had mandated open standards for file formats and data interchange then users would be able to make choices that don t result in their data being locked in to some proprietary format. Such standards could be set through government tender processes, if every government agency was to only buy software that complies with open standards then the proprietary software vendors would scramble to make their products less incompatible. The result would be that bad choices in purchasing software could become learning experiences that result in better purchases in future instead of being a lock on users that forces them to keep using the same software that doesn t satisfy their needs. Conclusion I think that the best thing about the paper by Diego Gambetta and Gloria Origgi is that it highlights the issue of low quality. No-one wants to be considered a loser, so maybe this can encourage people to strive for high quality (or at least try to make their work suck a little less). Regardless of the conclusion they eventually reach, it s probably good for people to occasionally wonder do I suck? .

Alexander Reichle-Schmehl: Some notes about the Debian on the HP Mini 2102

The other day I got the HP mini 2102 Netbook I won at the Release Cricital Bug Contests. Many thanks for it! It works more or less out of the box with Debian Squeeze, including Suspend, Hibernate, external VGA Port. Batterie seems to hold for about 7 hours, which is okay, too. However, it wasn't shipped with Debian pre-installed, as I had been told. After unpacking the Netbook right in the train on may to work after picking it up in the morning, it was quite disapointing to just see Windows 7 installing some software for over two hours, before I could do anything with it! Booting the debian-installer via usb worked, but I couldn't use the keyboard (which BTW doesn't have Page Up/Down, Pos1 and End keys) in the syslinux boot menu. But as the usb-images ship with a setup.exe wich adds the installer to the Windows boot loader, that wasn't a major problem (it just took me a while to find it). The HP mini 2102 is a quite new Netbook, but to my suprise nearly everyhting worked out of the Box. Some minor problems where the battery display. With Kernel 2.6.32 it only showed the current state, but no estimations how long it would hold. Installing Kernel 2.6.35 fixed that. The Synaptics clickpad (which is a touchpad without buttons physically sepperated from the touching area) isn't fully supported. The Kernel driver has already been updated (see #572842), however xorg synaptics driver hasn't been updated to support it. Don't ask me, why there hasn't been a bug report for that package; I asked for it in #597082 and put the packages on my people account. You just need to download and install the xserver-xorg-input-synaptics deb and you should at least have two usable mouse buttons. You can try some fine tunning as described in the Debian wiki, but not everything seems to be supported (e.g. multitouch, emulated third mouse button). The last problem is quite interesting. While the build in wireless adapter works very well, it constantly looses the connection, when I connect it to my Palm Pre in his hotspot-mode. But I have no idea how to debug it, as it works very well with other wireless networks, while my regular notebook works without problems with the Palm Pre. So I don't know, why wpasupplicant constantly looses the connection and reconnects. It someone has some hints about these two issues, an e-mail would be most welcome. Thanks! Update: Oh, I got Pg-Up, Pg-Down, End and Pos1 keys via fn and the cursors keys! Yeah!

Erich Schubert: Random background python script

I use the following python script to choose a random background on login:
#!/usr/bin/python
import os, os.path, random, gconf
startdir="PUT YOUR FOLDER HERE"
gkey="/desktop/gnome/background/picture_filename"imgs=[]
for root, dirs, files in os.walk(startdir):
  for file in files:
    base, ext = os.path.splitext(file)
    if ext.lower() in [".jpg", ".png", ".svg"]:
      imgs.append(os.path.join(root, file))img = random.choice(imgs)gconf.client_get_default().set_string(gkey, img)
It's fairly simple, but shows the power of the python libraries. It "walks" the directory tree, collects all files of the given extensions, chooses one at random, then updates the gconf key for the Gnome background image.P.S. Yes, I know a couple of ways to do that in a shell script, too. However, then one I used failed with whitespace in file names, so I decided to rewrite it in a much more sane language ... the random involved was also a hack.

16 September 2010

Adrian von Bidder: Remote Controlled

The Apple universe is happy to live with whatever Steve Jobs allows to get in. Numerous examples going back at least 20 years are available; most recent Apple's law action against a manufacturer offering compatible batteries and now an external harddisk for iPods. Microsoft is obviously the traditional enemy for many (personally, I think there's not much difference between MS, Apple and Google anymore.) So no surprise that MS Exchange plays a role in the story about a remote wipe function of many smartphones. Just being connected to a MS Exchange server allows the administrator of that server to remotely factory-reset the smartphone. I'm not sure if there's a complete list of vulnerable smartphones, but at least iOS, webOS and Android based phones are affected. Personally, I'd say this is a serious security issue. But of course, according to the manufacturers, it is a function for the convenience of network adminstrators so they can wipe stolen phones remotely. Update: Nico: If I'm somebody who is really after your data, I've got your smartphone and I'm clever enough not to connect it to the net before I got the data out. So you're only catching the Oh look what I accidentally found case, which I think is really just giving you a false sense of security. Anonymous: Google is the company with the Do Not Be Evil company motto and the very good press and marketing team touting everywhere how much they do for the good of everybody. Except when it cuts into their earnings. Like really cooperating with the Linux kernel folks. Like living up to what they announced they'd do in China. It's also the company covertly collecting WLAN data, and only admitting to exactly as little as they can get away with when it comes into the open. And, in the end, simple greed will do the rest: it's a powerful big company with plenty of very well paid career positions, and in my experience this company tends to attract people who will use this power in any way they can to increase their income. At this level of business, a company motto like the one of Google is just a few meaningless words. The real company motto is Earn Money. In Whatever Way. Other examples are told by anybody who needed to interact with their so called customer support, either because they got their free account locked or because they had a specific request as a paying customer placing ads on Google (and I'm talking about a company with at least several CHF 10k per year in ads, not just a small nobody.)

Michal Čihař: Cleaning up phpMyAdmin's feature requests

The phpMyAdmin's feature tracker is kind of special thing, which grows all the time. From time to time I try to go through all of them and properly mark those who are fixed meanwhile or do not make sense anymore. Today I started with 277 (49 of them already marked as fixed in upcoming releases). After random accessing the list and about one hour I'm down to 266 (53 out of them fixed in git). Well 15 less is not that much better, but at least I managed to kill some long waiting zombies, which turned out to be bugs instead of feature requests.

Vincent Sanders: The turmoil of an entropy key release.

Last week we released 1.1.3 of the Entropy Key software. Poor Daniel struggled for days to get this out the door but finally he managed to build all the various debs, rpms and tars for the supported platforms and Rob got it all uploaded and announced.

The release is kinda strange in that it was the first in which the main changes were for performance. OK there is an improvement to resilience in the face of failed re-keying which some users were seeing in high load situations, but that high load was (in some cases) being caused by the daemon itself.

The process was mainly driven by one of our users, Nix, who was experiencing ekeyd using "too much" CPU on his system.

Of course on our servers during testing ekeyd it had used around a percent of CPU, certainly nothing that flagged as a problem in our own use (yes we eat our own dogfood ;-) Alas for this user on a 500MHz geode it was guzzling down 10% of his CPU which was clearly unacceptable.

This user however instead of guessing what the problem might be or simply leaving it up to us did something about it. He instrumented ekeyd, located the garbage collector tuning parameters as being incorrectly set and supplied a patch. Did he stop there? no! he then went on to profile the code further and clean up the hotspots. This resulted in ekeyd falling to less than 1% of the runtime of his system.

By reducing the CPU usage of ekeyd to this level it became more apparent where a previously reported bug was coming from, which enabled me to address it.

I know sometimes I complain about Open Source software but at times like this it makes me happy that we released the ekeyd software freely. This is how its supposed to be! Everyone working to make better software and benefiting together.

It has not just been on this occasion either, throughout the last year since our very first 1.0 release there has been helpful and useful feedback, patches from several users and even the odd thankyou mail. This project then has been a positive Open Source experience and I look forward to another constructive year maintaining this software.




Next.

Previous.