Search Results: "Martin"

22 June 2006

Martin F. Krafft: Buying shoes

I truly hate buying shoes. As a matter of fact, I hate buying most wearables. That, by itself, is not geeky. What makes my geekyness irrefutable, however, is that today I simply bought the same pair of shoes three times, and as a matter of fact, they're the same kind that I had bought the last two times. In other news: I spent most of today procrastinating. So instead of finally working on my FrOSCon talk, I decided to get the long-overdue spring cleaning done. Four hours later, I could finally breathe again in my flat. And now I really feel a lot better, with all the tidyness around me. I wonder what I'll find next to keep me from completing the slides...

Anthony Towns: Happy Birthday To Me

Today’s news: I’m now a scary biker type person, just like Martin, Michael, David, Bruce, and James along with once and future bikers like Sarah or Pia, but only dreaming of approaching the glory days of the munificent Greg. As of yesterday, my ride is a gorgeous blue 2005-model Honda VTR250, picked up from the dealer with a whole 1km already on the odometer (apparently they rode it to the service station to get some fuel). Read the rest ...

20 June 2006

Martin F. Krafft: GPG keys expire

Today is 2006-06-20, and five years ago I created the GnuPG key pair that I have been using ever since. Possibly due to ignorance, I chose a key validity of one year and consequently stuck with that policy. Thus, every year on 20 June, I have to renew my master (signing) key and generate a new encryption key. And every year, on the days following 20 June, I will get several dozens (if not hundreds) of emails telling me that my key has expired, written by those who write emails faster than it takes to check for availability of the new key. Finally, my key now has hundreds of expired signatures, because it's GPG's default to expire signatures along with the master key. This year, I took a step back and reassessed the choice. The result is that I am not expiring my master key anymore, but I will continue to provide a new encryption key every year, which will be valid for just a little more than a year. Here are the reasons I found why you'd ever expire the master key:
  • the key is intended to be used only for a limited amount of time. This is not the case for me.
  • in case of loss of control and lack of revocation certificate, the key will eventually become unusable. First, I have a revocation certificate, and second, if I lose control over the key it should mean that someone figured out my passphrase, so could just extend the livetime of the key anyway.
And here are the reasons for the encryption keys:
  • if you do lose control over your key, all's lost anyway.
  • if an attacker manages to crack one key, s/he can only read communication of the year during which I used the key, but no past or future communication.
As always, I'd love to hear your input, and I'll post relevant follow-ups. In the mean time, please make sure you refresh my key:
gpg --keyserver subkeys.pgp.net --recv-key 330c4a75
wget -qO- http://people.debian.org/~madduck/gpg/330c4a75.asc.gz \
    zcat   gpg --import
(Note: you can always get my latest key from the above URL) You may also want to consider running gpg --refresh-keys from cron. I suggest doing so on a ghost copy of your keyring though and then to merge from there, or else you'll experience locking problems when trying to use the keyring at the same time.

19 June 2006

Martin Zobel-Helas: How to activate the Error LED on Soekris net4801

modprobe scx200_gpio
mknod /dev/soekris_error_led c 254 20
echo 1 > /dev/soekris_error_led
Now my router can morse errors :-)

17 June 2006

Martin F. Krafft: Parsing arguments in a shell script

Since shell is a rather unpredictable programming language, which seems not to allow manipulation of variables in parent processes, parsing arguments has always been a bit cumbersome. For instance, check out lines 74 through 123 of /usr/bin/deb-reversion (package devscripts) for the way I used to do things, which involves a sort of state machine to handle options taking arguments. Just last night, I came up with another means, and while it felt like an incredible hack at the time, I am starting to like it. This method can be combined with getopt, I just use it to parse guessnet test lines in /etc/network/interfaces right now:
eval $(while [ -n "$ 1:- " ]; do
    case "$1" in
      mac) echo MACADDR="'$2'"; shift;;
      essid) echo ESSID="'$2'"; shift;;
      ie) echo IE="'$2'"; shift;;
      *)
        echo "$ME: E: invalid argument: $1" >&2
        exit 1;;
    esac
    shift
  done   exit $?)   exit $?
When this is done, any (or none) of the three variables MACADDR, ESSID, and IE are defined in the shell script's environment. If an argument is required, I can do checks following the loop, or use getopt to parse $@ before looping over its components. Of course, the last line really does make it look like a hack, but it works and it's flexible... If I now look at /usr/share/guessnet/test/test-wireless, I wonder how Thomas Hood managed to get things working, specifically because he sets variables inside a while loop, and then uses them outside of the loop -- exactly the sort of construct that drove me nuts previously. Maybe it has to do with my religious use of set -u, maybe not. In any case, I am simply not willing to investigate.

14 June 2006

Gunnar Wolf: The other side of the world

Martin: Strange... Here setting up a company is so much of a hassle that most people only register as Persona f sica con actividad empresarial instead - Physical person with enterprise activity. That means, you can print your invoices with "Madduck Consulting Inc." if you so wish, as long as under that, in tiny letters, you print your real name and fiscal data.

Gunnar Wolf: My view on DPLship

Several people's blogs have appeared recently in the planet with the different points of view on the different candidates and various rants regarding the DPL office - Well... This time I have not yet been able even to read the platforms of the different candidates (of course, I plan on doing it quite soon), but I follow the posts on the subject with interest. The most interesting post so far is Martin Michlmayr's - Of course, being an ex-DPL, there are important experiences he has that few people do.
A couple of days ago I was talking with one of the candidates with whom I have talked and worked in the past. My main gripe with the whole process is that, although as a project we need a leader, an easily identifiable single contact person who knows the teams, knows the people and can speak on the project's behalf, I have not seen much being done by the past DPLs towards the inside of the project. Of course, it's easy to bitch around when I sit in the comfortable silent majority most of the time - Currently I am devoting quite less time and effort to Debian than what I should, although it is true that setting up Debconf6 in Oaxtepec takes a _lot_ of time and that it will facilitate much more interaction between Debian people (which is good for the project) than me working more and better on my packages and on doing interesting team work.
Maybe something that would make me to vote for somebody, more than the most coherent and best written platforms, is for the candidate to admit the lack of importance of the role to most of the project - or to defend how to make it again a leadership position.
Following Martin's post, maybe we do need a Bruce-like leader who tells us what to do and drives the project. Or maybe not, maybe we could do better with reducing the importance of the post towards the inside and emphasizing it's mostly a confidence vote for somebody to speak on behalf of us all. And even this would be difficult, as a sad flame in debian-private some months ago reminds us that nobody can speak on behalf os the whole project because somebody might be offended by the viewpoint taken by the official?
I am no big believer in democracies. I do think that sticking to much to a democratic constitution (where democracies are very scarce in the Free Software world, where projects tend to have benevolent dictators grown by meritocracy instead of democratically elected) and allowing everybody to voice too much the same opinion in our regular flamewars has lead Debian to the communications swamp it is right now. We do have very effective small teams (quoting Andreas Schuldei' term for the phenomenon that seems to work best and appear naturally in our project), integration between teams is quite good... But having 1000+ people sitting in a big room and shouting at each other is plainly not fun. Maybe we should stop pretending that there is no cabal (forgod'ssake...) and admit that there is and it works, and we (the drones) implement Their decisions? Nah... That sounds it would only create more flamewars.
But seriously: Towards the inside, do we need a leader? Have we ever used it?

13 June 2006

Martin F. Krafft: madduck's conjecture

The probability of failure of a (computer) system is exponentially proportional to the physical distance between it and the one who could fix it.

12 June 2006

Martin F. Krafft: Norwegian Wood

During my travels in Southeast Asia, I had several chats with a fellow traveller from Portugal, who also seemed to enjoy Haruki Murakami, and other works by modern Japanese authors. She was surprised to hear I did not like Norwegian Wood, which was her first Murakami, and brimmed over with enthusiasm about discussing Murakami (who's been my favourite author for about a year now), I promised to reread the book to find out just why I didn't like it. Here's what I came up with:
Norwegian Wood was the one of Murakami's novels that I didn't like at all, wish I had never read, and by which I felt "cheated" and let down by what may well be my favourite author for the time being -- well, maybe Dance Dance Dance is also one of those. It was previously impossible for me to determine exactly why I felt so bad about the book, which made this reread a little more challenging -- and rather interesting in the end. Norwegian Wood was my third Murakami novel, after I had read the Wild Sheep Chase and After the Quake. Up front those reasons that I think made me dislike the book the first time around: the story line of Norwegian Wood is absolutely boring and way too autobiographical, and the ending is painfully artificial. In fact, half way through the book, the story takes a turn (I cannot pinpoint the exact moment), around which I often put down the book in refusal, annoyed and disappointed. If I say that the story line is boring, I mean that it's a boring foundation, but as with all stories, it's in the author's hands to make it into an exciting novel. Murakami fails in this novel, in my opinion (he claims he set out to achieve something else, that this book was a challenge to him). Anyway, I do remember from my first reading that I really liked the tension and potential in the character interplay Murakami describes in the first half of the book, and I anticipated a deadlock between them, which would have to be solved by Watanabe (the main character) in a lose-lose type of resolution. However, what happens is that everything sort of resolves itself, dragging the characters along. It never touches once on paradoxical or supernatural elements as found in most other Murakami novels, which is a shame. Furthermore, it's a love story, and one with too many romantic and melancholic moments for my taste. Upon rereading (having gone through another four Murakami books in the mean time), I noticed a number of other things that disturbed me, or otherwise came in perpendicular to my taste: Toru Watanabe, the main character, aged around 20, goes through a great deal of effort to make sure the world knows he's just ordinary. Yet, the way he swings life is just a little too good for the ordinary. Throughout the book, you get the impression that he's not very happy or satisfied with his life, yet if you look at the days he fills, you'll tend to see them as complete. This turns Watanabe into a grouchy pessimist, and that mood transferred to me as the reader. On a side note: one thing I definitely like about Murakami's main characters (at least those I have met) is their self-sufficiency: the whole world could vanish and still they'd continue doing what they always did. In some ways, I have found myself in those characters, but more often I find myself looking up to them and wishing I could be like that. Watanabe is, however, just too much of a polished character (and with that I don't mean polished to be good, just polished), and one that seems to do everything right when it comes to the moral level. Sure, he asks himself about moral issues here or there, but my feeling was always that Murakami put those monologues in for completeness, not for character. I find it hard to imagine a boy between the ages of 17 and 21 (which is the years the book covers) with traits like Watanabe, and such integrity: he's never dishonest or even plagued by the possibility, and he appears to be consciously doing everything he does. He ends up in bed (or close by) with one of several girls he devours on a number of occasions, but each time stays in absolute control, not allowing himself to "do it", or accepting whatever excuse comes =66rom the girl. I don't mean to say that this by itself is unlike a boy at his age, but I guess what I am really lacking is a reflection on his thoughts, or at least some insight, which Murakami withholds each time. It would have added a lot of tension to those moments, made them even a bit erotic (which despite all the sex and sexual references, I found none of the book to be). Finally, there is almost no character development in the novel. Even though the time span of the novel spans a very important time in the development of a boy, he does not change much, nor does his perception of the characters around him (the book is told in the first person). In the end, despite a serious lack of motivation to read on throughout most of the text, I think I did learn to appreciate it after all. On the one hand, Murakami hides many little gems of thoughts in the conversations with Midori, the girl ready to shake up Toru's life, which often have Zen-character ("I wonder what ants do on rainy days"), and it did take me a reread to notice those -- and I smiled every time I did. On the other hand, the reread did allow me to get a closer look at the relationships between the characters, and how Murakami explores them, mostly with parallels referencing the past. He remains in my eyes as one of the most imaginative writers of modern literature, and while it strikes me as easier to be imaginative in an imaginary story, the challenge is all the more as you move into real life, and in this case: real life as tangible as it gets because of the elements of love.
I am still looking forward to my next novel, which will either be Murakami's Wind-Up Bird Chronicle (which is said to be his best), a book recommended to me by the aforementioned traveller (Lizard by Banana Yoshimoto), or one suggested today by my physiotherapist, but I fail to recall the name at this moment and shall have to wait until I receive my next treatment on Wednesday.

Simon Richter: The wheel, and what is wrong with it

Martin, on second thought I wonder why you are reinventing the wheel. Bind can already handle updates and also deals with the authorisation part. The thing that sucks about it is that it never rewrites the zonefile, but saves diffs instead, so once you start using dynamic updates in a zone, updating it by hand becomes more difficult.

Simon Richter: Bind vs. POSIX

Martin, I fully agree that bind should not try to second-guess the admin, but for the simple reason that it is not possible in any sane way to know about all the possible authorisation schemes, so why bother trying? I don't buy the argument that applications need to be able to deal with ACLs either, for exactly the same reason. "scp" for example, could not care less, simply because in the vast majority of cases, it will be used to copy files between computers whose user account databases are not synchronised anyway, so you cannot restore the ACL. If you want that, use tar and explicitly tell i

10 June 2006

Martin F. Krafft: DNS server selection, and why not to BIND yourself

I have been searching for a new DNS server for quite some time now. Among the ones I inspected were:
  • MyDNS, which seems interesting, but so far hasn't won my fancy because it has hardcoded SQL table names which do not at all fit in with our infrastructure, so I'd have to provide translation views (which isn't that much trouble). Upstream seems active, the bug count is low, but according to popcon, a whopping total of 0 participating people have mydns-pgsql installed. No wonder. Mh. Also, the package is unavailable on amd64 at the moment.
  • MaraDNS, which looks good and has a nice configuration file format, very similar to the djbdns (which I really like). The maintainer has indicated he'd prefer someone to adopt the package, not sure if I want to do that. Upstream seems active (and responsive), the bug count is equally low, popcon lists 35 installations.
  • nsd, which looks good but uses BIND-style zone files. No thanks! Read this about parsing them. I am just not all too thrilled about redundancy and brittleness.
So with all of the above, it comes down to MaraDNS or PowerDNS for me, depending on whether I want flat files (easy to maintain by separate users, with permissions set with per-domain granularity) or SQL (flexible, but not as easy to control access). My goal is to give certain users complete control over their own zones. Anyway, in the process, I did look at BIND 9 again, simply because it certainly has some interesting features the others do not have, namely nsupdate, DNSSEC, TSIG, and IPv6. So with the help of this awesome document on starting with a secure BIND configuration, I got the name server up and running with only few problems (zone files suck). However, it did not take me long to abandon it for good: The reason is #372591. I have found that the only way to give users the ability to create and modify zone files for their own domains in a fail-proof manner (so that they don't accidentally screw up permissions), is by using POSIX ACLs, so that each zone file has permissions like this:
# file: zones/belligerence.net
# owner: madduck
# group: dnsmasters
user::rw-
group::r--
group:bind:r--
mask::r--
other::---
BIND, however, insists on checking the standard Unix permissions of files it reads and fails rather verbosely if it decides that it cannot, or rather should not be able to read them:
Jun 10 15:36:15.871 client 84.7x.xx.129#33283: query: belligerence.net IN A
Jun 10 15:36:15.871 client 84.7x.xx.129#33283: error
I've let of most of my steam on IRC, but for the record, here's Bernhard R. Link's explanation, quoted with permission. He did point out that he knows only very little about BIND and comes at this rather from the point of view of the system-level privileges.
When POSIX permissions fail, it's always hard to decide. The system might not be able to drop root permissions properly and one might end up reading stuff not intended to be read. It took some time in Unix history to get privilege dropping right, and there's nothing worse than a BIND suddenly sending out your shadow file. the point is, bind needs root to bind to its ports. Then it has to make sure that root privilege is not abused. That can be either done by making sure on is only the specific user (which is hard to do portably, and sometimes fails), or double check you only access what you are allowed. Ideally it should drop privileges good enough, but given how often this failed in the past, double checks are a good thing.
I disagree. Of course it's hard to argue that double checks aren't a good thing, especially when it comes to security issues with respect to an application that has one of the worst security track records of all Unix applications. However, what BIND is doing here is covering up a potentially greater problem: if the underlying system does not handle privilege drops properly, then that needs fixing. If an admin runs such a system, there's the root of the problem. It helps only marginally that BIND is trying to help prevent attacks. Fix the problem at its root, don't fix or patch for the symptoms! Now, of course, it does not really hurt that BIND does these checks. However, if it does them, it should at least be less na ve about them. POSIX ACLs have been around for, what, almost 10 years now. Go figure. Btw: this applies to many other tools/standards in the Unix world. scp, for instance, also cannot handle ACLs. So MaraDNS or PowerDNS?

8 June 2006

Martin F. Krafft: Missing the nipple

When I solicited feedback on laptops and subsequently settled for the Thinkpad X40 [0], I was still a little sceptical about that little thing sticking out the middle of the keyboard which serves as a mouse. I don't use the mouse much, but now, switching to a new desktop machine after my laptop has served as primary workstation for the past 4 months, I find I miss the nipple. After all, the nipple is the only intuitive interface. After that, it's all nurture.
[0]a choice which I've never regretted, except maybe because of the flakey Hitachi 4K60 drive IBM ships -- I've had 2 replacements already), I was still

Martin F. Krafft: Matrox pains

One of my newer computers (an Athlon 64) came with a Matrox Millenium P750 graphics card. Back then, the machine was basically headless, so the graphics card didn't need to do anything. My primary workstation has been flakey over the past year, so I decided to switch to the newer machine. Trying to figure out the drivers for X, my mouth gets all watery when I hear about the P750 triple head support -- I do have three screens, so why not? But the excitement only lasts for a short time. First of all, Matrox only released a binary driver for Linux. Second, the binary driver only supports x86, so I cannot use it on my x86_64 environment. And third, the company is completely unresponsive, and if you get someone on the line, they're incompetent. I would be happy with a binary driver (sort of), but at least make it 64bit, don't just ignore the requests I do wonder how lonk it takes until one of the graphics card vendors pluges in at the deep end, open sources their Linux drivers, and becomes the Linux userss' primary vendor. At least they could do it for their previous models so as to not screw up the gamerz market. Oh, and let's give this guy some traffic.

Martin F. Krafft: Closed kitchen

When my (ex-) lab was (forcibly) suggested to move out of the main campus building to an office building in the north of Zurich, it was rather beneficial to me. The new building is a mere 500 metres from my flat, and the university cut a deal with the nearby Turbine Personalrestaurant to offer us our choice of three excellent meals for lunch each day for a mere CHF 7 (4.25 ; less than half of what you generally have to pay in Zurich for lunch). That restaurant is within eyesight of my flat. I could not have asked for more, really. Since then, the rest of the Department of Informatics has moved to another building across the street. Initially, the what supposed to include our group as well, but we resisted successfully. Even after I had left the lab, I continued meeting my former colleagues for lunch every other day, which was a great way to stay in touch. Anyway, with now more than 100 university employees in this part of town (which is supposed to become the third campus over the next ten years), the university opened a "Mensa" (university cafeteria) and subsequently stopped the subventions of our lunches at Turbine. This is a serious degradation of quality of life for all of us. Granted, Swiss university cafeterias must rank among the best in the world, but they still suck: you are treated as a number, no exceptions (like if you leave your ID card at home), and the food (which is far less appetising when served in masses) is slapped onto your plate without much love. Also, the new cafeteria is now much further away from my flat, so I am less likely to join the others for lunch on a regular basis. While most of my former colleagues are in the process of graduating anyway and I haven't really linked up with the new ones yet, this would have happened gradually anyway, but gradually is better than immediately. So now I am depressed and pondering whether to just not eat anymore. Damn you, university!

7 June 2006

Martin F. Krafft: Build dependencies and the clean target

I find it rather annoying that some packages require their build-dependencies to be satisfied to run fakeroot debian/rules clean. Those packages include:
  • all packages using debhelper (hm...)
  • all packages using cdbs
  • packages cooking with Python distutils
  • ...
I think they all should fail gracefully when asked to clean themselves, even if the build dependencies aren't satisfied. Rationale: if the build dependencies aren't there, there's probably nothing to clean. Otherwise it's a royal pain to quickly build packages on production systems with pbuilder or the like -- those clean first (rightly so), then try to package. Of course, an alternative would be to tell pbuilder to ignore failures from the clean process. But I'd much rather fix causes than symptoms. Also, this would mean that the clean target may actually not finish, because commands after the failed one get ignored. So please, prefix your dh_* or similar lines with a - (minus sign) in the clean target of debian/rules today. That minus will make ignore the errors. Thanks. /me now awaits the flame flood. Update: the discussion is going on (#debian-devel/irc.debian.org). It has been claimed that pbuilder must be fixed. I'd like to point out that dpkg-buildpackage does not check for build dependencies when asked to build a source package (which is when you need the clean target) with the -S switch. Update ^2: I could be coerced into accepting dpkg-buildpackage fixed to check for build dependencies before it cleans the source tree in the process of creating a source package. Note that it does this unless you pass -S, because then you're actually asking it to build the binary package, not just the source. The real question I guess is whether build dependencies need to be satisfied to "build" a source package. Update ^3: Junichi, the pbuilder author, has since followed up.

6 June 2006

Martin F. Krafft: Delaying mail

One thing I really miss about email as we know it is the feature to deliver a mail at a specified point in time, not necessarily now. Conceptually, this could be done quite easily: have an alias maildelay deliver to a script, which parses the envelope recipient of the form:
maildelay+2006.06.06.2000=madduck=debian.org@my.mail.relay
The script would drop the mail into a temporary file, removing the control information from the recipient headers:
s [^=]*=(.+)=(.+) \1@\2 
and set the file's modification date to the requested delivery date. Then have a daemon periodically scan the directory and pass expired files to /usr/sbin/sendmail. Michael Tokarev also offers an interesting approach: using Postfix header_checks, he suggests putting messages that contain a header such as X-Delay-Send on hold:
/^X-Delay-Send:/ FILTER hold:
Then, scan the hold queue and set the modification date of the appropriate files to the requested time to let Postfix's qmgr handle the delivery around that time. Of course, I am not supposed to roam about in /var/spool/postfix/deferred, less change any inodes, thus this method right now is not more than a nice idea (I did submit a feature request to Postfix; it doesn't look like it'll be accepted.). Regardless, both approaches are effectively open relays and I am not too inclined to do anything about that. So, moving on... Another method would be to write a policy daemon that returns a 4xx status message until the time specified in the email. Of course, this has the problem of unpredictability, so the mail could be delayed several hours longer than requested. But given the requirement that I'd like to turn my laptop (the submitting MTA) off and still have the mail delivered, the solution may be a second MTA on my SMTP relay (perhaps on port 587/tcp), which takes care of all TLS and SASL submissions and has a predictable retry period. If you have any thoughts (or existing solutions), please let me know!

Kenshi Muto: Now, CUPS 1.2 comes

After long working, we Debian CUPS team released CUPS 1.2 for Debian unstable. I'd like to say thank Martin Pitt because he has made many patches for CUPS. We hope this series will come into Debian Etch as soon as possible. Of course reporting bugs are welcome, but please consider whether CUPS is responsible or not for your bug :)

4 June 2006

Martin F. Krafft: Even easier?

Erich, claiming that "it's even easier" when our two approaches basically do exactly the same (mine requires less keystrokes to confirm) is kind of exaggerating, no? I must admit I am very interested in pyroman since I like Python, and "firewall" and "programming" are closely related topics for me. I'll have to do quite a bit of thinking before I can claim that it's easier to speard Python commands across several files as opposed to composing a firewall ruleset in the way it is later processed: line by line.

Erich Schubert: How to avoid locking yourself out via iptables...

Martin F. Krafft blogged about how to rollback firewall changes in the case you managed to lock yourself out from the box It's even easier if you use my Pyroman firewall config tool. (apt-get install pyroman). If you run pyroman safe it will execute the new firewall rules - and if you don't type OK within 30 seconds, it will undo all changes. Note that it can also restore to a configuration set by a different firewall app. (It just restores the old iptables state and feeds it back to iptables - it will support anything your iptables version does.) Oh, and it's much faster than the other firewall scripts I've tested so far, since it doesn't spawn hundreds of iptables processes, but only one iptables-restore for setting the new rules in one transaction. Check the web page for other benefits; should just work on any Linux distribution with iptables and python (read: every). [Update: Martin, I was referring to the instructions you gave, to adding an at job and then running atrm to accept the changes. Yeah, what you script does is basically the same what mine does for rollback.]

Next.

Previous.