Beid issues: survey

I've been receiving a number of bugreports, both formal bugreports through the BTS and just people contacting me through regular mail or otherwise, about the packages for the Belgian Electronic ID card that I maintain for Debian. I think I'm starting to see a pattern in the bugs, but I'd like to be sure; and in order to be sure, I'd like for people who use beid on Linux to please send me the following information:

• Does it work for you? If not, does nothing work, or can you use some of the eID functionality? E.g., it might be that you can get the 'beidgui' application to start and do useful stuff, but that the firefox plugin doesn't work.
• Are you using Debian (or a derivative, like Ubuntu)? If not, what distribution are you using, and do you use a package or did you compile from source?
• What chipset does your smart card reader have? Does your reader use the PC/SC API, or do you use OpenSC? (note: this is a change that I made to the beid packages; the official government source does not contain OpenSC support, and I suppose neither do packages for other distributions)
• What processor do you have? (powerpc, amd64/em64t, i386-based, m68k, ...?)

I'd appreciate it if people willing to help me out could send me an email with their answers to the above at wouter+beid@grep.be. Thanks.

The pattern that I'm seeing currently is that people using the ACR38u chipset (as in the eID cardreaders sold by Zetes and the government) on amd64- or em64t-based machines cannot get it to work. What I'd like to find out is whether it works on other 64bit architectures, and/or whether it is acr38u-specific.

Of course, I'm not doing this on a for-pay basis (I 'simply' maintain the Debian packages), so there's no guarantees of me fixing these issues here.

Your cooperation is greatly appreciated.

070707

Today is 07-07-2007, or 07-07-07. According to the news, there are many, many people who want to marry today. One of the brides whom they interviewed on the radio mentioned that her parents had married on 07-07-77. Heh.

Me, I didn't marry. But on such a beautiful day, I felt like waffles. So I made some.

Yummy.

On Index files

Libraries are great. They make sure I don't have to do some specific work.

Libraries with proper API documentation are even better. They make sure I don't have waste half a day just to figure out how to use the damn library.

If the API documentation is really well done, it has an index with all functions supported by the library so that one can easily find the function you're looking for. In order to make this index more easily searchable by the use of vgrep, such an index is commonly organized in an alphabetical manner, grouped per letter of the alphabet (so that you'd find a function foo() under the letter F, and a function bar() under the letter B.

However, if it's part of your API to prefix all your functions with a common prefix (say, g_ or gtk_) and you don't skip that common prefix in the alphabetic grouping of your index file, you're just being silly.

Traffic Shaping

Erich Schubert blogs about traffic shaping, and shows how you can do some basic traffic shaping using a rather long example. I'm sure that example works, but mine is slightly less complex:

This is actually a literal example in the Linux Advanced Router and Traffic Control-HOWTO, and it works for me. Linux has a reasonably good default prioritizing and queueing already, and using the tbf filter doesn't replace them, whereas the detailed sfq example that Erich gave does. I'm doing this on my router (on the outgoing interface), not my laptop, which is also a rather important bit.

Of course, it working for me doesn't necessarily mean that it'll work for you too. But you might just want to try it...

Aaarg

I just noticed that hotplug has been removed from unstable, claiming that it has been 'superseded' by udev.

On the few occasions that I did try udev, it's always failed for me; as such, I'm still using hotplug on my machines. It's just way more reliable, in my experience; and I don't need automounting of CD-ROMs, or user-space scripts doing setup of kernel-space device nodes, anyway.

There are also still some 2000 machines using hotplug, according to popcon.debian.org. That probably includes me, but I don't have 2000 systems.

So I have a dillemma, here: either try udev again, or pick up maintenance of hotplug. Or figure out whether it's possible to use udev's hotplugging abilities without its /dev management. That would rock.

Joshua Bell: followup.

I was still getting responses on my Joshua Bell in the subway article today, weeks after I posted that. This was unusual, so I started investigating. Turns out Fark.com links to it, and many people find their way from there. Hi!

Anyway, the latest comment on that item contains this gem:

There is/was a street musician here in Boston who played the most amazing slide guitar I have ever heard. He is also filthy, unkempt, rude, and generally angry at the commuters who he clearly feels owe him more of their attention. It would be wrong to assume that his failure to draw crowds is due solely to the public's inability to appreciate music.

Right on! My point exactly.

I suck

It's good if you bring out a maintenance release of a certain specific software package that you maintain, if it segfaults on startup when a new feature is used.

It's pretty silly if that new version still segfaults if and only if that very same feature is used. What do you mean, testing?

Anyway, today I released NBD 2.9.6 that fixes those issues. And I extended the tests that are ran as part of 'make distcheck' so that it won't be segfaulting on startup anymore next time I do a release.

Silly me.

Split MX with Exim

I've been having a rather strange exim setup for my grep.be domain since a while; but it works, and I like it, so I thought I'd document it.

There are two systems involved in the grep.be mail setup: samba.grep.be, a box which is on the public internet and which has a globally-valid IP address, and goa.grep.be, my Thecus N2100 that runs in my home network. The "home network server" used to be rock.grep.be, and western.grep.be before that, and folk.grep.be before that, but their exim config never was significantly different. None of those boxen ever had a fixed globally valid IP address.

You'd think I'm defining my accounts on goa, and have samba just be a secondary MX. Well, almost. I also run a bunch of mailinglists, and running those on my private network would be a waste of bandwidth; that'd require me to have the mails come though my cable modem to get to the mailinglist manager, then to get processed by the last, and then to get through the cable modem again for quite a number of times. Some of these mailinglists used to be quite... traffic-intense... and I didn't like the loss of almost all my Internet connectivity when a mail was being sent out. However, I hadn't been smart enough to remember to get my lists in a separate subdomain; instead, both regular mail accounts and mailinglist addresses are simple @grep.be addresses. I could of course have reorganized everything, but I didn't want to do that if not absolutely necessary. And after thinking about it for a while, I came up with this:

On goa, the exim config contains the following in the acl_smtp_rcpt acl:

accept hosts   = 195.144.77.39
       domains = +local_domains
       endpass
       message = unknown user
       verify  = recipient

accept domains = +local_domains
       endpass
       verify  = recipient/callout=random/no_details

And on samba, it contains the reverse:

accept hosts    = +goa_hosts
       domains  = +local_domains
       endpass
       message  = unknown user
       verify   = recipient

require domains = +local_domains
	endpass
	verify  = recipient/callout=random/no_details

with +goa_hosts being a hostlist that defines the IP address(es) that goa may use to connect to samba.

The idea is that when an SMTP connection is initiated with samba, it will first check whether it knows the mailadres by verifying whether it just happens to be a mailinglist. If it is, then it sends it to the mailinglist. If not, it will connect to goa to verify whether the local part is know to goa -- unless the SMTP connection happens to be originating from goa itself. Goa does the same thing, but in reverse.

This way, samba can bounce unknown users at the SMTP stage, rather than having to accept them and then bounce them, as would be the case if I didn't have this setup.

Obviously the possible IP addresses by which goa can connect to samba (and vice versa) must be perfectly maintained, otherwise you create mail loops. Since goa is on an IP address that tends to change from time to time, I set this in a hostlist in my exim.conf, so that I only need to change it once if the IP address changes.

I'm pretty happy about my exim setup, even if it isn't perfect. There are still a number of things I'd like to do; one of them is writing a tool to parse my /var/log/exim4/mainlog to find hosts that have been trying to abuse my server, so that I can blacklist them for a few days.

Update:

Damn spammers

Since I spent quite some time thinking about my SMTP setup earlier today, I finally took the time to hack up a little perl script to parse my mainlog, pick out the IP addresses of hosts that appear to have been spamming me, put them in a database, and modified my exim4.conf to look them up and deny them access if I want to.

Those lookups are pretty easy, really. In the first section of your exim4.conf, I have this:

hide pgsql_servers = (/var/run/postgresql/.s.PGSQL.5432)/*/spam/Debian-exim/

with '*' being the password. Except that this is ident authentication, so I don't need a password, but apparently exim still expects something (if I'm not on crack). Oh well.

Then, in an acl, I have this:

  deny
    message = "Your IP was used for spamming over the last few days. Please stop the spamming, wait a few days, and try again."
    log_message = "denied access for $sender_host_address: in blacklist database"
    condition = ${lookup pgsql{SELECT id FROM spammer WHERE       \
       adres='$sender_host_address' AND lastseen > now() - '10 \
       days'::interval}{true}{false}}

(with the backslashed lines being one line, really, but I didn't want to fuck up scrolling)

You can put this in any ACL you want, really. In my case, since I'm very sure by the nature of the way I gather these IP addresses that they're spammers, it's in acl_smtp_helo. Depending on how you populate your database, you may want to put this in a different place. If you want, you can teergrube them a bit by adding delay=30s.

An alternative would be to set up a DNS blacklist; but that would just take too much effort to set up properly, and I just didn't feel like it. This works.

Fun game

• Go to nm.debian.org/maintainers.php
• Find your name in the list
• Read upwards
• Be amazed at the amount of people who apparently aren't a DD as long as you are, but whom you thought would be.

No, really.

Obviously that only works for Debian Developers. But it's still fun.

The iPhone

... sucks.

As this page aptly explains.

Not that I need an E70 or anything, but it's pretty well done.

Well, perhaps not well done. And not G-ratedly done. But still, done.

The "Debian Maintainers" GR

I had mixed feelings about the Debian Maintainers GR. It perhaps somewhat seemed like a remotely reasonable thing to do given enough beer, but it sure as hell also felt like a gross hack and workaround.

Seeing people such as Christoph Berg (who's on the NM Front Desk) speak out against it, and reading arguments from other people who are opposed on Planet Debian, has helped me clear up my mind. I don't think it's proper to do this, and I'll vote against it. That's not to say I'll oppose every similar proposal; it's just that I don't think this one should be implemented.

If you think the NM process is taking too long, then it's probably better to help out there rather than to try to create a system to bypass it in this way. And yes, I'm doing my part.

Dear lazyweb,

When learning some code I didn't know before, my usual way to get familiar with it is to first find some documentation or a kind spirit to help me understand the big picture, and then to run the code in a debugger or to do something like '/bin/sh -x', or some such, so that I can understand how it actually flows. That works pretty well with most software.

One of the things with which it does not work, however, is gcc's .md files. As far as I know, there are no debuggers for those files; and even though Simon helped me understand a few things about it at Debconf, I'm still not confident enough to just start editing stuff. Additionally, just randomly editing a 7k+ LOC file and expecting those edits to magically work is not something I consider very likely to succeed.

So, dear lazyweb: how does one debug gcc's .md files?

Incomplete descriptions?

I've been removing and blocking blogs on Planet Grep that don't contain their complete articles in their RSS feed, because I feel that a planet should read as a newspaper; having only teasers to follow makes that problematic. I find that having to open a different website each time you get to a different article distracts you from actually reading the blog entries on the planet, which isn't very nice; and since the RSS feed can contain the entire article, why not?

However, it appears that a number of people disagree with that opinion, so I'm hereby requesting opionions.

If you feel that Planet Grep should continue to contain only feeds with full articles (as opposed to feeds with a "read more" type of link), please leave a comment on this article in my blog.

Likewise, if you feel that Planet Grep should not try to be holier than thou and that more people on planet is more important than being able to read an article in its entirety on the planet, then please leave a comment on this article in my blog.

Thanks,