GnuPG

I need to either kick a few keys from my keyring, or update more often.

gpg: Total number processed: 2085
gpg:              unchanged: 1111
gpg:           new user IDs: 232
gpg:            new subkeys: 67
gpg:         new signatures: 29393

I think I'll go for the former.

On apples

Julien Blache has been writing something called "pomme", to do some stuff with backlights for apple laptops--which explaines the name of the thing, since Julien is French.

One thing I've been wondering about, however, is why he chose to write something entirely new rather than submitting patches for pbbuttons, which does exactly the same.

His blog doesn't allow for comments currently (boo!), so I made this a blog post of my own. So, Julien, please convince me: what does pomme do that pbbuttons doesn't?

On my platform

I originally was quite reluctant to post on Planet Debian about the DPL race, but hey, this is the campaigning period, anyway.

My choice not to go into too much detail about what I'll do about Debian seems to spark some confusion. I initially thought of adding a rather verbose explanation for that to my platform; but as the initial version of my platform got quite long and convoluted, it got cut. Perhaps that wasn't a very good idea, so here goes:

One observation I've made over the years is that DPL candidates often come up with all sorts of grandiose plans about what should be done to improve Debian. These plans are usually the result of some observation they've made, and consequently some thinking they've put in so as to come up with what they think is the most reasonable solution to the problem at hand.

The only problem with this approach is that, if you're not involved in whatever you have ideas on, you'll probably end up suggesting things which the people that are involved do not think is a good idea to do. Which would consequently mean that you'll either have to do it all by yourself (since you can't force DDs to do something against their will, and we have a constitution to back that up), or that they convince you that it's not a good idea, and you end up not doing whatever you promised to do during your campaign anyway.

First, this is silly. If you don't know whether you can or will keep a promise, you should not make it. But apart from that, it's also a problem; if you get elected mainly because you promise to do one thing and then don't end up doing it, or do something else instead, then you've got yourself a very good reason not to be liked in the community. Which isn't something a DPL should aim for, I believe.

So rather than coming up with a detailed plan of all the things I'd do once elected, I decided to come up with a detailed plan of all the things that need work. The exact stuff that gets done about them would then be decided after having a chat (on IRC or otherwise) with the people involved, directly or otherwise, and after considering what other people's opinion on the matter is, if I know said opinion.

Does that give me a carte blanche, as Julien suggests? Well, yes and no. Yes, because every Debian Developer who runs for DPL is essentially asking for a carte blanche; after all, the DPL has the ability to speak for the developer body, unless overruled by GR. No, because I don't think doing whatever I want and everyone else be damned is an even remote sign of maturity, and because I promised not to seek the controversy in making decisions (while not avoiding it at all cost either).

Lazy day

So after a busy week at work and a rather busy day yesterday (with a rehearsal of the ensemble, then me volunteering to do the bar at a musical of one of the other choirs of the same group as the one I'm in, and then finally the DPL debate), I decided not to do anything remotely useful today.

Since the weather was nice, I went to the city. As I arrived there, walking around to figure out something interesting to do, I passed by 'De Muze', a well-known Antwerp jazzcafé (which either does not have a website, or has managed to hide it quite well). Since it was about 14:45, and they start live concerts there at 15:00 on sunday, I stayed for a while. After that, I went walking around in the city some more, enjoying the sun, eventually going through the Sint-Annatunnel (known to us Antwerp people as the "Voetgangerstunnel" -- pedestrian's tunnel -- since that's what it is), and stayed on the other bank of the Schelde for about an hour. Went home again, then, and had dinner.

I'll probably have a lot of questions to answer on -vote by now, but I just don't care for now. Tomorrow is another day.

The DPL race

The previous DPL races which I actively followed consisted of hectic discussions on the debian-vote mailinglist, multiple parallel long threads full of questions and answers.

Given that there were 9 candidates this year (of which only 8 are left now, after Sven Luther left the race, I expected to have to write an insane amount of time-sucking emails to that list, and had somewhat prepared for that eventuality.

Strangely enough, though, that hasn't happened. Since the campaigning period will come to an end this sunday, that'll mean that either most developers are waiting 'till the last minute, or that there simply aren't that many questions this year.

I'm really hoping for the latter... then again, I would prefer that people actually do ask questions -- the DPL is an important position in Debian, and people really should be informing themselves before voting.

Iniscripts

Been trying out upstart today. It's a nice piece of code, but unfortunately it's totally useless today.

Not because its concepts suck; rather, because Debian packages today ship with SysV-style initscripts, and those do not integrate well with upstart: most of the features that make upstart so interesting require you to create an event.d script, which has a totally different syntax. The Debian Developer inside me couldn't help but start to think about a way to fix this, but that seems harder than what it initially would sound like to the uninitiated.

My first idea was to add some /sbin executable to upstart or one of its supporting packages, so that a SysV-style initscript could exit if that binary told it that upstart was running, before doing anything. That way, a package could ship both upstart event.d files and SysV-style initscripts during a migration period, and we could get rid of the SysV-style initscripts when and if Debian eventually decides to migrate to upstar.

But when I sent that past #debian-devel, someone mentioned initng, which is yet a different init implementation. If this would work for upstart, it could also work for initng, and I don't think many packages would want to ship initscripts for three different init implementations. So scratch that.

My next idea was to generate initscripts, rather than have packages ship them. The amount of common code in our initscripts is huge, anyway, and it's not as if it's all that hard to write an initscript. The things an initscript needs to do are limited, anyway: start a daemon when requested, stop it, restart it, perhaps send it a SIGHUP if or when configuration updates have been performed, and provide some useful output on all that. In most cases, that's about it. So, I thought, why not create an RFC822-style file (analogously to other files in the debian/ directory of a debian source package) containing all the metadata on an initscript, and generate the correct style of initscript out of that? That should work, I thought. So I started writing a specification, and had a look at the initscript of one of my own packages, nbd-server. Which does this at some point (nonrelevant content cut out):

i=0
while [ ! -z ${NBD_FILE[$i]} ]
do
  start-stop-daemon --start --quiet --exec /bin/nbd-server (...)
  echo -n " ${NBD_FILE[$i]} ]
  i=$(( $i + 1 ))
done

There's no way you'll be able to express that type of flexibility with an RFC822-style file containing all the metadata. So, scratch that too.

I still do think generating initscripts is the right thing to do, however; the question that remains is "how". One idea I had was to use m4 in an autoconf kind of way, since autoconf allows one to mix autoconf macros with "regular" shell snippets, which would be exactly the kind of flexibility that one would need. However, that totally ignores the fact that autoconf is only able to pull this off because its output is shellscript in every case. An m4 macro that has to produce output which are not, in fact, shellscripts (such as would be the case for this project) could not do that.

I think I'm kinda stuck now...

iniTscripts: followup

(yes, I know how to type, but my keyboard is degrading. Apparently, I didn't know how to read yesterday)

There were a number of replies to my post about upstart and other init-implementations yesterday. Since it apparently didn't come through properly: yes, I do know about upstart-compat-sysv, and yes, I'm obviously using it. That wasn't the point.

The point is that using upstart-compat-sysv is a workaround which allows to migrate to upstart, rather than to support it in parallel. Debian has always been about choice; giving people the choice to use upstart rather than sysvinit and vice versa is something we should do. Ubuntu has chosen to use upstart rather than sysvinit, and that's their prerogative; but Debian as a whole cannot (and will not) make that choice.

The point of the exercise was to figure out a way to allow people to say "I want upstart", and bang—everything gets migrated to event.d scripts. But if they then decide that they don't like upstart after all, they should be able to just reinstall sysvinit, and bang—everything gets migrated back to regular SysV initscripts.

That currently isn't possible, and upstart-compat-sysv doesn't offer that.

Bornem Titans - Antwerp Diamonds: 0 - 6

My brother has been playing American Football at the Antwerp Diamonds since about a year now, and he's playing along in the official competition's matches this season. Not that there's much of a season, with only 6 teams in all of Belgium, but okay.

This sunday, they played against the Bornem Titans; and since he'd been asking me to come along to take some pictures of their match, and since I hadn't been all that productive on the camera front lately, I decided to come along.

They even won, although it was quite close: getting within 5yd of the goal line three times, only scoring once, and then even missing the conversion isn't exactly what they'd call a "perfect match", but it's good enough.

Also more pictures in my gallery.

known unknown_hosts

OpenSSH maintains a file called "~/.ssh/known_hosts", where it stores the SSH keys of the hosts it's visited before in an attempt to avoid MITM-attacks. This is good.

However, I have a range of IP addresses on this network here that are used for ever-changing hosts; customer's machines that are at my office, and which I need to temporarily give a network connection in order to allow them to download stuff (and because typing in an xterm on my laptop rather than on a different keyboard and to a different monitor is just so much more convenient). Therefore, I know that these IP addresses will change from time to time. At this point, known_hosts is an annoyance. And since I never connect to those hosts except from machines that I trust and/or through routers that I trust, there's no advantage to be gained in having the protection that known_hosts offers, anyway.

So, dear lazyweb: is there a way to tell OpenSSH that when it tries to connect to host A, B, or C, that it does not need to store stuff in known_hosts, and that it should just assume the key is valid?

Update:StrictHostKeyChecking no and UserKnownHostsFile /dev/null will do what I want. Obviously I do want to set these options in a specific Host stanza—i.e., not Host *. Thanks, madduck!

OpenID

I figured this new shiny OpenID thing was cool enough to start using it. There's just this one problem: I didn't want to have to go through the "register on a website and remember yet another password" dance once more; and since I have this marvellous Kerberos realm set up which works for authenticating against my webserver, too, why not use that?

So I downloaded the JanRain PHP OpenID library, and went hacking. It's not all that hard, really:

diff -ruN ./lib/actions.php /svr/www/openid.grep.be/data/lib/actions.php
--- ./lib/actions.php	2006-12-08 23:56:22.000000000 +0100
+++ /svr/www/openid.grep.be/data/lib/actions.php	2007-03-08 14:18:32.000000000 +0100
@@ -88,17 +88,24 @@
     if (!isset($input['openid_url'])) {
         $errors[] = 'Enter an OpenID URL to continue';
     }
-    if (!isset($input['password'])) {
-        $errors[] = 'Enter a password to continue';
+    if (!isset($input['password']) && !isset($_SERVER["REMOTE_USER"])) {
+        $errors[] = 'Enter a password to continue, or log in using an ' .
+			'apache logon method';
     }
     if (count($errors) == 0) {
         $openid_url = $input['openid_url'];
         $openid_url = Auth_OpenID::normalizeUrl($openid_url);
-        $password = $input['password'];
-        if (!checkLogin($openid_url, $password)) {
-            $errors[] = 'The entered password does not match the ' .
-                'entered identity URL.';
-        }
+	if(isset($_SERVER["REMOTE_USER"])) {
+	    if(!checkUser($openid_url, $_SERVER["REMOTE_USER"])) {
+	       $errors[] = 'The apache user does not match the openid URL';
+	    }
+	} else {
+           $password = $input['password'];
+           if (!checkLogin($openid_url, $password)) {
+               $errors[] = 'The entered password does not match the ' .
+                   'entered identity URL.';
+           }
+	}
     }
     return array($errors, $openid_url);
 }
@@ -166,4 +173,4 @@
     return sites_render($sites);
 }
 
-?>
\ No newline at end of file
+?>
diff -ruN ./lib/render/login.php /svr/www/openid.grep.be/data/lib/render/login.php
--- ./lib/render/login.php	2006-12-08 23:56:22.000000000 +0100
+++ /svr/www/openid.grep.be/data/lib/render/login.php	2007-03-08 14:53:56.000000000 +0100
@@ -3,6 +3,7 @@
 require_once "lib/session.php";
 require_once "lib/render.php";
 
+if(!isset($_SERVER["REMOTE_USER"])) {
 define('login_form_pat',
        '<div class="form">
   <p>
@@ -31,6 +32,33 @@
   </form>
 </div>
 ');
+} else {
+define('login_form_pat',
+       '<div class="form">
+  <p>
+    Enter your identity URL into this form to log in to this server. This
+    server must be configured to accept your identity URL. Since you already
+    logged on through an Apache method, entering a password is not required
+  </p>
+
+  <form method="post" action="%s">
+    <table>
+      <tr>
+        <th><label for="openid_url">OpenID URL:</label></th>
+        <td><input type="text" name="openid_url"
+                   value="%s" id="openid_url" /></td>
+      </tr>
+      <tr>
+        <td colspan="2">
+          <input type="submit" value="Log in" />
+          <input type="submit" name="cancel" value="Cancel" />
+        </td>
+      </tr>
+    </table>
+  </form>
+</div>
+');
+}
 
 define('login_needed_pat',
        'You must be logged in as %s to approve this request.');
@@ -62,4 +90,4 @@
     }
     return sprintf("<ul class=\"error\">\n%s</ul>\n", $text);
 }
-?>
\ No newline at end of file
+?>
diff -ruN ./lib/session.php /svr/www/openid.grep.be/data/lib/session.php
--- ./lib/session.php	2006-12-08 23:56:22.000000000 +0100
+++ /svr/www/openid.grep.be/data/lib/session.php	2007-03-08 14:34:49.000000000 +0100
@@ -129,6 +129,16 @@
 }
 
 /**
+ * Check whether the logged-on user matches the specified OpenID URL
+ */ 
+function checkUser($openid_url, $user)
+{
+    global $openid_user_urls;
+    return isset($openid_user_urls[$openid_url])
+        && $user = $openid_user_urls[$openid_url];
+}
+
+/**
  * Get the openid_url out of the cookie
  *
  * @return mixed $openid_url The URL that was stored in the cookie or
@@ -202,4 +212,4 @@
 
 }
 
-?>
\ No newline at end of file
+?>

It expects an array in config.php like so:

openid_user_urls = array(
	"http://wo.uter.be/" => "wouter@GREP.BE"
);

(in the case of kerberos; if you use a different authentication method, the syntax of that array will most likely be different, too)

It's still not perfect; all my changes really do is bypass the password check if it notices that apache has already authenticated the remote user; but I still need to "log on" at the PHP level, which also requires me to enter my OpenID URL. A somewhat cooler implementation would pre-enter the OpenID URL in the form. A really cool implementation would not even show me the logon form, but go straight to the "logged on" state, using the OpenID URL as given by the consumer, and the information apache provides us on the remote user. But it's a start.

Adding OpenID capabilities to my blog comment entry script is proving slightly more challenging, however. More on that later.

Valgrind

Valgrind rocks my pants off.

That is all.

Etch and glibc

Thomas mentions that Etch will release with glibc 2.3 rather than glibc 2.4, and wonders why that is.

There are two simple reasons for this:

1. AIUI, glibc 2.4 drops support for non-NPTL kernels (i.e., 2.4 and earlier Linux kernels). Since sarge's default kernel was still a 2.4-based kernel, upgrading to a glibc 2.4 will immediately break everything on your system, since at that point your libc suddenly refuses to cooperate with your kernel. Not providing an upgrade path for users who run a supported kernel of our previous release is not an option.
2. Etch will have official support for 11 architectures: i486 and later intel-compatibles, SPARC, Alpha, PowerPC, ARM, big- and little-endian MIPS, PARISC, ia64, S/390 and AMD64. If we want to migrate to glibc 2.4 or later and still release, then it has to work on all those architectures. Since NPTL requires some architecture-specific support and since that architecture-specific support is not available for some of our current architectures, this is not the case (also see the above). It may be possible that Debian "lenny" will drop some architectures because the most recent version of glibc still does not support them, but ultimately that decision will be up to the release managers.

So, while I'll agree that it kindof sucks that Debian will release with a somewhat outdated version of glibc, it's not as if there isn't a valid reason.

On the Debian Mailinglist "Code of Conduct"

There's something which has been bothering me for a while. I haven't talked about it much since I don't consider it all that important after all and since I know I'm probably in a minority position, but whatever.

Personally, I think the "do not Cc" policy in the Code of Conduct of Debian mailinglists is a big mistake. It serves no useful purpose (other than giving some people a reason to complain). If you want to make sure that people do not mail you unless you absolutely ask for it, then you should get their mail clients to support some sort of header to enforce that behaviour; and you should also make sure you set that header in your own mails. Most people on the Debian mailinglists use free software, after all, so doing this should be possible. Personally, I find it rather offensive that people can call Cc'ing you spamming, and get away with it. I refuse to even bother to keep track of who wants a Cc and who doesn't, and I refuse to use different keystrokes for 'reply to list' and 'reply to sender'. There's "reply" ("r", in mutt), which should go to the sender of the mail only; and there's "reply to all" ("g", in mutt), which should go to everyone who could read the original mail (either through direct, private mail or through list mail). Everything else requires special attention anyway, so it's pointless to try it. At least in my opinion.

Oh well.

Crap

Rule #1: don't do "svn commit" in a working directory of my blog when there are some unfinished and ill-worded blog posts still in that directory.

Or, in other words, my previous post shouldn't have gone out yet, it wasn't ready; it was way too convoluted and thus failed to bring across the intended message. Revisiting this post before posting it, is something that's been on my list of things to do for a fair while, but it just never happened. I guess the cat's out of the bag now, so I might as well clarify it here and now.

Let me make clear that I did not mean to say that people should just be Cc'ing everyone, whether or not they're on the list, in violation of the stated list policy. Instead, what I meant to say is that I do not believe that a policy on whether or not you should send Cc's to people is the right solution to this kind of thing.

Instead, I think we should have our mail clients support this kind of thing by themselves. There are really two types of "reply" in a mail client: one is a "public" reply, where everyone who read the original mail can also read any follow-ups, and the other is a "private" reply, where you only send your reply to the person who sent the mail you're replying to in the first place. There should not be a difference on the UI level between "reply to the list" or "reply to each and every email address that's in the 'To', 'Cc' and 'From' headers"; MUA software should be smart enough to notice when you're mailing to a mailinglist, and pick the right option out of the latter two all by itself. And if someone really wants a private copy of the mail, adding a header to do that is already possible today.

With that in place, there shouldn't be a need for a code of conduct to state that you should not randomly Cc people. QED.

Then again, obviously mailinglists suck and usenet is much better. But that's another discussion for another time.

Samba upgraded

I just upgraded samba.grep.be, my web/mail/subversion/whatever server, from sarge to etch. No, etch isn't released yet, but it's almost there, anyway, and I had some time off. That is, some time off—I got distracted halfway through, and then obviously dpkg asked me about conffile changes.

As far as I can see, it's all up and running again, now, though I might have missed some stuff in between. Occasionally, that might mean that Planet Grep had some issues for you today; but those (should) have been dealt with by now.

And I didn't even have any issues with packaged software. Isn't that great?