I’ve just implemented shared mailboxes in dovecot (which rocks, btw). It isn’t difficult, but I don’t think it’s very well documented…

The preferred way to do this is with IMAP Namespaces. My natural approach would be to create something like a Maildir tree /srv/mail/shared, and make this the “public” namespace. Then set filesystem permissions on subtrees of that, to define who can see what. Unfortunately, dovecot uses strict Maildir++, and won’t let you create mailboxes inside each other (on the filesystem) /Foo/Bar is stored as a Maildir called .Foo.Bar, so subtrees don’t exist, so this isn’t an option. The up-comming dbox format should allow something like this, but it isn’t usable yet.

My solution was to create multiple namespaces. One for each shared mailbox. Users are given permission to use them via file-system permissions (i.e. group membership), example:

Setting CONTROL and INDEX mean that dovecot’s metadata is stored in the user’s personal Maildir, so users who don’t have permission to see the shared mailbox don’t get errors.

The permissions of the mailbox should be done as follows:

If you want a common subscription list, you have to manually symlink:

Seems to work well. (at least with thunderbird)

Finally, it’s got easy to install the codecs we can legally use in this country:

Medibuntu now has a non-free-codecs package, an all-in-one virtual package.

Nice job!

Personally, I’m still in favour having them there by default, and the installer removes them if you select a patent-encumbered country as your time-zone, but I can see why people are wary of that approach….

This afternoon, I went off to UCT, to help Arno out with a sudden problem in TSL: When you try and log into KDE, it just hangs. And if you try and run a KDE application from Gnome, it hangs…

I straced startkde, and spotted a hang that looked lock-related:

After some trial and error, it turned out, that the problem was the NFS mounted /home. KDE wants it to be mounted with the options async,lock. Then it’s happy. I don’t why how this turned up in a routine nightly Ubuntu feisty update. Maybe it was a backport?

Anyway, there you go: KDE is fussy about its locks.

Yes, petrol is now expensive enough, that it’s worth the risk to steal it from someone else.

On friday night, some bastard cut the fuel lines of all 4 cars parked outside our house. We are probably the only people on our street who don’t park behind an electric gate, because our driveway only has space for my parents cars on the property. My car lives on the council-owned part of our driveway.

I found out because my sister (who’d been visiting to use our Internet connection) broke down on the way home. With her car, this is perfectly normal, and to be expected. I went out to tow her home (she was only about a 500m away). I couldn’t find the tow hook on my car (my Golf has removable tow hooks, and somebody once broke into my car and stole the jack-set containing the removable hook), but I did notice that my car was trailing a line of petrol… odd… I went back to borrow my father’s car (with a tow-bar), and towed her home with that.

She was going to borrow my mother’s car (she usually does that when my mother is away, and her car breaks down), but noticed that there was a pool of petrol under it, too. Very odd…

At this point, I put 2 and 2 together, and found that all of the cars had cut lines. In the case of my father’s car, they hadn’t got a fuel line, but had god a brake sensor line instead. (Apparently VWs all have the fuel lines on the outside for safety, so they are the easy targets). On my car, they had only cut the fuel return line, so it could still drive, but would trail petrol.

The police were quick to come, but not very helpful: they said they’d never seen anything like it. They were thinking vandalism or neighbour issues. The questions were “Do you have a dog?” “Do you get on with your neighbours?” etc. You can tell what the normal problems in our area are :-)

The AA refused to come and help or tow the cars to my mechanic, saying the damage was an “insurable risk”. I thought most car problems were “insurable risks” and the reason one has AA membership is to sort things out afterwards? This refusal by them is unacceptable, what if it had happened when I was parked somewhere else? Would I have to get my car home by myself?

Fortunately my grandmother’s car was in storage in her garage, and I could rescue it. My sister stole her mother’s car, too. But I’ve now got a whole lot of paperwork to sort out, and 4 dead cars to get repaired… As I said, “Bastards!”

Photos here

Update:

• None of the cars have empty tanks, so if they were trying to steal petrol, they didn’t succeed.
• The damage came to R500 for the VWs, which isn’t bad at all. (Replacing the lines would be a mission, my mechanic repaired them). Excluding many hours of towing, phone calls, e-mail, and SMSs, though.

Update: Debian/Ubuntu version

I've finally jumped onto the local only DSL bandwagon. If you haven't done it yet, it's a great way to save some bucks. The idea is that you get a local only account like this, which costs a fraction per GiB compared to normal account. Then you get your router to connect to both simultaneously, and route intelligently between them.

Most ADSL routers won't let you connect 2 concurrent ADSL connections on the same ATM circuit. The solution is to use a separate modem and router. I'm using a basic Billion modem, in bridged mode, and a WRT54GL, running OpenWRT/kamikaze, as the router.

OpenWRT doesn't support 2 PPPoE connections out of the box, but I've found the problems, and got a few changes committed upstream, that solve them:

• Configurable default route: changeset 8569
• Allow specifying ppp unit numbers: changeset 8563+8564
• Support for multiple interfaces in UpdateDD (a DynDNS client): bug 2294

The firewall (/etc/init.d/firewall) needs to be modified with "WAN=ppp+" somewhere near the top, so that it masquerades all the ppp connections. This was a hack, apparently the firewall is being re-written soon.

There is also a bug that resets existing PPPoE connections on a ethernet interface when you fire up a new connection. This will apparently be fixed by the future interface aliasing support. For now, I just hacked around it in /lib/network/config.sh:

and /sbin/ifdown:

I got my local routes list from cocooncrash's site (he gets them from local-route-server.is.co.za, aggregates them, and publishes every 6 hours). OpenWRT already has a static routing configuration system, but it's very verbose. So I wrote my own, adding the new configuration option routefile. I used these hotplug scripts to set up routing and source routing, with the help of iproute2:

You'll probably want to update that route file regularly. I don't run cron on my WRT54GL, so I do it manually. Up to you.

/etc/config/network:

/etc/iproute2/rt_tables:

/etc/hotplug.d/iface/20-split-routes:

/etc/hotplug.d/net/20-split-routes:

Now, lastly, it won't bring up both interfaces by default. That will be fixed by aliasing in the future, but for now:

/etc/init.d/network-multiwan:

That's it, and it's working beautifully :-)

What is source routing, people ask? The problem is that your router now has 2 WAN IP addresses. IP1 is used for local traffic, and IP2 for international. So if somebody in ZA tries to connect to IP2, the reply (local destination) will go out of Interface 1. The ISP on the other end of Interface 1 will drop this reply, because it's not coming from IP1.

Source routing tells the router that replies must go out of the same interface that the request came in on. I'm doing it by creating separate routing tables for traffic origionating from each WAN interface.

Gotchas

• If you are using 2 different ISPs (say SAIX international and IS local), you must make sure that DNS queries get routed out the right interface. SAIX won't accept queries on their servers from IS, and vice versa.
• SAIX Web proxies, Mail servers, and News servers don't accept traffic from local accounts. (especially from another ISP)